Vision no part error: restart the robot cycle with ExitCycle

Your robot picks a part from a loader, presents it to the camera, and the vision offsets drive the machining location. When the loader presents nothing, the camera reports no part — and the inline IF that retries the pick leaves the program pointer stranded after the block, so the cycle dies mid-program with nobody there to restart it. The fix is not another IF. Raise the error out of the vision routine, catch it at the top of the cycle, park the robot, and call ExitCycle: the program pointer returns to Main and the next start runs a clean pick. This guide gives the RAPID pattern for an ABB controller, the restart plumbing an unattended cell needs, and the tests to pass before lights-out.

Why the inline IF retry strands the program pointer

An IF statement lives in the happy path. When the camera reports no part inside that IF, you re-run the pick there; when the second attempt fails too, execution falls out of the block and carries on with the next line — often straight into the machining call with an empty gripper. The program pointer (PP) only moves forward through a routine; no branch inside main sends it back to the top.

The structural lesson: a miss is not a branch, it is an exception. The vision routine's job is to report what it saw. What a miss costs — a home move, a restart, a fault stop — depends on robot pose, gripper state and cell outputs that the vision routine does not own. RAPID error handling splits this natively: an ERROR handler in each routine, and RAISE to hand the problem to the caller. The same layering pays off when you structure a vision-guided pick and place program around drop targets instead of around retries.

The pattern in three layers

Three routines, three responsibilities:

• The vision read (CheckStatus here): reads the camera result. No part found → raise your own error, declared as an errnum, so handlers can tell it from a comm loss.
• The vision exchange owner (GetVisionData here): calls the read and applies the offsets on success. Its ERROR handler is a single RAISE — pass the problem up unchanged.
• The cycle owner (main): its ERROR handler parks the robot home with the gripper open, sets the cell outputs, then calls ExitCycle. The pointer moves to Main, execution stops, and the next start runs the whole cycle from the top.

PROC CheckStatus()
    ! Read the camera result and its freshness here.
    ! No part found: RAISE your own no-part errnum.
ERROR
    RAISE;                    ! forward whatever arrived, never swallow it
ENDPROC

PROC GetVisionData()
    CheckStatus;              ! raises on no part, timeout or comm loss
    ! ...apply the offsets, continue the cycle...
ERROR
    RAISE;                    ! the cycle owner decides, not this routine
ENDPROC

PROC main()
    PickFromLoader;
    GetVisionData;
    MachineCycle;
ERROR
    MoveHome;                 ! park clear, gripper open
    ExitCycle;                ! PP to Main, execution stops here
ENDPROC

PickFromLoader, MoveHome and MachineCycle stand for your own routines. The RAPID reference defines RAISE as the way to propagate an error to the caller of a routine, and an error raised where no handler exists ends at the system error handler: a stopped program and a message that waits for a person. That is exactly the unattended-shift failure you are designing out.

What the camera side must deliver

The robot pattern is camera-agnostic, but it needs three clean states from the vision system: part found (with offsets), no part, and no answer before the timeout expires. If your system returns a single bit today, add the timeout watchdog in the robot: a result that never arrives must raise, not hang. The same result-mapping work appears when you send camera part coordinates to a robot controller over TCP.

Where the result comes from does not matter to main. A smart camera such as the LS-SMC-0017 runs the inspection on the device and hands over one decision per request — see robot pick and place vision without an external PC — while a cell built around vision controllers hosts several cameras and the result logic on one box.

Step by step: build the restart path

You need edit access to the RAPID program (RobotStudio or the teach pendant), the camera result mapped to robot-readable form, and a cell signal able to start the program in automatic mode. Then:

