Vision locate works in teach but fails at run time: stream vs snapshot

Teach worked ten minutes ago: you snapped the part, saved the position, taught the pick points. Then you press play, the robot reaches the locate step, and the camera node reports a stream or acquisition failure. Reopen the teach panel and the camera snaps fine. That pattern — setup works, run fails — points at how the program's camera session was opened and released, not at optics, calibration or cabling. This guide ranks the causes by probability, walks through the fixes that take seconds, and gives the timing arithmetic to set snapshot acquisition and frame timeouts correctly. It is written for anyone wiring a wrist- or cell-mounted camera into a robot program's locate step.

Why does vision locate work in teach but fail when the program runs?

Teach and run start the camera differently: the teach panel opens a private one-shot snapshot session, while the running program asks for a continuous stream that was never established — or that a leftover teach session still holds — so the locate node waits and times out.

Most camera toolchains split the work between two clients. The teach panel is a setup client: each snap opens the device, captures one frame, runs the locate, then releases or parks its session while you edit. The program is a run client: its locate node expects to open the device once and receive frames on demand until the program stops. Three gaps break between them:

1. The teach session never released, so the camera refuses the program's open request.
2. The node asks for a continuous stream while the session produces single frames on command — no frames ever arrive.
3. The program connects with different settings than the setup screen used: another address, another network interface, another packet size.

None of these touches the taught part model or calibration, which is why the teach panel keeps snapping while the program starves. If the locate has never been reliable anywhere, start instead from the vision locate feasibility checklist; if the symptom is grey frames rather than silence, Camera works in setup but grey image at runtime covers that sibling failure.

What does a stream-failed error at the locate node actually mean?

The error means the node requested frames and none arrived before its timeout, commonly a few hundred milliseconds to a few seconds: the camera and lens are fine, the image was never delivered, so troubleshoot the acquisition session before touching exposure or optics.

The node tried to open the device, asked for frames, and its wait expired with nothing delivered. Read two details out of that. First, an expired wait means frames are not merely late — nothing is producing or delivering them. Second, the error says nothing about image quality: exposure, focus and lighting can all be perfect while zero bytes cross the link.

That distinction saves an hour. Skip the lens-and-lighting checklist and go straight to session state: who opened the camera, in which mode, and whether they released it. The same silence inside your own acquisition code appears as a frame that never arrives within the timeout, and the discipline there — one wait call per frame — applies at the node too.

Which cause should you test first?

Test a stale or mismatched acquisition session first: teach worked minutes earlier on the same cable, switch and address, so network and power are largely excluded and the difference sits in how the program's session was opened.

Work down this list; each test costs seconds.

1. Leftover teach session (most likely). The setup tool was closed with its session still open, and the camera refuses a second client. Test: close every setup tool, stop and start the camera from its setup screen, run once. This sequence alone clears most cells.
2. Acquisition-mode mismatch. The node requests a continuous stream while the session produces single frames on command, or the reverse. Test: open the node's camera settings and read the acquisition mode it actually requests, rather than trusting a default. The same mismatch family explains a hardware trigger that fires once and then stops.
3. First frame later than the timeout. An exposure set only in the program's settings pushes every first frame past a short wait. Test: read the exposure the program applies and add it to the transfer time; trigger timing versus exposure time breaks the two apart.
4. A second client competing for the stream. Background viewers, monitoring dashboards and a second cell program all count. Test: close every other vision application and run.
5. Address or interface drift. The program reaches the camera through a different network interface or address than the setup screen did. Test: ping the camera from the controller the program runs on, not from your laptop.

Power supplies and cables sit last: the teach panel just used the same hardware successfully.

How do you fix it without rebooting the whole cell?

Restart the camera session, not the cell: stop the program, close the teach panel, stop and start the camera from the setup screen, then run once — most cases clear in under a minute without a controller power cycle.

1. Stop the program and bring the robot to a supervised stop.
2. Close every setup tool that uses the camera: teach panel, live viewers, calibration utilities.
3. In the camera's setup screen, stop or disable the device, then start or enable it again. This clears its session without touching taught data.
4. Press play and watch the first locate complete before walking away.
5. If the failure returns on the next full run, add a session reinitialize — stop the camera session, start it again — as the program's first vision step, and set the acquisition mode explicitly to on-demand single frame.

