GigE camera disconnected detection: fail fast instead of freezing

A camera that vanishes mid-run is worse than a camera that never worked. When a GigE camera loses its link - a cable is kicked, a switch port resets, the camera reboots - the acquisition object in your process may stay alive and look normal. Your next buffer fetch either blocks or throws an exception whose type depends on how far the disconnect got, and a GUI built on top of it freezes solid. Detect the disconnection deliberately: check available transport status, guard every fetch with a timeout, and fold acquisition failures into one failure path your recovery code can handle.

What actually happens when the link drops

A typical GigE Vision connection has a control channel kept alive by a heartbeat and a streaming channel carrying image packets over UDP. When the cable pulls out, packets stop. The camera may detect a physical link loss immediately; expiration of the control heartbeat is a separate mechanism. Your application learns about the failure through transport events, failed control operations or missing image buffers.

That is why the symptom is so confusing in practice. A GUI that fetches on the main thread does not necessarily crash - it hangs, because the fetch call sits in a blocking wait with no data arriving. For the stream-side timeouts this connects to, see the GigE Vision stream timeout guide, which covers packets, buffers and MTU in detail.

The three signals you can check

Use these three sources of evidence together rather than relying on one connected flag:

1. Device or transport status. Check your acquisition library for connection-loss events, status queries or documented control-channel checks. Feature names and availability vary; do not assume a universal boolean named DeviceLinkStatus. Start with a once-per-second check off the GUI thread, and bound any network operation it performs.
2. Heartbeat timeout. The heartbeat timeout tells you how long the camera tolerates silence from the controlling host. Read the documented setting at start-up. It governs control-session expiry, not the minimum useful interval for checking image delivery.
3. Fetch behaviour. A fetch with an explicit timeout returns a timeout result or error when no buffer arrives. This also covers streaming failures where the control channel remains available but image packets are lost.

Check transport status and monitor image delivery separately. If the link appears connected but three consecutive fetch timeouts pass, report a stream failure when frames were expected. That is evidence of missing images, not proof that the physical camera disconnected.

Guard every fetch with a timeout

The single most effective change is to never call a blocking fetch without a timeout argument. Acquisition libraries may default to a long or indefinite wait; passing an explicit value converts an unbounded hang into a repeatable, catchable condition. Confirm the timeout units in your library's documentation.

With a 200 ms fetch timeout and three misses before declaring failure, the waiting time is approximately 600 ms, plus processing and scheduling overhead. This estimate assumes consecutive fetch attempts and an expected frame arrival within each interval. Triggered acquisition and long exposures need a different deadline.

Wrap the exception zoo into one failure path

The reason a tidy try/except is hard is that the underlying binding layer can surface different exception types depending on where the disconnect happened: an aborted stream, an invalid device handle, a protocol error or a plain timeout. Catch acquisition errors at the acquisition boundary, translate them to an internal failure state, and keep the details for the log. Do not silently classify unrelated programming errors as camera disconnections.

1. Create one acquisition class that owns the camera and the stream. Nothing else touches them.
2. In its fetch method, call the buffer fetch with an explicit timeout in the documented units.
3. Handle the library's documented timeout and transport exceptions, and log their concrete types and messages.
4. Distinguish a missing frame from a fatal transport failure. Translate a confirmed connection failure into one internal exception type, for example CameraLost.
5. Count consecutive fetch timeouts only while frames are expected. Declare a stream fault after your configurable threshold and stop acquisition through the documented shutdown path.
6. Expose a simple acquisition state that combines transport status and image-delivery health, so the GUI does not need to handle transport exceptions.

Now cable loss, camera reboot, switch reset and driver errors enter the same recovery workflow, while the log preserves their different causes.

Worked example: a GUI that stays responsive

Suppose a user presses a capture button while the camera is unplugged. Without guards, the button handler blocks inside the fetch; the event loop stops painting; the operating system greys out the window. With a worker-based design, the button handler submits a request and returns immediately. The worker uses a 200 ms fetch timeout and reports a fault after three consecutive misses, assuming a frame was expected during each wait. The accumulated waiting time is approximately 600 ms, after which the GUI displays the fault and re-enables the button.

Move acquisition onto a worker thread regardless. A worker with bounded waits can report failures without stopping the GUI event loop. If your freezes involve several cameras sharing one thread, the multi-camera acquisition freezes guide covers the callback and buffer-queue side of the same problem.

Choosing hardware that fails informatively

The camera itself matters less than the acquisition library's documented failure handling. Pick one that fits your resolution and bandwidth, then check how the host reports connection loss and missing frames. A 2.5 MP global-shutter model such as the MV-CU020-90GC is typical for general inspection on GigE, and the area scan camera category has the full range if you need more pixels or a faster interface. Use the camera finder to filter by interface and resolution.

On the host side, separate camera-facing network ports can reduce shared-link contention and help isolate network faults. They do not prevent one blocking acquisition loop from stalling another camera in the same process. A vision controller such as the MV-VC3301H-128G66 provides multiple LAN ports and built-in light outputs. Verify processing capacity with your actual acquisition and inspection workload. Browse the vision controllers category for other port counts.

Recovery: reconnect without leaking

Once you have detected the disconnect, recovery has its own traps:

• Stop and release the old acquisition session through the documented cleanup path before reopening the device. Mishandled session and buffer ownership can cause the slow memory growth described in the C# camera memory leak guide.
• Rescan the device list before reopening. The camera may return with a different address, depending on its network configuration. The Linux GigE Vision discovery guide covers the network-side checks.
• Identify the returning camera by a stable identifier rather than discovery order. The camera-to-port assignment guide explains how to keep camera identities consistent.
• Verify and reapply your required feature set after every reconnect. Exposure, gain and packet settings may persist or reset depending on the device and the type of interruption.
• Rate-limit retries. Reconnect attempts every 250 ms against a device that is mid-reboot just add noise; back off to once per second or slower.

If your failures are intermittent rather than a clean disconnect - a frame drops, the stream stutters, then it recovers - the broader intermittent camera acquisition troubleshooting guide is the better starting point.

When the usual answer is wrong

A status poll returning "connected" does not mean images flow. Image delivery can fail while the control heartbeat keeps the control session active. Packet-size mismatches along the network path are one possible cause. That is why image-delivery health must be part of your acquisition state, not just a link-status boolean.

Likewise, a fetch timeout does not always mean disconnection. A long exposure or an absent trigger can leave the stream without a completed image. Before declaring the camera lost, check the expected exposure and readout time, trigger configuration and trigger arrival. Where an encoder generates triggers, confirm that its pulses reach the acquisition system. If the freeze only happens while you tweak camera features live, the camera feature browser freeze guide describes that specific interaction.

Pre-flight checklist

• Every blocking buffer fetch passes an explicit timeout. A starting range of 100-500 ms may suit frequent frame delivery, but the deadline must accommodate exposure, readout and trigger timing.
• A watchdog checks available transport status off the GUI thread, with bounded control operations.
• Consecutive fetch timeouts mark a stream fault only when frames were expected; the threshold is configurable.
• Documented acquisition failures enter one recovery workflow; the original exception type and message go to the log.
• Reconnect releases the old session, rescans the device list and verifies the saved feature set.
• Retry rate is limited and the GUI shows a state, not a hang.

Build the camera-and-controller pairing around these checks: the system configurator walks through the system components, and the camera-to-port assignment guide covers stable camera identities during recovery. If you would rather have your watchdog design reviewed before a line launch, contact us - free expert support comes with every order.