Switch vision jobs mid program without losing the camera socket

A UR program that opens its own TCP socket to load a camera job, followed by vision-guided steps that run through the camera's vision URCap node, works as two separate programs and fails as one. After a mid-run job load, the vision step sends its request and nothing comes back; the camera answers again only after its address is re-entered or it is power-cycled. Here you will find why a job switch kills the session, four causes ranked by how often each turns out to be the guilty one, ten-minute tests for every cause, two connection patterns that fix the merged program, and the cycle-time cost of each choice.

The symptom: each program passes alone, the merged run hangs

Each half works by itself. Program one opens the socket, sends the job-load command the camera manual defines and gets its acknowledgement. Program two runs the pick or the place through the camera's vision URCap node. Merged into a single run — connect, load the pick job, vision-guided pick, load the place job, vision-guided place — the vision step that follows a load stops receiving answers. Requests time out, the program faults or waits forever, and the sensor comes back only when someone re-enters its IP address in the vision URCap setup or power-cycles it.

That recovery detail is the fingerprint. A reset that clears the fault means a dead session was still registered on the sensor; a clean sensor needs no reset. The same root cause appears as a camera that drops offline mid-run with nobody having closed a connection, which is why disconnect detection that keeps the robot program running belongs in the same program as the fix below. A near neighbour — the sensor answers after a load but the first images are wrong or missing — is the ready-gate problem in why a smart camera misses its first images after a load.

Why the camera goes quiet, most likely cause first

Four causes produce this signature. Test them in this order.

1. The job load restarts the sensor's network server. A job file is a whole application. When the sensor applies it, its Ethernet service stops and starts again, and every TCP session — yours and the vision node's — is dropped on the sensor side. TCP warns a client of nothing until its next send, so your socket sits half-open while the node's pending request is answered by nobody.
2. The client table is full. Embedded vision servers accept a small, fixed number of clients per port; treat it as one unless the sensor's manual states more. Your raw session then occupies the slot the node needs, so its connect is refused or its request never queues — the same one-camera-two-clients trap as reaching a camera's parameter tree over TCP from a second application.
3. You send while the sensor is still re-initializing. The old session acknowledged the load command, the application then restarts, and anything sent in that window lands on a listener that no longer exists.
4. The node trusts its cached connection. The vision node keeps its session state from the previous run and does not re-handshake after foreign activity on the sensor — the leftover-state trap that also makes camera tests flaky on leftover settings until everything starts from a known state.

Test each cause in ten minutes

Run the merged program three times with one change each time, and the failing cause names itself.

1. Remove the job loads. If both vision steps now pass, the load path is the trigger and the cause is 1 or 3.
2. Close the raw socket before each vision step. Open, send the load, wait for the acknowledgement string, close, then run the vision node. If everything passes, you had cause 2: concurrent owners on a one-client server.
3. Time the restart window. After a load, try a raw connect every 100 ms and record when the first one succeeds. On an embedded vision sensor expect 0.5 to 2 s; that measured value becomes the ready-poll cap in the fix.
4. Check the open result. Assign it to a boolean: open_ok = socket_open(camera_address, camera_port), with those two set to your cell's address and port. A false return from a camera that answers a ping means the session layer, not the network — reconnect on false: close, wait 0.5 s, try again, the pattern in fixing a robot socket that gives no response. If a clean program restart still leaves the sensor deaf, re-enter the camera's address once at the bench; if that revives it, cause 1 is confirmed.

Run the first merged cycles at reduced speed with the arm clear of the fixture, so a vision timeout stops the motion instead of finishing it blind.

The fix: one owner per run

Decide in this order. First, if one job file can run both inspections, load it once and skip switching entirely: no switch, no dropped session, full cycle rate. Second, if the jobs must switch, give the camera exactly one connection owner per run and route every load through it. Third, whichever pattern you pick, check every open and send result and reconnect on failure, which turns a dropped session into a 1 s pause instead of a stopped cell. One more cut: configure the sensor to auto-load its startup job, as in set your vision sensor to auto load its job on startup, so every cycle starts in the pick job and needs at most one switch.

Pattern A: route everything through one persistent session

Use this when the vision steps are plain socket transactions — trigger command in, result string out — and no separate vision node needs its own session.

1. In the program's start routine, open once: open_ok = socket_open(camera_address, camera_port).
2. On a false result, close, wait 0.5 s and retry; after three failures, fault the program, so a dead sensor stops the cell instead of looping forever.
3. Send the job-load string for job A from your command table — one line per job, the same one-command-one-recipe discipline as RS232 vision recipe selection with unique command codes.
4. Poll readiness: send a light status request every 100 ms until a reply arrives; cap at 2 s, or 5 s for large job files.
5. Trigger the inspection and read the result string over the same session, parsing it field by field the way four vision results parsed from one socket string on a UR10e shows.
6. For the place job, repeat steps 3 to 5 on the same session. Never open a second one mid-run.
7. Close in the end routine and on every error path before any reopen.

