Inspect results from each vision engine: a tag probing method

A four-engine inspection station rejects a good part and the only signal you have is one red verdict bit. Which engine disagreed, by how much, and on which part: none of that reaches the PLC. The fix is a probing method you build into the program itself. Give every inspection engine its own named result tags, copy those tags into shared debug variables, and poll and log the variables from one loop in the main program. You end up with a per-part, per-engine record that turns "the station failed" into "engine 3 scored 0.71 on part 4512". The same steps work on a smart camera that inspects on the device and on a vision controller running several engines.

Why the final verdict hides the fault

The verdict bit is every engine's pass-fail output folded through your verdict logic. Four different faults produce the same red bit:

• A marginal engine. The score sits just above its threshold: 0.71 against 0.70. Most parts pass, then a slightly shinier one scores 0.69 and the station rejects.
• A stale tag. The verdict step read the previous part's result because a done flag arrived late or was never cleared. The stale result, fresh measurement per pick article walks that trigger-side fix.
• An unlit image. The engine exposed before the strobe fired and scored ambient light, so the part carries a fault it does not have.
• A wiring fault. An edit disconnected or renamed a variable, and the verdict step is combining yesterday's values; the disconnected inspection step variables article covers that failure.

Each fault has a different fix, and the verdict bit cannot tell them apart. The probe can, because it records what every engine actually computed.

What you need

• Edit access and a shared-value layer. Nearly every engine-based runtime has one: a global variable list, a shared-variable library or an on-device tag table. If your smart camera already publishes scene results to script, that publication is your tag source — the smart camera scene result variables article shows how to read them.
• A part identity. A PLC part ID, an encoder tick or a counter incremented per cycle. It is the join key that ties three engine rows to one physical part.
• A log file. CSV on the camera or controller is enough at production rates; the worked example below lands near 10 MB per shift.
• Hardware matched to where the engines live. On a camera that inspects on the device, the probe lives in the same program. A 5 MP color global-shutter vision sensor like the one below handles a typical presence, orientation or label check and exposes its result variables to the runtime.

When the checks are split across several cameras or engines, a vision controller hosts the runtime where all the tags meet. The VC5000 model below carries PoE camera ports and 8 built-in light channels, so one box covers the cameras and the per-engine strobes.

Step 1: give each engine its own named result tags

1. List what each engine already writes: score or measurement, pass-fail bit, found position X and Y, and angle. That is the minimum set.
2. Add the three values engines rarely publish but debugging always needs: execution time in milliseconds, a done flag, and the part ID. Without the part ID you cannot prove that a failing row belongs to the part the PLC rejected.
3. Namespace the set per engine — Eng1_Score, Eng1_Verdict, Eng1_X, Eng1_Y, Eng1_Angle, Eng1_ExecMs, Eng1_Done, Eng1_PartID. Those names are examples; keep your runtime's convention, but keep one set per engine instance. Two instances writing one shared tag produce overwritten values, which are indistinguishable from wrong ones. The same rule that gives each add-on instruction instance its own tag applies on the vision side.

Step 2: copy the engine tags into shared debug variables

1. Create one shared or global debug variable per engine tag, under a Debug_ prefix: Debug_Eng1_Score and so on. The engines keep writing their own tags every cycle; the debug set is the copy the rest of the program reads.
2. Write the values first and the done flag last. A reader that sees Eng1_Done true then knows the other values in that set are complete and belong together.
3. Copy, never move. The probe stays a lightweight layer you can delete after commissioning without touching inspection logic, and the inspection loop pays one write per tag per part — nothing more.

Step 3: poll and log from one loop

1. Add one loop that runs for the whole session, independent of trigger and engines. Keep the PLC handoff in its own path, as you would keep one poll loop for one PLC CPU.
2. Set the poll period to a tenth of the line takt: 100 ms for a station that inspects one part per second.
3. On each rising done flag, copy that engine's set into a log row: timestamp, part ID, score, verdict, position, angle, execution time.
4. Write one CSV line per engine per part. Keep image dumps out of the loop; log numbers every part and capture images by hand when a row looks wrong.
5. If you stream the tags to a dashboard, missing updates are a transport problem, not an engine problem — the missing MQTT engine tag updates checklist covers the usual causes.

