Vision job lost after a robot fault: re-handshake at cycle start

A protective stop trips the robot, the motors drop, the operator clears the fault and restarts — and the first vision call after recovery fails, complaining that the connection is closed and asking for a valid job set with a valid active job. The pendant fix works, but at a few stops a day it is the operator doing the recovery instead of the program. This guide shows what actually breaks during the stop, three tests that separate the causes, a cycle-start handshake with a retry budget sized to your trigger window, and the point at which the hardware, not the code, is the answer.

What actually dies when a robot fault stops the cell

A protective stop or collision trip does three things at once. The servos power down. The cell's safety circuit often cuts 24 V to everything inside the guarded space, the vision sensor included. And the pendant's camera integration loses the single session it holds to the sensor over Ethernet.

The job files on the sensor survive all of that. What does not survive is the session and — if the sensor rebooted — the active-job selection it was running under. So the first trigger after recovery arrives on a dead socket, and a rebooted sensor comes up with no active job at all. That is the whole error: not a damaged camera, but a link and a selection that must be rebuilt before anything can trigger. The pendant's installation screen does that rebuild by hand; the rest of this guide moves it into the program.

Three causes behind one error message

Rank them by how often each turns out to be guilty:

1. The session died, the sensor did not. The fault closed the integration's connection while the sensor kept its supply and its job. The most common case, and the cheapest to fix: a fresh open plus two commands restores everything.
2. The sensor rebooted. The safety circuit dropped its supply. The job set is still stored, but the active-job pointer resets and the sensor needs its boot time before it answers anything. A sensor whose address does not come back after a power cycle stacks a second failure on top — the persistent IP address not retained after a reboot is its own fault with its own fix.
3. The program resumed past its own set-up. The operator restarts from the current line instead of from main, so the open and the job selection, which live at the top of the program, never run. The fault then looks random, because it follows where the pointer landed, not what the sensor is doing.

Three tests, five minutes

Run them in this order after the next stop:

1. Ping the sensor from a laptop or the controller once the motors are back. No answer means power or boot: wait out the boot and treat a missing address as a separate problem.
2. Open the sensor's own interface, the web page most vision sensors expose. If the page answers while the pendant still reports a closed connection, the sensor is healthy and the session state on the pendant is what died.
3. Read the active job in that same interface. Empty or reset to none means the selection died with a reboot or a session restart, so plan on a load and a select, not just a reconnect.
4. Check where the program pointer sits after the operator's restart. If it resumed below the set-up block, cause three is yours, and no amount of sensor-side work will fix it.

The fix: re-handshake at every cycle start

Put the recovery into the program's main routine, in this order:

1. Before any motion or trigger, close any old session handle and open a fresh one. A close error on a session that was not open is normal after a fault; ignore it and continue.
2. Send the job-set load command and wait for its acknowledgement. Retry twice at a 2.0 s timeout, then raise an alarm.
3. Send the active-job select and compare the acknowledgement against the job you expected, by name or index, not just an ok.
4. Arm the trigger only after both acknowledgements. Wrap the block in a watchdog that raises its own alarm code on timeout, so a stuck handshake is loud instead of silent. The vision project start stop handshake troubleshooting patterns map onto this block signal by signal.
5. Log every re-handshake. The commands are idempotent — when the link is healthy, a load and select that already match the running state acknowledge in milliseconds — so the block costs nothing in normal cycles. A count that climbs across shifts is measuring your collisions, not your code.

These are the same two commands a healthy job change uses, so nothing here is special to faults; the guide on switching vision jobs mid program without losing the camera socket covers the command side in depth. Once the block is in, the pendant visit disappears: the program performs the same load-and-select the installation screen does, before anything can trigger.

Sizing the re-handshake budget for a 6-second window to first trigger

The inputs, and where each comes from: the window from motor-on acknowledgement to the first image trigger is 6.0 s, set by the program's first approach move at reduced speed — your own program gives you this number. The open timeout is 2.0 s, a value you set in the handshake: generous against a one-switch subnet, short enough to fail fast. A successful open is budgeted 0.3 s including the integration's session set-up. The job-set load acknowledgement gets 1.0 s, the active-job select 0.5 s, and one retry is allowed on the open. These four times are budgets you assign; the arithmetic is what must hold.

