Inspection step variables disconnected on edit: how to keep them wired

You add one variable to a working inspection, and a step that has run for months comes up with two inputs unchecked in its input/output dialog. The variables still exist; the wires are gone. Nothing errors, because the step keeps executing on whatever those empty inputs resolve to. This page is for anyone maintaining configured inspection scripts — arithmetic and pass/fail steps that consume named inspection variables — on smart cameras and vision controllers. You will get the mechanism behind the drop (connections are stored and re-linked by name), the edit sequence that prevents it, the repair for a script that has already lost wires, and the checks that prove the step is trustworthy again.

The symptom: fine until you edit

The script runs clean, cycle after cycle. Then you open the configured arithmetic step to add one input, and the input/output list shows previously wired variables unchecked. Rechecking them re-adds the connections, but at the end of the list and in the wrong order, so the expression now reads the wrong wires. Until you touch the step, everything works: the wiring is stored in the step's saved configuration, and the drop happens when the editor rebuilds the list at open time.

The custom user interface fails one level up in the same way. You edit the interface file, run the inspection, and the changes do not appear until you break the link to the file and relink it — and the relink can drop the UI-bound variables too.

Likely causes, most probable first

All four have the same shape: the consumer holds a stored reference that no longer matches what the editor rebuilds from the current names, and the rebuild is the moment the box comes unchecked. The rename case is the one with a documented fix history — later editor releases refresh the names and keep the selection — but re-linking by name remains, so the discipline below works on any version.

What a dropped wire actually computes

Take a worked example: a milled slot checked for width. Example recipe values: nominal 24.50 mm, tolerance ±0.15 mm; the part in front of the camera measures 24.62 mm.

Wired correctly: margin = |24.62 - 24.50| = 0.12 mm, and 0.12 mm is within the 0.15 mm limit, so the part passes.

Drop the width wire so the input resolves to 0: margin = |0.00 - 24.50| = 24.50 mm, which is above the limit — every part fails and the line stops. Annoying, but safe.

The expensive case is the tolerance wire. Say the editor leaves the previous recipe's 0.50 mm wired where the new 0.15 mm belongs: 0.12 mm passes, and so does the 24.80 mm part the tighter limit was installed to catch, because |24.80 - 24.50| = 0.30 mm still sits under 0.50 mm.

A dropped wire never announces itself; it quietly moves the decision boundary.

The edit sequence that keeps the wires

1. Export and save a dated copy of the script before touching anything.
2. Screenshot every configured step's input/output dialog. The checked order is your map when something rechecks in the wrong place.
3. Create all new variables first, in steps above the consumer. If the value comes from a measurement, set the variable in that measurement step itself.
4. Open the consumer and change one thing per pass: recheck any missing boxes in the screenshot's order, add the new input, wire it, close the dialog.
5. Run one cycle on a known-good part and read each variable live: width 24.62 mm, nominal 24.50 mm, tolerance 0.15 mm — not zeros, not leftovers from the previous recipe.
6. Save a new version and note the change in one line, so the next engineer sees why the step changed.

Scale the audit to your script: a 40-step program with 6 configured steps averaging 5 wired inputs holds 30 connections. At an assumed 20 seconds each to check against the screenshots, one full pass is 30 × 20 s = 600 s, ten minutes. That is the whole price of never trusting a stale wire.

Order sensitivity is not unique to variables. Camera set-up has its own sequence trap — exposure applied after streaming starts — covered in set manual exposure before streaming: initialization order. Editing while the line runs adds a second layer: changes can sit as pending until you commit them at a stop, the same trap PLC programmers clear with fix for online edits stuck as pending in a running program.

Renames: never rename, repoint

Renaming is the confirmed trigger, and renaming a measurement step renames its results too — every consumer holding the old string desynchronizes at once. The safe pattern:

• Keep the old name in place. Create a new variable with the correct name in the same step that sets the old one.
• Wire the new name into each consumer deliberately, one input at a time.
• Run both values in parallel for one cycle and confirm they match.
• Delete the old variable only when nothing references it any more.

The pattern costs one extra variable for a few cycles. A rename costs an afternoon of hunting every wire that quietly went stale.

Custom interface changes that do not refresh

Two workarounds, in order of reliability:

1. Change the interface file in a way the importer cannot miss: resize the panel. The size change forces the editor to import the modified file on the next run and leaves the existing link untouched.
2. Break the link to the custom file, run once on the built-in interface, then relink your file. This also forces a re-import, but the relink can leave UI-bound variables unchecked — recheck them against your screenshots before trusting the interface.

After either fix, run one cycle and confirm each displayed value moves when the part changes. An interface showing stale numbers is worse than none.

Where the script lives: camera or controller

The discipline is identical on both. What changes is how many people edit the file, and how much processing one box carries.

For a single-camera check, keeping the whole script on a smart camera makes the file the one artifact to back up. The smart cameras range runs inspection on the device, and the camera finder filters it by resolution, interface and shutter. The MV-SC5060XM-08M-WBN pairs a 6 MP mono sensor with a fixed 8 mm M12 lens over GigE; its rolling shutter suits parts that sit still at exposure.

When several cameras feed one decision, move the script to the hardware built for it: vision controllers. More people edit there, so the backup-and-screenshot habit matters more, and the processor headroom lets you split an overloaded step into several small ones. The MV-VC2140-128G40-1T gives you 3-4 LAN ports for cameras, 4 built-in light channels and 8 GB of memory.

How much processing stays on the camera is its own sizing question; on-camera image processing: what can you offload sets the boundary.

Prevention: the ten-minute audit

Run this monthly and after every recipe change:

• A dated export stored where the next shift can find it. The fastest repair is usually rollback, not rewiring.
• A screenshot of each configured step's dialog, checked boxes in order. Order is what silently changes.
• No renames, anywhere, ever. New name plus deliberate repoint, every time.
• Every variable set above every consumer. Creation order is what the stored selection assumes.
• A known-good and a known-bad part run after any edit. One proves the pass path; only the other proves the fail path.

And after loading a saved version back onto the line, watch the first cycles: load-time behavior has a failure mode of its own, covered in why a smart camera misses its first images after load.

When to rebuild instead of repair

If more than two or three inputs come back unchecked, or a recheck lands wires in the wrong place twice, stop patching. Delete the step and rebuild it in one pass: create the inputs, retype the expression, wire from the screenshot, run one cycle. Five minutes, and every wire is fresh and known.

Split while you are in there. One step computing four comparisons is one place for four silent failures; four steps with named intermediates — for example slot_margin, slot_pass, slot_reason — turn any future disconnection into one visibly wrong intermediate value. Each scalar step costs microseconds of compute, so the split adds no measurable cycle time.

If the script leans on variables that carry state between steps and cycles, the durable structure is a routine that owns its values rather than loose globals; refactoring global variables into a stateful routine walks through that migration step by step.

The decision, per case: one camera and a small script — stay on the camera, apply the sequence, audit monthly. Several cameras or a script someone else wrote — move it to a controller and audit before the first production cycle after any edit. A step already broken beyond three wires — rebuild it, never patch it.

Planning a move from camera to controller? Build a system steps through camera, lens, light and controller in order, and more run-and-maintenance fixes sit in the systems topic guides. If a script keeps losing wires and the sequence above does not hold it, bring the exported script and screenshots to the applications team via the contact page.