Simulate a GigE Vision camera reset: heartbeat timeout and reconnect

You need to know how your vision application behaves when a camera vanishes mid-run: a power cycle, a firmware reboot, a switch that reboots unannounced. Pulling cables to find out is slow, hard to repeat and hard on connectors. A GigE Vision server — a software device emulator — lets you script that failure: stop it, hold it down long enough for the client to register the loss, then start it again on the same address. The reconnect is the client's job, so what you are really testing is your transport layer and your recovery code. The sequence, the numbers that drive it, the checks that prove recovery, and the cases where only real hardware counts are below.

How do you simulate a camera reset on a GigE Vision server?

Stop the server, keep it stopped for at least 3 s — the default GigE Vision heartbeat timeout — then start it again on the same address; the client's reconnect logic does the rest, and that logic is exactly what you are testing.

The server needs no reset of its own. A stop closes the control and stream sockets; a start brings the device back with the control channel privilege register (GevCCP) at 0 — the state a freshly booted camera presents. Work the sequence in this order:

1. Bring the server up and let the client connect, take control and stream. Capture a baseline: frame counter, exposure, gain, pixel format.
2. Record the heartbeat timeout in use. The default is 3000 ms, and your hold time is derived from it.
3. Call the server's stop function. Both sockets close and the device stops answering.
4. Hold for at least the heartbeat timeout. At the default that is 3 s; the next section sets the committed value.
5. Call start on the same IP address. The device reappears with GevCCP at 0 until a client takes control again.
6. Watch the client recover — disconnect signalled, device re-enumerated, control re-acquired, streaming resumed — and log a timestamp at every step.

Server libraries expose connected and disconnected events; register for both, so the harness logs when the client dropped and when it came back rather than inferring it from the stream. And do not simulate the reset by stopping and restarting acquisition inside the client: that exercises a different failure path, the one described in repeated camera start-stop cycles trigger frame timeout: keep it open.

Why must the server stay down for a few seconds?

The heartbeat keeps the GigE Vision control channel alive and its default timeout is 3000 ms, so a restart inside that window can pass completely unnoticed by a client that relies on the heartbeat alone.

The transport layer polls the device as its liveness check — it reads the GevCCP register periodically — and declares the device gone when nothing answers before the timeout expires. Restart the server inside the window and, on a quiet link, the next check can succeed against the restarted device as if nothing happened. Your recovery path never runs and the test passes for the wrong reason. The hold is therefore not a comfort margin; it is the timeout itself plus the detection time:

Four seconds is the committed hold at the default timeout, and the 1000 ms margin covers the request-failure path described next.

How quickly does the client notice the camera is gone?

No later than about 1 s after the stop with a standard GenICam transport layer, because the closed socket makes the client's next control request fail immediately instead of waiting out the 3 s heartbeat timeout.

Three signals race, fastest first:

• Request failure. The stop closes the socket, so the client's next read of GevCCP is refused outright. Observed with a standard GenICam transport-layer client, the disconnect shows up no later than roughly 1 s after the stop call — the polling cycle sets that time, not the heartbeat.
• Heartbeat timeout. If the request path stays quiet, the 3 s default still fires and marks the connection dead.
• GevCCP at 0. Even a sub-second stop leaves a trace: the restarted device reports control channel privilege 0, which tells the client nobody holds control.

Detection is fast and reliable — but only the hold time guarantees the disconnect becomes an event your recovery code actually processes. What the timeout does to a live stream is its own subject: why the GigE Vision heartbeat timeout stops your stream after a pause.

What state does the client come back to?

It comes back to a device that holds no control privilege: the stop/start cycle resets GevCCP to 0, so the client must reopen the control channel, take privilege again and rebuild the stream channel from scratch.

Plan the recovery around three facts. Control is gone, and re-acquiring it is a control-channel write, not a link renegotiation. A reset device returns to power-on defaults, so exposure, gain and pixel format set before the outage are gone; the reconnect path must reapply settings and read them back. The frame counter restarts, so sequence numbers from before the outage cannot be compared with numbers after it.

A reset that lands the client in a broken configuration is the classic follow-on fault — GenICam driver fails after restart: fix the camera configuration covers the reconfiguration sequence. Some devices also need an explicit wake before they stream again, as in camera stuck in standby after reconnect: wake it before you stream, so put that call in the recovery path when your hardware behaves that way.