The rule in words: the worst case is one failed open, then a successful open, then the two command acknowledgements. That total must fit inside the window with margin, or the handshake belongs in the start-up section rather than the trigger path.

The arithmetic: t_total = 1 × 2.0 s + 0.3 s + 1.0 s + 0.5 s = 3.8 s, and margin = 6.0 s − 3.8 s = 2.2 s.

The decision: from about 4.0 s of window upward, the in-line handshake with one retry always fits, with 2.2 s to spare in this case. Below roughly 4 s, move the block to start-up, before the robot leaves home, and keep only the trigger in the cycle path. One case no retry budget rescues: if the stop cut the sensor's supply, nothing answers until boot completes. Poll with ping every 2 s and alarm out at a 60 s ceiling instead of hanging the cycle inside the trigger path.

Make every restart land on the handshake

The block only protects the cell if it runs, and an operator under time pressure resumes from the current line. Two settings take that off the table. First, return the pointer to main at cycle start — controllers commonly expose a return-to-main setting on cycle start for exactly this situation. Second, verify the loaded job before the start signal is released; job verification before start is a configuration on several controller families, not an extra.

The no-part failure uses the same mechanism from the other side, and its fix composes with this one: the guide to restarting the robot cycle after a no-part error shows the controller-side cycle pattern that guarantees the entry block runs every cycle.

When to take vision off the pendant

If the cell trips often enough that every stop costs a camera visit, change the architecture instead of tuning the retry. Browse the smart cameras and vision controllers categories to see the two families side by side. Both moves below remove the fragile session from the robot's side of the fence.

Run the inspection on the device. A smart camera holds the job set and performs its own handshake, so a robot fault has no session to close and no selection to empty; the robot reads a result and nothing more. The LS-SMC-0063 carries its own 16 mm lens and white light, runs 60 fps over GigE, and covers fields in the up-to-3 MP class — a station in one housing.

Or keep the brains off the robot entirely. A vision controller survives robot faults because it was never part of the stop: it holds the camera sessions, the processing and the light channels, while the robot exchanges results with it over I/O or fieldbus. Pick one with enough LAN ports to give the cameras their own subnet.

The MV-VC2140-128G40-1T covers a small cell with 4 built-in light channels, 3-4 LAN ports and 8 GB of memory. The MV-VC3301H-128G66 steps up to 5+ LAN ports and PCIe expansion, comes without PoE, and includes a VM6200Pro license. Either one turns a robot fault back into a motion problem only.

Checks before you call it fixed

Work through this list once, on purpose, before trusting the fix:

• Trip a controlled protective stop at reduced speed with an empty gripper, recover, and restart from main. The log should show open, load, select and trigger with no operator touch.
• Pull the sensor's Ethernet plug at the switch for five seconds while the cell is idle. The watchdog should raise its own alarm code, and the next cycle start should clear it.
• Power-cycle the sensor with the cell off. The handshake should reload the job set without a pendant visit; if the address did not survive the power cycle, fix that first, because it imitates this fault exactly.
• Resume from mid-program once, deliberately. If the handshake is skipped and the error returns, the restart policy is open, not the vision code.
• Count re-handshakes per shift for two weeks. A count that keeps climbing means the collisions need their own investigation: approach speeds, grip force, or part presence sensing.

And when recovery goes half-right — images arrive but the picks do not follow — the restart handshake between vision and robot is the next place to look; the vision picking restart handshake guide walks that case.

When it is not the handshake

Ping alive, web page answering, a fresh open and select succeeding from a laptop — and the pendant still errors after every restart. Then the integration's own session state is the suspect: reset the pendant's camera configuration or update the integration by the sensor maker's documented procedure, and re-check the job references afterwards.

A sensor that vanishes from the network after a software error rather than after a robot fault belongs to a different family altogether; the GigE camera rediscovery after a resource error guide covers that recovery path, and its fix starts at the sensor, not at the robot.

Hardening the cell from here

If the cell stops rarely, the handshake block and the restart policy are the whole fix, and both cost nothing but program time. If stops are frequent enough that hardware is on the table, size cameras and controllers in the build-a-system configurator, and keep the neighboring failure modes in reach: calibration drift after a restart has its own diagnosis in the robot camera calibration guide, and the systems topic page collects the rest.