Ignition Multistate Indicator Loses Binding on Component Rename

Symptom Signature and Affected Setup

A Vision window that was copied from a working project, with only the tank's tag bindings and position changed, loads with an error on the multistate indicator's property binding. The indicator's state no longer follows the tank. In one observed case it displayed 14 where the configured states run 1 to 4. The Designer reports:

SerializationException: Error invoking [BoundVariableExpression]com.inductiveautomation.factorypmi.application.binding.expression.BoundVariableExpression@53112a62.setPropertyListener() caused by IllegalArgumentException: wrong number of arguments

Observed environment: Ignition v8.1.45 (b2025010709), Java Azul Systems 17.0.13. The window was built or modified by editing the window XML directly and pasting or importing it back into the Designer.

Check 1: Exception Text in the Designer Console

Before anything else, open the Designer output console and read the full exception chain. Do not start editing bindings until you know which component and property it names.

1. Reopen the window and capture the first SerializationException.
2. If the inner cause is setPropertyListener() with wrong number of arguments, a bound expression tried to attach a listener to a property path that did not exist when the window was deserialized. Go to Check 2.
3. If the error names a null property name, or fails before any binding listener is attached, the XML structure itself is damaged. Go to Check 4.

Here is why this matters. In Vision, an expression binding that references another component, such as {Root Container.Cylindrical Tank.value}, does not store a live object reference. It stores a path string. On load, Vision walks the container hierarchy by name, finds the target, and registers a property listener. If the named component does not exist at that moment, the listener cannot attach. Vision then logs the error and discards the listener, which removes the binding.

Check 2: Component Names Against the Binding Expression

1. Open the Project Browser and expand the root container. Read the exact name of each tank component.
2. Open the multistate indicator's state binding and read the component path inside the expression.
3. Compare the two strings character by character.

What each outcome means:

• Names match: the reference is valid. Look for a property name that no longer exists on the target component, or go to Check 4.
• Tank is now Cylindrical Tank 1 and the expression still points to Cylindrical Tank: this is the root cause. Go to Check 3.

The rename behavior is repeatable. When the window XML was imported into a brand-new, empty window, Cylindrical Tank came in as Cylindrical Tank 1. After the name was changed to Cylindrical Tank Test in the XML, it imported as Cylindrical Tank Test 1. A name collision does not explain this, because the target window was empty. The behavior points to a defect in how Vision sets items from pasted XML. Until the XML path is fixed in a release you have tested, treat any name inside hand-built XML as unreliable. Anything that references a component by name can break on import.

Check 3: Binding Presence After Load

1. Select the multistate indicator and open the binding on its state property.
2. If the binding type shows None, or the expression is empty, Vision already removed the listener. Saving and re-exporting will not bring it back. An export of the window taken now shows the expression as blank.
3. If the expression is present but still references the old name, the binding is present in the editor but will fail again on the next load.

Resolving branch for a one-off window:

1. Rename the tank component in the Designer so its name matches the expression, or leave the new name in place.
2. Delete the text of the multistate state expression and rebuild the reference with the property browser button in the expression editor. Do not type the path by hand. The browser inserts the current component path.
3. Save the project. Close and reopen the window. Do not move on until the console shows no SerializationException on open.
4. Export the window and confirm the expression text appears in the export. A blank expression in the export means the binding did not survive the save.

A clean window can also be restored from an export taken from a working Designer session, as opposed to raw XML. Then re-point only the tank bindings inside the Designer.

Check 4: Hand-Edited Binding Types in Window XML

Consider this change set, all made directly in the XML:

• Remove the capacity expression binding to 10000.
• Add a capacity expression binding to {[default]Local_Tags/A1}+{[default]Local_Tags/A2}.
• Remove the value expression binding to {[default]1_A1-1_A10/1_A1}*{[default]1_A1-1_A10/1_A2}.
• Add a value tag binding to [default]Local_Tags/A1.