A full power-down does work — it clears every session at once, which is why teams find it first — but it costs minutes and hides which step leaked. Re-running from a clean, known state is the same discipline as fixing flaky camera tests caused by leftover settings: reset the session, then run once and judge.

Should the locate call use a snapshot or a continuous stream?

Use an on-demand snapshot for one locate per cycle: exposure plus transfer plus locate processing lands near 100-200 ms for a typical 1-2 MP wrist camera, while a continuous 30 fps stream costs bandwidth and a live session for no benefit.

The arithmetic decides it. A pick cycle repeating every 6 s needs exactly one frame; a 30 fps stream produces about 180 frames between locates and keeps roughly half the camera's link busy discarding them.

Continuous acquisition keeps a real job in live image loops for setup and monitoring; keep it out of the once-per-cycle locate. Watch exposure if you do stream: GigE frame rate falls as exposure climbs, which is one way a locate passes in teach with a short preview exposure and starves at run with the program's longer one.

When is the real cause the network instead of the session?

Suspect the network only when the teach panel fails too: if the camera is not pingable, drops packets or sits on another subnet than the program's interface, fix addressing and link first, because no acquisition-mode change recovers an unreachable camera.

The run history separates the two causes. A session failure hits the first locate identically every run; network and power faults let runs survive for minutes before dying.

• A camera on another subnet answers your laptop and not the controller — that is why the fifth test above belongs on the controller itself, and why a failed ping points at addressing before anything else.
• Read the link's dropped-packet counters. A packet-size mismatch between sender and receiver passes light traffic and drops frames under the load a stream adds.
• On a wrist camera, flex-test the drag-chain cable and its connectors; a broken conductor passes a bench test and fails at speed.
• Watch the pattern: failures after minutes of running match Smart camera fatal error after days running: network failure recovery, not a session leak.

A camera that never answers at all needs subnet and link checks on a camera the controller cannot ping before you touch the program.

How do you keep the failure from coming back?

Prevention is three settings plus one habit: set the node's acquisition mode to on-demand explicitly, set its timeout to at least three times the expected first-frame time, and close the teach session every time you leave it — a reinitialize call at program start covers the rest.

Turn that into the cell's checklist:

• Settings: acquisition mode set explicitly to on-demand single frame, never inherited from the last client.
• Settings: frame timeout at least 3× the first-frame time; with the 100 ms example above, 500 ms.
• Settings: exposure as short as your lighting allows; every millisecond of exposure lands on every cycle.
• Habit: teach panel closed before every run, even between quick edits — the leftover session is the most common leak.
• Design: a camera-session reinitialize as the program's first vision step, so each run starts from a known state.
• Design: a log line per failed locate saying which wait expired; first-locate versus mid-run separates session from network at a glance.

With locating reliable, harden it against presentation drift using vision locate set up to survive rotation, and keep position-drift diagnosis for the failure class that follows.

When should the locate move to a smart camera or vision controller?

Move the locate onto dedicated vision hardware when session juggling keeps costing cycle time or more than one camera shares the cell: an on-device locate returns coordinates over Ethernet or discrete I/O, and a controller-hosted system manages camera sessions for you.

Both layouts remove that manual open-and-release discipline: the robot program reads an answer instead of holding a stream open.

The MV-SC5060XM-08M-WBN is a 6 MP monochrome GigE smart camera with an 8 mm M12 lens, the layout that runs the locate on the device.

The MV-VC3301H-128G66 pairs an Intel Core i3 with 8 GB of memory and a 128 GB SSD, brings 5+ LAN ports and 4 built-in light channels, and includes the VM6200Pro license for PC-based vision.

Browse smart cameras and vision controllers, narrow the choice in the camera finder, or start the configurator at the camera step. If the failure survives the reinitialize step, contact us with the node's settings and run log, and we will read the timing with you; more run-time acquisition fixes sit on the systems topic page.