Robot vision camera disconnect detection without stopping the program

An integrated camera that drops off the network mid-shift is worse than one that never worked. The cell keeps running, the robot handles parts nobody inspected, and the first visible symptom is an execution fault at the vision call or a run of bad results. The controller gives you no function that answers the question of whether the camera is connected, so the link state has to live in your own program. The pattern that works: an error-driven retry handler that waits 5 s and retries, a heartbeat scheme that keeps that state current in automatic mode, and the cabling and network choices that stop most drops before they happen. Everything is worked through with numbers for an 8 s cycle.

Why the program only ever sees an error

A camera built into a robot controller is driven by calls, not queries. You tell it to load a job, set a run mode or request an image; each call either returns or raises the camera communication-timeout error — printed as ERR_CAM_COM_TIMEOUT in the integrated vision manuals. No call returns link state, and the error is raised once per failed call: nothing tells you afterwards that the link came back. That leaves two jobs for your program. Turn each failed call into a bounded recovery attempt, and keep a flag that says whether the last call succeeded. Everything below is those two jobs, plus the hardware that keeps the calls from failing.

Rank the causes before you touch the code

A dropped camera is almost always physical, so work down this table before changing a line of code. Each test takes minutes.

On a wrist or in a chain, treat level 1 as the default suspect. A cable not built for continuous flexing is not rated for that duty, and no error handler changes that.

The retry handler: catch, wait, retry, mark healthy

Wrap every blocking vision call in a handler with three pieces: a bounded retry count, a fixed recovery wait and a flag that records the outcome. The 5 s recovery wait is the value to start with — long enough for a switch or camera to re-establish the link, short enough to fit a production stop an operator would tolerate. The counter bounds the pause; three rounds rides out a power-cycle recovery and still hands over to a controlled stop quickly.

! Illustrative handler in the style of an integrated-vision error trap.
! Keep the constant exactly as your controller's vision manual prints it.
! cam_ok: bool, TRUE at power-up. n_retries: num, cleared each part cycle.
PROC vision_step()
    n_retries := 0;
    <this cycle's vision call>;   ! placeholder: your blocking capture call
    cam_ok := TRUE;               ! reached only after a clean return
    RETURN;
ERROR
    IF ERRNO = ERR_CAM_COM_TIMEOUT AND n_retries < 3 THEN
        n_retries := n_retries + 1;
        cam_ok := FALSE;
        TPWRITE "Camera link down, retrying";
        WaitTime 5;               ! recovery wait, seconds
        RETRY;
    ENDIF
    cam_ok := FALSE;              ! three rounds failed: caller decides
ENDPROC

The mechanics answer the question of how you know the error is solved. The first clean return sets cam_ok back to TRUE and logs the restored link; a retry that fails again re-enters the handler, and after three rounds the flag stays FALSE for the caller to act on.

Automatic mode: gate the flow, do not trap the fault

Manual and automatic mode do not treat the handler the same. On integrated vision set-ups the reported behavior differs by build: in automatic, some controllers raise the execution error before the program's error handler is entered, so the trap never fires and the program stops in fault. Measure which behavior your build has, and design so both outcomes leave the cell safe.

Design 1: the handler runs in automatic

Let the production call double as the heartbeat. When it returns, the link is healthy by definition; when it times out, the handler clears cam_ok and the next cycle becomes a hold cycle: infeed output off, robot to a park position, and one lightweight probe call per cycle with the same trap around it. Keep the probe small — a reduced image region in mono8 — so it costs nothing: at 640 × 480 pixels per 8 s cycle the load is about 0.3 Mbit/s, worked through below. The first probe that returns sets cam_ok to TRUE, the hold lifts and production resumes without an operator. Recovery is detected within one cycle of the link coming back.

Design 2: the heartbeat becomes a physical input

No vision call may be allowed to fail in automatic, because the first failure is a program-stopping fault. The heartbeat then has to be a signal that does not pass through the vision call: the camera's programmable ready or error discrete output wired to a controller input, or the device-status bit fetched from the PLC. The program reads that input every cycle and treats a steady error level exactly like a failed heartbeat — hold the infeed, park, wait. When the input returns to the ready level, vision calls resume. Nothing calls the camera while the link is down, so nothing can raise. Wiring controller inputs to report machine state is standard practice; a worked I/O configuration that exposes pause and stop states shows the same discipline.

The numbers: recovery budget and heartbeat load

The inputs below are example values; set them from your cell and re-run the same two lines:

