Configuring Ignition Vision XML Encoding for Window Analysis

Where does a Vision window actually live, and why is window.bin opaque?

Start with the data path. When you save a window in the Designer, the Designer serializes it and pushes it to the Gateway. The Gateway writes it to its project directory on its own filesystem. In a default project, each window's content lands in a window.bin file. The Designer that edits the window can run on a different computer from the Gateway that stores it. Any tool you build has to decide which end of that path it reads from:

• Gateway end: the files on disk, either live or inside a gateway backup.
• Designer end: the deserialized, live Swing component tree of an open window.

The .bin encoding has no published specification, and no supported way exists to read objects or tag references out of it directly. Treat it as a closed container. To get at a window's contents programmatically, you have two options: make the Gateway store it in a readable format, or read it after the Designer has deserialized it.

Which approaches exist for inspecting or modifying windows programmatically?

The criteria that decide the choice are:

• Do you need to read (inventory, audit, cross-reference tags) or write (create and modify components)?
• Does the job have to run without a person at the Designer?

Reading at scale belongs at the Gateway end in XML. Writing belongs at the Designer end, with an engineer opening the window.

How does the XML encoding setting change what the Gateway stores?

The setting lives in the project, not in the Gateway web configuration. In the Designer, open Project Properties -> Vision -> General -> Resource Encoding. It has three values:

The setting acts at serialization time. Changing it does not rewrite resources already on disk. A window only converts when the Designer re-serializes it, which means you open it and save it. A project with 200 windows where you changed the setting and saved three will have three XML windows and 197 .bin windows. Templates follow the same rule.

No separate backup option exists. A gateway backup copies the project files as they sit on the Gateway filesystem. After you open and re-save every window and template under the XML setting, every backup you take contains XML for those resources. Resources you did not touch remain binary in the backup too.

What do the symptoms mean when the XML does not show what you expect?

How are components and tag bindings laid out inside the XML?

The XML format is an internal implementation detail. It is convoluted, and there is no public documentation for it. Build your parser from observed structure, and expect it to break across major versions. The key structural fact is this:

• A window whose components have no bindings serializes roughly as a tree of containers and components.
• Once a component has a binding, it is encoded together with the window's InteractionController instead of appearing as a plain node in that tree.

A naive walker that descends the container hierarchy therefore finds unbound components and silently skips the ones you care about, the bound ones.

Reverse-engineer the mapping on a controlled sample before you run anything across a project:

1. Create a scratch window with one Label and no bindings. Save it and capture the XML.
2. Add a tag binding to the Label's text property. Save it and capture the XML again.
3. Diff the two files. The added region shows how the InteractionController carries the binding and how it references the component.
4. Repeat with an expression binding, a property binding, and a nested container. This maps each binding type you need to recognize.

For a first-pass tag inventory, skip the structure entirely. Scan every text node and attribute for strings shaped like bracketed-provider tag paths. This catches bindings wherever the encoder put them. The structural pass is only needed to attach each tag to a component name.

The script uses the gateway backup as an archive because the backup is a filesystem snapshot. Point the same logic at a copy of the project directory if you have filesystem access to the Gateway. The STILL BINARY lines double as your conversion checklist.

When is Designer scripting the better path?

Script the Designer when you need to modify windows, or when the XML structure gets in the way of reading them. After the Designer deserializes a window, it is a real Swing component hierarchy with typed properties. Walking getComponents() and reading properties is far simpler than decoding the InteractionController layout in XML.

Two hard limits apply:

• The window must be open. The Designer only holds live objects for windows open in its workspace. Closed windows are still serialized resources.
• Nothing runs by itself. No out-of-the-box mechanism exists to auto-run Designer scripts. That includes Designer startup events, file watchers, or a script that waits for a parameter file and then edits and saves the project. Every run starts with a person at the Designer.

A file-watcher design also has a location problem. The Designer's host filesystem and the Gateway's filesystem are frequently different machines. A trigger file dropped next to the Designer tells you nothing about where the project resources live, and the reverse is also true.

A generic recursive walker for an open window's root container (standard Swing API, runnable from the Designer Script Console once you hold the root container reference):

def walk(comp, depth=0):
    print('  ' * depth + comp.getClass().getSimpleName() + '  name=' + str(comp.getName()))
    for child in comp.getComponents():
        walk(child, depth + 1)

Get the root container reference from the open window in the Designer workspace. The accessor depends on the Designer API of your Ignition version, so check the SDK Javadocs for that version. Binding metadata is not stored on the Swing component itself. It sits with the window's interaction controller in memory, just as it does in the XML.

Which approach should you use for a bulk read-and-modify job?

Split the job along the data path:

• Read at the Gateway end in XML. Set Resource Encoding to XML, re-save every window and template once, and run inventory and tag cross-reference scripts offline against backups. This part can be scheduled, because it never touches the Designer.
• Write at the Designer end with a person in the loop. Generate the change list offline from your parameter file and the XML inventory. Then have an engineer open each affected window and run a Script Console script that applies that change list to the live Swing objects, and save.

Do not hand-edit XML on the Gateway filesystem as your write path. The format is undocumented. Bound components carry cross-references through the InteractionController, and a malformed edit can leave a window that will not deserialize. If you experiment with it anyway, work in a scratch project restored from a backup.

Reports get neither path. There is no Resource Encoding option for reports and no human-readable form underneath, so report inspection and editing stays manual in the Designer.

Procedure:

1. Take a gateway backup before any change, and keep it as the rollback point.
2. In the Designer, open Project Properties -> Vision -> General -> Resource Encoding and change it from Auto to XML. Save the project.
3. Open every window and every template, save each one, and close it. Repeat for every project that must be analyzed; the setting is per project.
4. Take a new gateway backup and copy it to the analysis machine.
5. Run the offline scanner. Resolve every STILL BINARY line by returning to step 3 for that resource.
6. Build the component-to-tag map using the structural rules you derived from the scratch-window diffs.
7. For modifications, produce a per-window change list. Open each target window in the Designer, run the walker plus your edit logic in the Script Console, and save.
8. Take a final backup and rerun the scanner to capture the post-change state.

How do you verify the conversion and the extracted data?

1. Encoding check: in a fresh backup, count .bin files under the Vision resources. The target is zero for windows and templates. Any remaining file is a resource that was not re-saved.
2. Round-trip check: open three converted windows in the Designer: one with no bindings, one with tag bindings, one with nested containers. Confirm each renders and its bindings resolve. This proves the XML-encoded resources deserialize cleanly.
3. Parser coverage check: on the scratch window with a known set of bindings, confirm the scanner reports exactly the tag paths you bound. If a bound tag is missing, your parser is reading the container tree and skipping the InteractionController.
4. Cross-check against the live Designer: for one production window, compare the XML-derived component list with the Script Console walker output on the same open window. The component names and count must match.
5. Post-modification check: after Designer-side edits, take a backup and rerun the scanner. Diff its output against the pre-change inventory. The only differences should be the components and tag paths listed in your change list.

FAQ