These edits produced a deserialization error, and a separate attempt produced a null property name error. The Vision window XML is the serialized form of the internal Java component and binding objects. It is not a documented configuration format. An expression binding and a tag binding serialize as different object types with different fields and listener wiring. Swapping one for the other by editing text is likely to leave the structure incomplete or inconsistent. A diff tool can confirm that you changed only the intended lines. It cannot confirm that the result is a valid object graph.

Decision:

• If the change is one-time, make it in the Designer binding dialog and export the window afterward.
• If the change must be repeated across many tanks or windows, stop editing XML and go to Check 5.

Check 5: Window Generation as the Real Requirement

When the underlying goal is to place and bind tanks from an external program, do not generate or modify window XML at all. The Vision window serialization layer carries significant technical debt and is not designed for programmatic authoring. Creating new windows at runtime is also unsupported in practice. Use the dynamic layout components instead:

The external program's job is to produce data, such as a CSV or dataset, and not a window. On Vision clients, a practical pattern is for the window to call a local executable or read a file to fetch placement data, then write that data into the canvas or repeater dataset.

Template parameters can carry tag paths. A tag path is just a String parameter. Binding a property directly to template.tagpath returns the path text, not the tag's value. The tag lookup requires an Indirect Tag binding.

Procedure: Tank Template With Indirect Tag Path

1. Create the template. Add the tank, multistate indicator, and any sliders inside it. Set a fixed template size that matches your canvas cell. Confirm: the template opens in the template editor with no console errors.
2. Add parameters. Add a String template parameter for the tag path, for example tagpath, and one per additional tag if the tank needs more than one (value, capacity). Keep the parameter names identical to the dataset column names you plan to use. Confirm: add a temporary label bound to the parameter and check that it shows the exact path string.
3. Bind the tank value indirectly. On the tank's value property, choose Indirect Tag. Enter {1} as the entire path. In the references table, bind {1} to the template parameter. Confirm: with a known-good path such as [default]Local_Tags/A1 in the parameter, the tank shows the live value with no bad-quality overlay.
4. Bind writable components bidirectionally. For a slider that writes to the tag, use the same indirect binding and enable the bidirectional option in the binding dialog. Confirm: moving the slider changes the tag value in the Tag Browser.
5. Drive the multistate from inside the template. Bind the multistate state to the template's own properties or to an indirect tag, not to a component path outside the template. Names inside a template are fixed at design time and are never renamed by an XML paste. Confirm: the displayed state stays within the configured state values.
6. Place instances. For a repeater, build a dataset with one column per parameter name. For a canvas, build the instance dataset in script, one row per tank with position, size, and parameters encoded with system.util.jsonEncode. Confirm: each instance renders at its position and shows its own tag's value.

Verification of the Indirect Binding

If an indirect binding does not connect, as in the slider that would not link while other sliders bound to the same tags worked, check these in order:

1. Resolved string. Read the temporary label bound to the parameter. It must include the provider prefix, for example [default], and match the Tag Browser path exactly, including folder separators and case. Copy the path from the Tag Browser rather than typing it.
2. Reference wiring. Reopen the indirect binding. {1} must appear in the path field and must have a reference row bound to the template parameter. A literal path with no reference, or a reference whose index does not appear in the path, resolves to nothing.
3. Parameter value at runtime. Template parameter defaults apply in the template editor. The instance on the window or canvas must receive the value. Check the instance's parameter in the property editor, or check the dataset column feeding the repeater or canvas.
4. Tag quality. Watch for the bad-quality overlay on the bound component. An overlay with a correct-looking path means the tag does not exist at that path under that provider.
5. Write path. For sliders, confirm bidirectional is enabled and the tag is not read-only. Then move the slider and read the new value in the Tag Browser.
6. Reload test. Save, close, and reopen the host window. The console must show no SerializationException, the tank must show the live value, and the multistate state must match the tag-driven condition.

FAQ