Camera emulator communication timeout after run mode: fix the order

The job passes in the emulator, the program reaches the run-mode call, and the socket sits silent until the timeout fires. That gap between a passing simulation and a dead command stalls more commissioning days than the job itself ever does, and the cause is almost never inside the inspection. This guide is for integrators wiring vision to a robot or PLC before the camera exists, and for anyone testing jobs against a virtual controller on a bench PC. You get the six-step handshake order, waits sized from measured job time, a script test that separates vision from robot code, and the checklist for the first real cycle.

Why does a camera emulator time out when you set run mode?

The command times out because it reaches an emulator whose session is not in the state run mode requires: the job is not confirmed loaded or the result read is not armed, so the emulator silently withholds its acknowledgement until your wait — often set at 1 s — runs out.

Ordered by how often each turns out to be the cause:

1. Run mode is sent before the load acknowledgement arrives — the job was issued, but nobody read the confirmation.
2. A second client still holds the session — the development environment is open on the same emulator, which serves one client at a time.
3. The result read was never armed, so run mode is answered but the result wait that follows expires.
4. The load was attempted in the wrong state — one vision-sensor protocol answers a load-while-online request with the error code 0x0401, a refusal rather than a timeout.
5. Transport is wrong — address, port, firewall or a localhost binding — and then connect itself fails.

On platforms that drive the camera through the controller's vision instructions, the failing call is the run-mode setter — spelled CamSetRunMode in one common instruction set — and none of these five causes is cured by making that one wait longer. The cure is the order that leads up to it.

When the emulator stands in for a camera that a robot controller's integrated vision will drive, the pairing options are laid out in integrated vision with a third-party camera.

What is the correct handshake order before run mode?

Connect and confirm the session first, load the job in program state, read the job ID back and compare it, arm the result read, and only then set run mode — six confirmed steps, each with its own wait, each verified before the next one is sent.

The waits are commissioning defaults, not limits. Step 2 exists for protocols that refuse a load sent while online, like the 0x0401 refusal in the list above, so the load happens in program state before the mode change. If your sensor can set your vision sensor to auto-load its job on startup, step 3 shrinks to a verify, and step 4 becomes the guard that catches a wrong or stale job.

Two more state traps sit next to this order. A camera that misses its first images after a load needs the ready-gate fix for first images after load, and a job switch that leaves the wrong online state behind is a separate error with a separate fix for the state after a job switch online error. Parameters follow the same discipline: set manual exposure before streaming is the same order-first pattern applied to settings.

How long should each wait in the sequence be?

Give every startup command a 2 s wait and size the trigger-to-result wait at max(500 ms, 3 × the job time you measured in the emulator), a rule of thumb that survives a slow LAN and one missed result.

The startup waits in the table are defaults; the wait that decides production is trigger-to-result, and it follows one rule:

The 500 ms floor covers a plant-LAN round trip near 10 ms plus one lost frame and its retry. The 3× factor carries that retry with margin. Both are rules of thumb — the measurement is the law.

Worked example. Time the job in the emulator: send a software trigger, take the result timestamp, subtract. Suppose the job measures 180 ms and the command round trip measures 10 ms. The minimum wait is 180 + 10 = 190 ms. The rule gives 3 × 180 ms = 540 ms, which clears the minimum and carries a retry, so the wait is set to 600 ms. On a PLC with scan jitter, 1,000 ms costs nothing on a pass — the long wait only runs out on a failure. The 180 ms and 10 ms are illustrative; take your own the way measuring frame trigger wait time and polling resolution sets out.

Which cause matches your symptom?

Match the failure pattern before you change anything: a timeout on the run-mode call alone points at order, a timeout on every command points at transport, and a result that never arrives points at an unarmed read — the table sorts the five patterns.

Rows are ordered by how often each pattern turns out to be the live one. Not every emulator times out, either — some refuse run mode outright with a dedicated error when the target type cannot support the mode, as one HMI emulator run-mode error documents. A refusal and a timeout are the same family of state problem; both are the emulator telling you which state it could not reach.

How do you test the handshake without the robot in the loop?