1. Map the camera answer to three states — found with offsets, no part, timeout — before writing any handler.
2. Raise a user error in the vision read. Declare a no-part errnum; one generic error for every failure removes your ability to branch later.
3. Add a RAISE-only ERROR handler to GetVisionData. One instruction, no logic: this layer exists so lower errors keep travelling upward.
4. Add the ERROR handler to main: home move with the gripper open, cell outputs (a stack-light blink is enough), then ExitCycle. The pointer moves to Main and execution stops there.
5. Provide the start. A stopped program does not restart itself; in automatic mode a start requires the pointer at Main, and ExitCycle has already put it there. Wire the cell cycle-start signal so the next start needs no person — the sequencing side is covered in PLC ladder logic for robot part sorting with a vision system. A start that stalls even though images keep arriving is a different fault: vision picking restart handshake troubleshooting diagnoses it. The wider start-stop exchange has its own failure modes in vision project start stop handshake troubleshooting.
6. Count consecutive restarts in a module variable. After 3 no-part restarts in a row, park home, set a fault output and stop: one miss self-heals, three means an empty feeder or a jam.
7. Clear camera state every request. A latched result from the previous part reads as found on an empty gripper — the stale-data failure described in conveyor vision scene timing: troubleshoot stale pick data.
8. Test empty, then gapped, before the first unattended shift.

Worked example: one missed pick per hour on a 16-hour lights-out shift

Inputs, with the basis for each:

• Cycle time 8 s per part (pick → camera → machine). Presented-part tending typically runs 5-15 s; substitute your measured cycle.
• Miss rate 1 per hour: the loader occasionally fails to present a part.
• Restart overhead 3 s beyond the wasted cycle: home move, pointer reset, start.
• Shift 16 h unattended = 57,600 s.

The rule in words: one miss costs one wasted cycle plus the restart overhead, and the shift share is that cost times the misses, over the shift.

• Nominal output: 57,600 / 8 = 7,200 parts.
• Misses: 1/h × 16 h = 16.
• Lost time: 16 × (8 + 3) = 176 s.
• Shift share: 176 / 57,600 = 0.003, about 0.3 %.
• Parts lost: 176 / 8 = 22 of 7,200.

Decision: below 1 % of shift time lost, ExitCycle restarts alone are the right design — the cell self-heals and costs you minutes a night. At or above 1 %, put a part-present photoelectric sensor at the loader so empty cycles never reach the camera, and keep the restart path for the rare genuine miss. Keep the 3-consecutive-restart stop in both cases.

Verify it before the first unattended shift

• Empty-loader run. The robot parks home, gripper open, pointer at Main, execution stopped, no message waiting. The event log shows a handled error, not a system stop.
• Start pulse. One pulse of the cell start must run the cycle from the top of main, not resume the old one.
• Camera cable pulled. The timeout path must fault, not restart: a silent restart on comm loss would run an empty cell all night.
• Three forced misses. The counter must stop the program and set the PLC output.
• One gapped dry run, end to end, with the shift log reviewed afterwards.

Common mistakes

• Retrying inside the IF. The original failure: after the second missed pick the flow exits the block and continues, into machining, with no part.
• Returning a status instead of raising. Works until the vision read also moves the robot; then a miss needs unwinding only the caller can do.
• ExitCycle mid-flight. Without the home move first, the arm sits inside the machine and the next start assumes it is clear.
• ExitCycle with nothing to start. The pointer reaches Main and the cell stands still until morning.
• Timeout treated as no part. An absent answer is a comm fault until proven otherwise; restarting hides it.
• One errnum for everything. The top handler cannot branch, so every failure takes the restart path, including the ones that should stop.

When a blind restart is the wrong answer

The unreadable-part row is the one that bites. Glare, focus drift or an exposure feedback loop can make a held part read as no part, and the restart path then re-picks from an empty loader while the real part waits in the machine. If the gripper has a grip sensor, read it in the top handler before deciding, and fix detection at the source — auto exposure ROI instability from detection feedback is a known version of that trap. A late result is its own hazard: when acquisition and motion overlap, a result can belong to the previous request, which is the timing overlap traced in vision picking request timing.

Checklist before lights-out

• Three result states mapped: found, no part, timeout.
• No-part errnum distinct from the comm-loss errnum.
• Handler chain CheckStatus → GetVisionData → main, RAISE-only below the top.
• Top handler: home move, gripper open, cell outputs, ExitCycle.
• Automatic start proven from the cell signal with the pointer at Main.
• Restart counter faults after 3 consecutive misses.
• Grip sensor read before the restart decision, if fitted.
• Empty-loader, cable-pull and triple-miss tests all pass.

If the camera side of the cell is still open, sketch it in the system configurator with your cycle timing at hand, or bring the timing and the miss rate to the contact page and the applications team will size the inspection side with you.