If you rehearse the program in the offline simulator first, its socket sessions pause differently from the real controller's; the URSim socket control notes for UR10 program pauses explain the difference.

Pattern B: sequence the sessions strictly

Use this when the vision steps must run through the camera's vision URCap node, so the node owns the working session.

1. Open a raw socket, send the load command for job A, wait for the acknowledgement string, then close the raw socket — four instructions, always in that order.
2. Probe the sensor: try a raw connect every 100 ms; when one succeeds, close it immediately. The successful connect is your proof the server is back, and closing the probe frees the slot for the node.
3. Run the vision node step for the pick.
4. For the place job, repeat steps 1 to 3 with job B's load command.
5. On any fault anywhere in the run, close every session you opened before the program stops, so the next start begins clean.

What a mid-program job switch costs in cycle time

Worked example. Take a pick-and-place cell with a 6.0 s base takt and one job switch per part. On an embedded vision sensor a measured switch typically breaks into 0.4 s to apply the job file, 0.6 s of server restart before a connect succeeds again, and 0.2 s to reconnect and verify — 1.2 s total. The effective takt is 6.0 + 1 × 1.2 = 7.2 s, so throughput falls from 3600 / 6.0 = 600 parts/h to 3600 / 7.2 = 500 parts/h: 100 parts/h lost, 16.7% of capacity, for one command in the middle of the program.

The fix changes the numbers. Pattern B's readiness poll replaces the fixed post-load wait, so the same switch costs about 0.7 s — 0.4 s apply, 0.2 s average poll, 0.1 s verify — and the takt lands at 6.7 s: 3600 / 6.7 = 537 parts/h. Merging both inspections into one job file sets n_switch = 0 and keeps the full 600 parts/h. Log your own three numbers once — timestamps around a single load — and substitute them; the 0.4 / 0.6 / 0.2 split above is the starting estimate for this class of sensor, and large job files move the apply time up first.

When to move the switching off the sensor

Two situations change the answer.

The PLC or an operator changes recipes. The same server restart happens no matter who sends the load, so one owner and a ready poll still apply; the extra failure there is the trigger race, covered in vision format selection timing and PLC trigger races. Over serial there are no TCP sessions for a load to drop, one reason local vision recipe switching from operator buttons often rides a serial line in real cells.

Several cameras or heavier logic join the cell. Then move the vision application onto a vision controller: the software owns each camera exclusively, so job switching happens inside one application with no second TCP client to fight, and the robot link rides its own LAN port — see the vision controllers category. The MV-VC3301H-128G66 lists an Intel Core i3, 8 GB memory, 5+ LAN ports and 4 built-in light channels, with a vision software license included.

The three controllers below span a compact N-series box, a Core i3 mainstream box and a PoE-equipped Core i5 box:

All 3 share: Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Prevention checklist

• One owner per run. The raw socket and the vision node never hold sessions at the same time; concurrent owners are cause 2 and the hardest to see.
• Check every open and send. Branch on the result, reconnect once on failure with a 0.5 s wait, fault on the second failure.
• Close on every exit path, faults included, so no half-open session survives to poison the next run.
• Poll readiness after each load with a 100 ms step and a cap that faults; never trust a fixed sleep.
• Auto-load the startup job so a cycle carries at most one switch, per the math above.
• Keep one command table: job file, load string and expected acknowledgement in one place in the program, the way a vision-guided pick-and-place program built around drop targets keeps its targets in one place.
• Log timestamps around loads so the measured switch cost stays current after firmware or job-file changes.

The decision, per case

• One job file covers both inspections: merge them. n_switch = 0, no session risk, and the example cell keeps its 600 parts/h.
• Jobs must switch, steps are socket transactions: Pattern A — one persistent session carries loads, triggers and results.
• Jobs must switch, the vision URCap node must acquire: Pattern B — load, acknowledge, close, probe, run; poll instead of sleep.
• Recipes change from the PLC or an operator panel: the same rules, plus the trigger-race fix; move the link to serial if races persist.
• The cell grows past one camera or past the sensor's logic: a vision controller owns the cameras and gives the robot its own port.
• Considering a background thread for the socket exchange: it keeps motion moving, but it makes connection ownership harder to see; get one owner working first, then thread it.

Pick the sensor for the merged cell in the camera finder or the smart cameras category, and the computing side in the vision-controllers category above. For a quoted multi-camera build, the quote page and the contact page are the direct routes, and the robot-side guides are collected on the robotics topic page.