Vision result stale every cycle: trigger a fresh measurement per pick

The robot drives to the same spot on the belt every cycle, the part has moved, and the part-detected flag sits at 1 even over an empty belt. That behaviour is not a faulty sensor. It is a latched result: the vision job ran once, the controller was handed a stored answer, and nothing in the program has asked for a fresh one since. The sections below give the signature, the five likely causes in order of probability, a five-step handshake that re-triggers the measurement on every pick, the cycle-time cost, and the empty-belt test that proves the fix.

The signature of a latched result

Four signs together point at a latched result rather than a camera or optics fault:

• The configuration tool's live view still locates parts correctly whenever you look at it.
• The pose the robot receives never changes within one program run, even when you shift the part between cycles.
• The flag you set back to 0 at the end of the program flips to 1 again the moment the locate node runs — with the belt empty.
• Stopping and restarting the program produces exactly one fresh result, and then the freezing starts again.

The last sign is the diagnosis. A restart re-executes the vision node once, so the sensor measures one new image; that answer is then stored and replayed until the next restart. The sensor is doing what its outputs are designed to do: hold the last job result until a new job run overwrites it. What is missing is a command, once per pick, to run the job again.

The empty-belt side of this flag has its own page — Vision locate with a part detected flag variable: stop the empty belt. This page assumes the locate itself is sound and the handshake is what leaks.

Likely causes, in order of probability

Work down the list; the first two cover most cells that run correctly once and loop badly.

1. The locate node sits outside the loop. If the program calls the vision node once before the loop starts, every iteration reuses the same variables. Test: open the sensor's live view and let the program loop ten times — if the image or its frame counter stops advancing after the first pass, nothing is re-triggering the job. Fix: move the acquire-and-locate node inside the loop, directly before the robot move that consumes the result.

2. The node reads a stored result instead of commanding a measurement. Many plug-in layouts separate the node that starts a job from the node that reads its result, and a move-to-camera-position node (one plug-in names it MoveToCamPos) can act as a pure reader after its first execution. Test: place an acquire node in the loop ahead of the reader; if results start updating, that was it. Fix: every path through the program that consumes a pose must pass through an acquire first — including the second and third pick in one program run.

3. The done flag is never consumed. The sensor sets a job-done or result-valid output when a run finishes, and a node linked to a pendant variable writes that stored state every time it executes — which is why your cleared 0 turns back into a 1. Test: log the flag against the cycle counter for ten cycles; a flag that never drops was never acknowledged. Fix: the handshake in the next section.

4. The discrete trigger is level-sensitive where you need an edge. A trigger input held high for a whole cycle counts as one trigger event, not one per pick. Test: read the sensor's internal trigger counter after three cycles and compare it with three. Fix: pulse the line for 10-20 ms per pick and check the edge setting in the sensor's I/O configuration.

5. The network session dropped mid-run. Triggering over Ethernet depends on the session staying up, and a silent timeout leaves the last result in place. Test: keep a continuous ping running through a full program run and scan the controller log for communication faults. Fix: a hardware trigger wire is immune to network trouble, and the socket layout later on this page removes the plug-in's session handling altogether.

The fix: clear, trigger, wait, copy, clear

Whatever the cause, the cure is an explicit handshake that runs on every pick, in this order:

1. Clear before you trigger. Set your result-valid variable to false, and send the sensor's acknowledge or reset command if it exposes one. You are marking the previous answer as consumed before asking for the next.
2. Trigger exactly one measurement. Call the plug-in's acquire node, send the trigger command over the socket, or pulse the discrete trigger input for 10-20 ms. One trigger, one image, one job run.
3. Wait for done with a deadline. Poll the job-done or result-valid flag in a loop with a timeout of 500 ms, which covers a locate that normally takes under 100 ms with margin to spare. On timeout, treat the cycle as no part found instead of reusing the old pose.
4. Copy the result into your own variables. Read the pose once into variables declared for this cycle, then move using only the copy. The robot never references the sensor's buffer directly.
5. Clear again before the loop returns. Reset the flag and the result variables, so no stale value can survive into the next iteration.

The variable names in this sketch are illustrative; the sensor-side flag names come from your sensor's own interface description.

bool  resultValid = false           // your flag, reset at every loop start
float partPose[6] = {0,0,0,0,0,0}   // your copy of the located pose
int   timeoutMs   = 500             // deadline for the wait in step 3

resultValid = false
sendTrigger()                       // acquire node, socket command or output pulse
while (not doneFlag and elapsedMs < timeoutMs)
    wait 5 ms
if doneFlag:
    partPose    = sensorPose        // copy once; move with partPose only
    resultValid = true
doneFlag = false                    // consume the flag so old data cannot look new