• Call timeout 5 s, recovery wait 5 s, retry limit 3: worst case 3 × (5 s + 5 s) = 30 s of pause before the flag goes FALSE for good and the cell hands over to a controlled stop.
• Cycle time 8 s: 30 s spans 30 / 8 = 3.75 cycles, so a link that dies and stays dead costs at most 4 cycles of production.
• Probe at 640 × 480 mono8: 640 × 480 = 307,200 bytes ≈ 0.31 MB. One probe per 8 s cycle gives 307,200 bytes × 8 bit/byte ÷ 8 s = 307,200 bit/s ≈ 0.31 Mbit/s, about 0.03 % of a GigE link's 1,000 Mbit/s — the heartbeat costs no measurable cycle time.
• Sensitivity: a 10 s call timeout lifts the worst case to 3 × (10 s + 5 s) = 45 s; a 16-bit probe doubles the bytes to 614,400, still about 0.6 Mbit/s.

Where the vision package fixes the call timeout instead of exposing it, read its printed value into the same formula in place of 5 s.

Keep the link up: cable, power, network

On a robot wrist or in a drag chain the camera cable is a wearing part, and it should be bought like one: flex-rated for continuous chain duty, run with a service loop that holds the bend radius near 7.5-10× the cable's outer diameter — the range drag-chain cable makers commonly rate — and clamped so the strain lands on the boot, not the connector. The camera cables category keeps the drag-chain grades together. For a GigE camera, this is the grade meant for the chain:

The LS-CBL-0199 is a 3 m GigE camera cable, high-flex and drag-chain rated, with screw locks. USB3 cameras are less forgiving of cable abuse, and a passive SuperSpeed run is normally kept short:

The LS-CBL-0219 is the 3 m USB3.0 counterpart, high-flex and drag-chain rated. Carry the trigger and the ready or error line through the same chain on the same discipline:

The LS-CBL-0300 is a 7 m power and I/O cable, M8 8-pin, 8-core, male to open end, rated for drag-chain use.

Power next: probe 24 V DC at the camera connector across ten full cycles with the whole cell running. A dip that coincides with a motor start is a shared-supply problem, and the fix is a dedicated camera feed.

Network last: give every camera a static IP outside the DHCP pool and record it, because an address that moved after a switch swap looks exactly like a dead camera. The GigE camera on a robot wrist article covers the network build for a moving camera, and this GigE camera-to-controller setup walkthrough goes port by port on a concrete controller.

Put the inspection on the device

A smart camera or vision sensor changes the failure shape. Inspection runs on the device, so the robot link carries one short result per cycle instead of a streaming session, and a hiccup costs one result, not the image pipe. These devices also provide the programmable discrete outputs that Design 2 needs: assign one as the ready or error line and the link check stops depending on the vision call entirely. The smart cameras page is that shelf. The MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor with a 1/1.45" global-shutter sensor, an M12 mount and a Fast Ethernet interface:

Verify the chain before production

1. Pull test, once, in automatic. Arm the handler, pull the connector and record whether the trap fires. The result names Design 1 or Design 2 for your build.
2. Wiggle test. Flex the cable 100 mm from each connector while streaming; a drop that follows the flex replaces the cable before the next run.
3. Supply probe. 24 V DC at the camera connector across ten cycles; investigate any dip aligned with a motor start.
4. Recovery drill. Drop the link for 30 s in automatic and count cycles to resume. At an 8 s cycle under Design 1, the numbers above predict resumption within one cycle of the link returning.
5. A week of counters. Log handled retries and hold cycles for a week. Retries every shift are a hardware problem wearing a software fix.

When the usual answer is wrong

A camera can fail without disconnecting. If the link stays up but frames stop refreshing, no timeout error ever fires — timestamp each frame and treat an image older than two cycles as a failed heartbeat; the frame timestamp timing article shows how to read frame timing. Slow frames in a multi-camera rig mimic disconnects but are contention, which the multi-camera polling article sorts out. A USB camera that vanishes after a capture crash has its own re-enumeration path, walked in the USB camera recovery article. Acquisition from a PC is a different problem entirely: GigE Vision control-channel heartbeats and application watchdogs detect a dead device there, as the GigE camera disconnected detection article covers, with the stream-level timeouts in the PoE stream recovery article. A program restart, finally, wipes cam_ok and n_retries: re-initialize both and re-run the camera handshake at every start, a point the ExitCycle no-part recovery article builds on.

The decision, per case

• Handler fires in automatic, per the pull test: Design 1 — trap, 5 s wait, 3 retries, per-cycle probe heartbeat, hold on cam_ok.
• Handler does not fire in automatic: Design 2 — ready/error discrete input gates every cycle, and no vision call is made while the link is down.
• Camera on a moving axis: flex-rated drag-chain cable, service loop, strain relief, static IP outside the pool.
• Acquisition from a PC: application watchdogs, per the linked articles above.

Pick the camera and the flex-rated cable as one system: the camera finder, the accessories finder for cabling, the area scan cameras page when inspection runs on a PC, and the configurator's trigger step to match trigger wiring to the camera. The systems topic page collects the surrounding recovery patterns, and contact is open if you want a set-up checked against your cycle time.