The PLC still receives only what it needs. The match result to a PLC output article shows that handoff, and the pass-fail results, not images rule keeps the interface small enough to trust.

Worked example: poll rate and log size at 60 parts/min

Three engines, seven debug tags per engine, 8 bytes per value plus 8 bytes per timestamp, and a line feeding 60 parts/min:

Decision: poll at 100 ms and write one CSV per shift. A tag is never more than 100 ms old against a 1000 ms takt, a 10× margin, and 9.68 MB per shift needs no database and no rotation logic.

The same inputs scale linearly. At 120 parts/min the takt is 500 ms, the poll drops to 50 ms, and the log grows to 2.42 MB per hour — about 19 MB per shift. Still a CSV problem.

The rule runs out once a part occupies the line for less than one poll period. At 20 parts/s each part lives 50 ms, so a 100 ms poll samples every second part. Latch each done flag and copy the tags at that moment instead, or push rows through a queue; the get versus tryGet queue comparison shows both read patterns.

Step 4: judge each engine on its own numbers

Run 200 parts with the probe logging, then read the log engine by engine, not by verdict:

• Score margins. Sort each engine's score column. With a threshold of 0.70, a column whose worst passing score is 0.71 has a margin of 0.01, which is 1.4% of the threshold (0.01 ÷ 0.70 = 0.014). A part scoring 0.69 fails for glare, not geometry. Working rule: a pass margin under 0.05 on a 0-1 score is a marginal engine. Fix contrast, light or template first, re-log 200 parts, and only then reconsider the threshold.
• Execution time. A column that climbs from 45 ms at shift start to 95 ms four hours in points at queue buildup or a leak, not at the parts. Investigate any sustained rise beyond 2×.
• Flipped rows. A score that says pass beside a verdict bit that says fail is verdict-logic wiring. Score and verdict agreeing while the PLC still rejected is the handoff, not the engine.

Batch totals stay honest when counters reset at batch boundaries; the per-batch pass-fail counter reset article sets that up.

When every tag is right but the verdict still flips

Consistent scores and verdicts in the log, intermittent rejects on the machine: the engine computed honestly on a bad image. Two timing faults produce exactly that.

• The trigger reached the camera before the strobe fired, so exposure ran on ambient light. The symptoms are distinctive, and the flicker versus exposure diagnosis separates them.
• An auto mode moved exposure or white balance between parts, so identical parts produced different scores. Turn every auto mode off before drawing conclusions; the brightness drift article explains why.

The structural fix is one strobe channel per engine, fired between trigger and exposure, with the strobe-enable bit logged beside the tags. A digital light controller with per-channel strobing gives you that; the 4-channel, 200 W box below drives four engines from one unit.

Prove the probe works before you trust it

Four checks, on ten parts and one deliberate bad part:

1. The part ID advances by exactly one per part in every engine's set. A set that skips means its done flag never fired, and that engine's rows are missing from the log.
2. Feed a part that fails only engine 2's check: Eng2_Score must drop below threshold and Eng2_Verdict must flip while the other engines hold. If only the verdict flips, the score tag is wired to the wrong variable.
3. Stop the line between parts. Every debug set must hold the last completed part, never a half-written set; a half set means a done flag was written before its values.
4. Compare probe rows against the PLC reject counter over one batch. The counts must match exactly; a mismatch means a double-triggered part or a result consumed twice.

Common mistakes

• Polling faster instead of latching. A 10 ms poll hides the symptom and burns processor time; the done-flag latch fixes the ordering problem itself.
• Logging images every part. It turns a 9.68 MB per shift log into gigabytes and slows the loop. Capture images on demand.
• Stepping through engine code with breakpoints on a running station. The engine misses parts while halted and the PLC sees timeouts; the probe exists so you never halt a live engine.
• Changing threshold and lighting in the same afternoon. Change one, re-log 200 parts, then judge.

Which hardware fits which case

For a new station, size the camera with the camera finder, pick the controller from the vision controller category, and wire the probe in before the first production part. It costs an afternoon and settles most commissioning disputes with data instead of opinions.