Worked example: what the handshake adds to the cycle

The handshake costs one measurement plus one controller scan. Time a measurement as:

Take a strobed exposure of 2 ms, an on-board locate of 70 ms on a 1.6 MP frame, and an 8 ms reply across the network:

t_result = 2 ms + 70 ms + 8 ms = 80 ms

Add one controller scan of 10 ms for the copy in step 4 and the whole vision step lands at 90 ms per pick. On a 2 s pick-and-place cycle that is 90 / 2000 = 4.5% of the cycle — modest overhead for never picking at last cycle's pose.

The locate term dominates, and it is the one you control: search time scales roughly with search area, so cutting the search region to a quarter drops that 70 ms term to about 18 ms and t_result to roughly 30 ms. A 10-20 ms trigger pulse and a 5 ms poll interval add nothing worth counting. These are example inputs for a single-part overhead scene; most configuration tools print the job's own execution time per run, so measure yours once and put the number in the cycle budget.

When the plug-in will not let go: drive the sensor over a socket

If the handshake is correct and the replay continues, the plug-in's own session handling is the remaining suspect. Take it out of the path: open a TCP socket from the robot program, or from a small program on a controller, send the sensor's trigger command, and parse the pose fields out of the reply yourself.

You gain three things: the measurement happens exactly when your code says, you read only the fields you need, and the handshake sits in plain sight in your program instead of inside a node. The command set and reply format come from the sensor's interface manual; the pattern — connect, trigger, wait for done, parse, keep alive — repeats across every vision sensor with a service port. The register-level version of the same idea is in Access GigE camera registers at runtime from your control code.

Two details matter once the plug-in is gone. The job inside the sensor must load by itself at power-up, so switch the auto-load setting on — Set your vision sensor to auto load its job on startup walks through it. And park the sensor on a private switch with fixed addresses, so a plant DHCP server cannot move it mid-shift.

If the robot cannot open sockets, or you would rather keep the handshake out of the robot program, put a fanless vision controller between sensor and robot and let it run the client — the vision controllers range is built for exactly this. A model such as the MV-VC2140-128G40-1T carries 3-4 LAN ports, 2 USB 3 ports, 4 built-in light channels and 8 GB of memory, so the same box drives the socket client and a strobed light on the trigger edge.

Sensors that take a trigger and run the locate on board

The handshake needs three abilities from the sensor: it runs its locate job on board, it accepts a software trigger over Ethernet, and it takes a discrete trigger edge. Filter the smart cameras and vision sensors by shutter, resolution and mount, or use the camera finder on the shop side.

Prefer a global shutter: the exposure lands while the belt moves and the robot reaches, and a rolling shutter smears a moving part into a pose error. For a single overhead locate, the MV-SC3050XC-16M-ATN-H — 5 MP, color, global shutter, M12-mount — leaves resolution to spare for two pick points in one frame.

If one fixed shot covers the whole part, an integrated-lens vision sensor keeps the wiring down to a power drop, an Ethernet line and the trigger pair:

The MV-SCB007EC-12S-WBN integrates a 12 mm manual-focus lens, and the mono HK-TD032-12-WBN sits beside it in the same resolution class. The MV-SCA002M-03S-WBN-SR pairs a 3 mm lens with fixed focus at 240 mm; mount it close over the part and the focus stays put for the life of the cell.

Prove the fix, then keep it proven

Run three tests before calling the job closed:

1. Empty belt, ten cycles. Nothing in the field of view. Pass means the flag stays 0 for all ten and the robot takes its no-part path — the program-level handling is in Vision no part error: restart the robot cycle with ExitCycle. A flag that still sets now means a false detection, not a stale result: darken the cell and recheck exposure before touching thresholds — Ambient light variation in pick and place vision: control it lists the usual offenders.
2. Moving part, ten cycles. Shift the part a few centimetres each cycle and mark the true position. The robot must land within a few millimetres of the mark every time. A pose that lags the part by a fixed amount is trigger timing on the belt instead — Conveyor vision scene timing: troubleshoot stale pick data is the companion page.
3. Counter check. Trigger counter and cycle counter must finish equal. Any divergence marks the exact loop where a measurement was skipped.

Keep both counters on the pendant permanently; they cost one integer each and turn next month's mystery stall into a five-minute diagnosis. After a robot fault or a controller reboot, the handshake starts from zero — Vision job lost after a robot fault: re-handshake at cycle start covers the recovery, and the habit of testing from a known sensor state comes from 3D camera test flaky on leftover settings: start from a known state.

If you are specifying the station rather than repairing one, start from the sensor category and finder above, add the controller card when the handshake moves off the robot, and send the trigger, cycle-time and field-of-view numbers to us through the contact page — we will lay out the handshake with you.