Troubleshooting Ignition Find/Replace After an Upgrade

Ignition 8.1 Find/Replace can fail at three different points: resource enumeration, resource loading, or property traversal. The distinction matters because an empty result does not prove that the old tag path is absent. In the reported upgrade case, searches that targeted All windows, Selected windows, or Opened windows returned no results after moving from 8.1.26 to 8.1.27 b2023042509, while Find/Replace Selected Windows from the Project Browser found the expected value. Later 8.1 releases also showed incomplete searches caused by unloaded Vision dynamic properties or a resource that interrupted traversal.

Where does the Find/Replace request stop?

Follow the data path. The Designer receives the search term and scope, enumerates eligible project resources, loads or reads each resource representation, traverses searchable properties, and adds matches to the result table. A failure at any hop can produce an incomplete or empty result set.

Layer one first in this context means the stored project resource, not Ethernet wiring. Confirm that the resource is included, readable, and loaded in the representation needed by the property type before judging the search expression.

Which symptom identifies the failure mode?

Use a token whose location is already known. The reported rename from TE201AB_StackInTemp to StackInletTemp was confined to the P&ID and PCS Trend windows, making those resources suitable controls. A search without a known control cannot distinguish a clean project from a broken scan.

Which search approach should you use?

Use selected-resource searches first. They provide an explicit resource list, find the expected values in the 8.1.27 case, and support a binary-search diagnostic when one resource stops traversal. Open windows and templates when the target is a dynamic template property. Reserve XML search for a large inventory that cannot be covered reliably through the Designer.

Do not treat the approaches as interchangeable. A successful selected-resource search proves that the token is searchable in that loaded or explicitly selected resource; it does not prove that All windows enumerates the same resource or exposes the same property state.

How do you isolate a window that stops the scan?

1. Close all open Vision windows so the test starts from a repeatable state.
2. Clear the Designer console, then run Find/Replace against a small selected group containing a known match.
3. Check the console immediately. One observed failure included java.lang.ArrayIndexOutOfBoundsException: 0 >= 0, followed by calls through DefaultTableColumnModel.getColumn and VisionAdvancedTable.lambda$updateViewDataset$3.
4. Enable debug logging for Vision.FindReplace. Record which windows are listed and the resource after which logging or results stop.
5. If a selected group fails, divide it in half and repeat the identical search against one half. If it succeeds, test the other half. Continue dividing the failing set until one window remains.
6. Open that window and inspect its bindings. A binding damaged during an upgrade can stop the entire search. Open the suspect binding editor and accept it with OK to rewrite a binding whose configuration is otherwise correct; repair any validation error shown by the editor.
7. Save the resource, clear the console, and rerun the search first against the repaired window, then against the original group.

The binary split is faster than testing every window sequentially. Keep the search term and options fixed throughout the test; changing case, scope, or property filters introduces another variable. If the console stays clean but the known closed-window value remains missing, test for the dynamic-property limitation instead of continuing to hunt for corruption.

How should dynamic Vision properties be searched?

Vision template parameters and other dynamic properties can depend on an in-memory component instance. Their values may not exist in the form traversed by Find/Replace until the containing window or template is opened. That explains a specific split seen in later 8.1 versions: a closed window could be found by an object or template instance name such as AnMon 2, while a custom template property named path containing TT111 was found only after opening the window.

1. Identify whether the target text is a resource/object name, a standard component property, a binding, a script, or a custom template property value.
2. Search a known closed resource with the narrow Project Browser selection.
3. If the custom value is missing, open the window and every referenced template needed to materialize that property.
4. Repeat the same token with Opened windows or the explicit selected-resource command.
5. Compare the result count and resource paths. A match that appears only after opening identifies a loading limitation, not a malformed search string.

Opening every resource can consume substantial Designer memory because the operation constructs component trees and serializes dynamic state. Work in controlled batches. Static scripts, ordinary tag paths, and component names may remain searchable while custom template values do not, so record coverage by property class rather than assigning one pass/fail status to the entire project.

How can XML provide a project-wide fallback?

The Vision Resource Encoding setting can store resources as XML, making their serialized text searchable outside the Designer. The setting is anterograde: changing it affects resources as they are resaved; it does not automatically convert every existing .bin resource.

1. Set Resource Encoding to XML in the Vision settings.
2. Open each required window and template, close it, and select Yes when prompted to commit changes.
3. Save the project. Confirm that the targeted resources have been converted from .bin to .xml.
4. Search beneath C:\Program Files\Inductive Automation\Ignition\data\projects with a file-content search tool. Use the old token as an exact string and review every match before changing it.
5. For the lower-risk workflow, use the file search only as an inventory and make each edit in the Ignition Designer, where property and binding editors can validate the resource.
6. If external replacement is required, close conflicting Designer editors and preserve a restorable copy of the affected project resources before editing.
7. Request a project filesystem scan by calling system.project.requestScan() in gateway scope, or wait for the gateway filesystem scan, reported as occurring every five minutes.
8. In the Designer, select Update Project or press Ctrl+Shift+U, then save.

Restarting the Designer and gateway is not required merely to detect external project-file changes. The scan plus Designer update is the relevant path. External text replacement still requires close review because a syntactically valid substitution can target the wrong property, alter more resources than intended, or leave a tag path that resolves to no tag.

How should the software-version decision be made?

The broad-scope regression reported in 8.1.27 b2023042509 was identified as fixed for 8.1.28. Returning to 8.1.26 also restored the earlier behavior in the affected installation. Those facts address the version-specific failure where broad searches returned nothing while an explicit Project Browser selection worked.

Later observations in 8.1.44 and 8.1.48 show that a successful move beyond 8.1.27 does not eliminate every Find/Replace failure mode. Closed-resource dynamic values can remain unavailable, and an individual resource can still interrupt a large search. Treat the 8.1.28 fix, the Vision dynamic-property limitation, and damaged-binding traversal failures as three separate branches.

1. Before changing versions, record a known token, its exact resource locations, selected-resource result count, broad-scope result count, and console output.
2. Apply the approved upgrade or rollback using the project’s normal change-control and backup process.
3. Open the same project with the matching Designer version.
4. Repeat the fixed test matrix: selected known resources, opened resources, and all windows.
5. Confirm that replacement changes only the intended paths, then validate that each edited binding resolves to the renamed tag.

FAQ