How long should the simulated outage last?

Commit to a 4 s hold with the default 3 s timeout — 3 s to guarantee the heartbeat path fires, plus 1 s for the request-failure path — and measure the reconnect time instead of assuming it.

Run the opposite case too: stop and start again inside 0.5 s. The heartbeat never fires and the request path can miss the gap, leaving GevCCP at 0 as the only trace. A client that treats that as a silent re-acquisition is doing the right thing for a blip; a client that ignores it will misbehave on real brownouts. If you raise the heartbeat timeout, scale the hold the same way: at a 10 s timeout, hold 10 s + 1 s = 11 s.

How do you verify the reconnect worked?

Assert exactly one disconnect and one reconnect, confirm the client re-took control by reading GevCCP as non-zero, and prove the stream is fresh by checking the frame counter climbs from its restart value.

Check each of these on every run:

• One disconnected event and one connected event on the server, in that order. Two pairs means the client is flapping, not recovering.
• GevCCP reads non-zero after the client takes control. Access GigE camera registers at runtime from your control code shows how to read device registers from the harness itself.
• The frame counter increases monotonically after the restart, and no pre-outage frame is delivered as a fresh one; match on counter and timestamp.
• Settings readback: after reconnect, write exposure, gain and pixel format, then read them and compare with intent.
• Recovery lands inside your process budget. Set that budget from what the cell tolerates — one missed inspection cycle, say — never from protocol timings.
• Soak: loop the stop-hold-start cycle 100 times and watch for leaked handles, duplicate events, or a client that stops noticing the disconnect on later iterations.

If a run crashes the client instead, the device can be left held by the dead process; release a camera after a crash on Linux: GigE restart fix is the cleanup path. In production the same disconnect must be noticed without halting the program, the pattern in robot vision camera disconnect detection without stopping the program; and if the client is a robot controller rather than your own code, its integrated GigE camera connection troubleshooting lists the controller settings that decide whether it re-finds the camera.

When does a simulated reset not prove anything?

A server stop is a clean, total failure, so it says nothing about link-level faults — an unplugged cable, a rebooting switch, PoE brownout, packet loss on a live link — which only appear with real hardware and a real cable.

The emulator cannot reproduce a link that is up but lossy, or a stream channel that dies while the control channel lives. Before sign-off, run the drill against a physical camera: pull the cable mid-stream, power-cycle the camera at the socket, and repeat over a long run rather than a patch cord, because marginal links fail at length. A switch between camera and client adds the reboot case the emulator cannot fake. Start from GigE area scan cameras — the camera finder filters by interface — and treat camera cables as part of the test matrix, not as wiring.

For the hardware pass:

The camera above is a 6 MP GigE camera on a C-mount, so the same unit doubles as the production-representative device for the settings-reapply test. Pair it with a short and a long cable:

LS-CBL-0199 is a 3 m high-flex GigE cable with screw locks; LS-CBL-0117 takes the test out to 15 m, where marginal links show themselves. More lengths are in the accessories finder.

What should the final reset test cover?

Sign off on four blocks — timing derived from the 3000 ms default, the sub-second blip case, the post-reconnect readbacks, and a soak — and the checklist below is the complete set.

Before

• Baseline captured: frame counter, exposure, gain, pixel format.
• Heartbeat timeout recorded; hold time derived from it (default: 4 s).
• Recovery budget chosen from process tolerance.

During

• Stop; hold at least the heartbeat timeout; start on the same address.
• Blip case: stop and start inside 0.5 s, then check the GevCCP handling.
• Timestamps logged at stop, disconnect, start, reconnect, first good frame.

After

• Exactly one disconnect and one reconnect; no flapping.
• GevCCP non-zero once control is re-taken.
• Frame counter climbing; settings readback matches intent.
• 100-cycle soak clean: no leaked handles, no missed disconnects.
• Hardware pass done: power cycle, cable pull, long cable run.

When the recovery code passes all of that, the remaining questions are hardware: which camera, which cable lengths, which controller drives the light and trigger. The configurator above steps through them in order, and if the reset timing needs a second opinion against your exact client, reach us through the contact page.