Why the GigE Vision heartbeat timeout stops your stream after a pause

You pause your acquisition loop at a breakpoint for a few seconds, step on - and the camera hands you one image, then nothing, until you close and reopen the device. That signature has one dominant cause: the GigE Vision heartbeat timeout expired while your application sat blocked, and the camera closed the control channel and the stream together. This guide is for anyone writing C++, C# or Python code against GigE cameras. It explains what the camera counts while you are stopped, works the arithmetic on a real 9 fps stream, and puts the tests and fixes in the order the failures actually happen.

What the camera counts while you are stopped

A GigE Vision camera watches its control channel with a heartbeat. The watch runs one way: the camera counts the time since it last received a control message from your application, and when that gap passes the heartbeat timeout it concludes the host is gone. It closes the control connection and stops the stream, because a host that cannot talk has no business receiving frames. Every control command resets the timer, so a healthy loop that polls the device keeps the camera alive indefinitely.

Camera manuals commonly label the setting "Heartbeat Timeout", and some devices accept periodic register reads as a keep-alive. The margins are seconds, not minutes: in one observed case, cameras dropped offline after a control gap of about 3.6 s, which puts typical defaults in the low single-digit seconds. A debugger pause of a few seconds sits squarely inside that window. The stream side explains the single image: a frame already in flight completes into a buffer, then nothing follows, because the camera has already stopped sending.

Worked example: 4 seconds at a breakpoint on a 9 fps stream

Inputs, with their sources:

• Camera: the LS-CMR-0053, a 12 MP GigE camera that runs 9 fps (catalog data sheet).
• Pause: 4 s - the reported failure sat at a breakpoint for a few seconds; 4 s is the value worked here.
• Queue depth: 3 buffers, the default most acquisition SDKs start with.
• Heartbeat trip point: about 3.6 s, the observed control gap that dropped cameras offline.

The rule: the sensor keeps exposing and the camera keeps sending for as long as the heartbeat allows, and only frames that find a free buffer survive.

The arithmetic:

• Frame interval: 1 ÷ 9 fps = 0.11 s per frame.
• Queue full: 3 × 0.11 s = 0.33 s into the pause.
• Frames produced during the pause: 9 fps × 4 s = 36 frames.
• Frames with nowhere to land: 36 - 3 = 33.
• Heartbeat expiry: 3.6 s, which is 4 - 3.6 = 0.4 s before you resume.

The result: the camera shuts the stream down while you are still reading the debugger. On resume you drain up to three stale buffers, display an image or two, and the loop then finds nothing more. The reported case showed exactly one frame and froze - the same physics with a smaller queue.

The decision: any pause past roughly 3.6 s kills the stream at these settings. Queue depth decides how many stale frames you get; the heartbeat decides whether the stream exists at all. Fix the blocked thread and the timeout, not the buffers.

The camera behind the worked numbers:

Cause 1: the heartbeat expired while the host was blocked

Most likely when the pause-then-silence signature matches. Test it without a debugger: replace the breakpoint with a ten-second sleep in the grab loop and run. The same one-frame result proves the stall is the cause. Afterwards the camera still enumerates, and only reopening the connection restores streaming.

Fix it in two places. In production code, keep the thread that owns the camera free of blocking work: no modal dialogs, no locks held across a frame wait, no heavy processing on the grab thread. If the language is Python, threading is the wrong tool there - multiprocessing is the fix. While debugging, raise the heartbeat timeout above the longest pause you plan to take; 60 s is a practical bench value. When you tune exposure or gain mid-run, apply the settings while streaming so the control channel never goes quiet.

Cause 2: the queue filled and the stream choked

If frames stop mid-run with no pause anywhere, the stream side takes over. Three buffers hold 0.33 s of a 9 fps stream and 0.1 s of a 30 fps stream, so a host that falls behind longer than that loses frames no matter how the heartbeat is set.

Test by reading the camera's dropped-frame and packet-error counters after the stall, plus the SDK's own loss statistics. SDKs name the saturation differently; troubleshooting GigE camera buffer overflow errors walks one stack's overflow messages end to end.

Fix in three layers. Raise the queue depth first, because three frames beat one and more buffers absorb burst arrivals. On Linux, size the socket receive buffers - small defaults drop packet bursts before your queue sees them, and socket buffer tuning is its own procedure. Last, a 20 MP frame spans thousands of Ethernet packets, so one stalled moment exhausts the resend budget: work the resend ratio and the packet-loss diagnosis when the grab ends in a buffer that was incompletely grabbed.

Cause 3: the camera is gone, not just quiet

When the camera no longer enumerates at all after an incident, the chain is different. A host that boots after the camera comes up misses it entirely; boot order decides that one. A connection killed mid-configuration can leave the driver refusing to start on the next launch; the GenICam driver fix after restart covers that. When frames stop with no pause in the run, the stream timeout checklist walks packets, buffers and MTU in order. And when a crashed application still holds the connection, most discovery tools offer a force-IP or force-control function to reclaim the camera without a power cycle.

Prevention: the settings that decide it

1. Keep the camera handle on a thread that never blocks. Any regular control traffic resets the heartbeat, so a loop that talks to the camera stays alive; a thread asleep at a breakpoint does not.
2. Set the heartbeat timeout to 60 s on the bench and restore the default in production.
3. Run at least three buffers, size the socket buffers for your platform, and set the packet size to the largest your network accepts. None of these keeps a paused connection alive; all of them keep a live one healthy.

The decision, case by case

• A few seconds paused, then one stale frame, then silence: heartbeat expired. Unblock the grab thread, or raise the timeout on the bench.
• Frames stop mid-run with no pause: read the loss counters, then raise queue depth, socket buffers and resend budget in that order.
• Camera missing from enumeration after a crash: boot order, saved configuration, then force-control.
• Rebuilding the station: the rule travels with the interface, not the sensor - every GigE Vision camera enforces the heartbeat the same way:

Browse GigE area scan cameras by interface and resolution, filter the camera finder to what your host can drive, or step through the camera configurator to match sensor, lens and light in one pass. If a stream still dies after these checks, bring your SDK, timeout settings and loss counters to the contact page.