Drive the emulator from a plain socket script that sends the six steps and prints every acknowledgement, because if the sequence works there, the vision side is proven and the fault lives in the robot program's order, not in the emulator.

Function and variable names below are illustrative — keep your SDK's own calls — and so are the address and port:

emulator_ip = "192.168.1.50"     # illustrative emulator host address
port        = 5000               # illustrative emulator port
connect(emulator_ip, port)       # step 1 — accept expected within 2 s
set_program_mode()               # step 2 — only if loading requires it
load_job(123)                    # step 3 — illustrative job ID
assert read_job_id() == 123      # step 4 — compare, never assume
arm_results()                    # step 5 — subscribe before run mode
set_run_mode(RUN)                # step 6 — expect the run acknowledgement
trigger()                        # then wait 600 ms for the result
result = read_result(600)

The test that proves the order is the cause: run the script twice, once with the arm step deleted and once complete. The first run must stall at the run-mode call and the second must return the result — same emulator, same job, only the order differs. If you speak raw TCP instead of the SDK, the same discipline governs the send loop; the case of a robot socket string that never arrives is the same fault with the robot on the other end.

When does the timeout point at the network instead of the order?

Suspect transport when even the first connect or a simple status read times out: wrong IP, wrong port, a firewall on the development PC, or a second client — usually the still-open development environment — holding the emulator's single session slot.

Work the transport checks in this order:

• Ping the emulator's address from the robot or PLC, not from the desk PC.
• Confirm the port against the emulator's own settings — it is a setting, not a constant.
• Close the development environment; its session occupies the single client slot.
• Point the runtime at the PC's LAN address, never at a localhost binding that only exists on the development machine.

Emulated industrial targets fail this way across platforms — a run command fired at a session that is not fully up — and one HMI emulator communication timeout fix documents the same connect-first diagnosis. The leftover that bites later is the half-open session: after a robot fault, the next cycle start times out with no error of its own, and the cure is a full re-handshake, covered in re-handshaking at cycle start after a robot fault.

What changes when you move from the emulator to a real camera?

The six-step order does not change; the numbers do, because the real camera adds exposure, transfer and lighting time the emulator simulated, so re-measure the trigger-to-result time on hardware before you carry the wait into production.

Three things arrive with the hardware. Exposure adds its full duration to every job — a 5 ms exposure is 5 ms more job. The trigger becomes a wire with its own timing and its own failures. The licence moves to the controller that runs the vision software. Re-measure trigger-to-result across 20 cycles on the camera, keep the slowest, and apply max(500 ms, 3 × t_job) again.

A first hardware stand-in is the MV-SC3050XC-16M-ATN-H, a 5 MP colour vision sensor with a global shutter on Fast Ethernet and an M12 mount.

The MV-SC5060XM-08M-WBN takes the same role with more image to work from: 6 MP mono on GigE, an 8 mm lens, M12 mount.

At the desk end, the emulator's job lands on a vision controller: the software runs there, the camera ports take over the session the emulator held, and built-in light channels drive the illuminator. The MV-VC3301H-128G66 ships with its VM6200Pro licence included, so the job you proved in the emulator moves across unchanged. The two controllers below cover the small end and the multi-camera end of that job.

What should you check before the first real cycle?

Run the checklist below once with the cell in manual mode: session, state, timing, recovery and safety each get one line item, and every line exists because skipping it is exactly what produces a timeout on the shop floor.

• Session — exactly one client: search the startup code for a second connect call. Its session is the one the run-mode command lands on.
• State — the job ID compared after every load and every power-up, never assumed. A stale job passes silently until run mode refuses it.
• Timing — waits sized from 20 measured hardware cycles, slowest taken. Emulator numbers omit exposure and transfer.
• Recovery — a fault drops the session and the next cycle start re-handshakes from step 1. Half-open sessions time out without raising an error of their own.
• Safety — first live triggers in manual with the robot at reduced speed. The emulator never tested the trigger wire or the light.

From here the hardware side starts in the smart cameras and vision controllers categories, the camera finder filters by the interface your handshake already speaks, and the systems topic page collects the commissioning fixes around this one. Expert support comes free with every order — if the set-up has a wrinkle such as mixed interfaces or an odd trigger chain, describe it via contact before you order.