Acquisition timeout after power cycle: enable continuous transfer

The camera streams perfectly in the vendor's viewer. Close the viewer, start your own driver, and the log fills with acquisition-timeout warnings and a frame counter pinned at zero. Power-cycle the camera, and even the run order that worked yesterday stops dead. That pattern — viewer yes, driver no, a power cycle deciding — is not a network fault and not a buffer-size bug. It is register state: the viewer configured the camera, your configuration file did not, and the reboot erased the viewer's work. This guide shows how to read that failure out of the log, names the register that most often blocks the stream, explains the crash that follows the timeouts, and gives you a cold-boot test plus a timeout budget you can copy.

What the failure looks like in the log

The signature is short, and every line of it means something. The driver prints its register plan, announces startup, then warns and restarts into the same silence:

WARNING: acquisition timeout, restarting!

Frame counters stay at rate [Hz] in 0.00 out 0.00 drop 0%, and after a few cycles the process exits on this exception:

Unable to set StreamBufferCountMax due to failure to determine image size or payload size. [-1009]

The timing lines in the same log clear the network too. Timestamps run from 24.79 s to 30.30 s between configuration load and startup, so the driver took 30.30 − 24.79 = 5.51 s to come up, and 3.49 s of that (25.76 s to 29.25 s) went to finding the camera on the network. Discovery succeeded, the link was up, and the camera still delivered nothing. Found, opened, configured, silent: that combination points at register state.

Decide first: no frames or dropped frames

"Timeout" hides two different diseases, so count frames before you touch anything.

For the general timeout tree — triggers, exposure-linked stalls, buffer starvation — start from diagnosing a camera frame acquisition timeout, then come back here for the power-cycle twist.

The register that blocks the stream

Many thermal GigE cores split acquisition from transfer inside AcquisitionControl. AcquisitionMode set to Continuous keeps the camera acquiring for as long as it is powered. continuousTransferMode decides whether those frames are pushed onto the network continuously as they arrive. With it Off, the camera acquires and holds; a driver that only starts acquisition never sends the extra command, so it waits for frames the camera will never ship. That is exactly what the failing configuration wrote: AcquisitionMode to Continuous, then continuousTransferMode to Off.

The fix is one line — set it On — or delete the key if your configuration template copied it in with Off as its value. The three lines every live-stream configuration has to agree on, written the way the camera's feature list names them, are:

AcquisitionControl/AcquisitionMode: Continuous
AcquisitionControl/continuousTransferMode: On
TriggerControl/TriggerMode: Off

If your camera exposes no continuous-transfer node at all, the same decision lives elsewhere — a transfer or stream start switch — or you capture the viewer's full setup into a user set and load that instead.

Why the viewer hides it until the next power cycle

GenICam register values live in the camera, not on your host. The viewer applies its whole startup sequence and leaves the values in place when it closes. Your driver then runs on borrowed state: viewer first, driver second works; driver from a cold start fails. A power cycle repays the loan and returns every register to its factory default, where the transfer switch sits at Off. If the cameras power down on a nightly schedule, the bug reappears every morning at the same time — a useful signature when you are not sure what you are chasing.

Two habits follow. Close the viewer completely before starting your driver, because a GigE Vision camera serves one controlling application at a time. And remember the persistence cuts both ways: it is why a viewer visit seems to repair things, and why settings tuned once — stream bitrate, for example — survive later reboots, as in keeping camera bitrate settings after a power cycle.

The buffer crash is a symptom, not the cause

The exception at the end of the log names buffers, so the instinct is to tune buffers. Resist it. A driver sizes its receive-buffer pool from the payload of the first frame the camera delivers; that is what "failure to determine image size or payload size" means, literally. With zero frames delivered there is no size to determine, the sizing call throws, and the process exits with [-1009] seconds after the timeout warnings. No buffer count, memory setting or pixel format can conjure a first frame. Restore frame delivery, and the same sizing call completes on its own. Treat that exception as a receipt for the timeout, not as a separate fault.

Fix it from a cold power-up

1. Close every program that can hold the camera: the viewer, other drivers, the last test's nodes. One controlling application per camera.
2. Correct the configuration file: continuousTransferMode to On, or delete the key that forces it Off. Set AcquisitionMode to Continuous for live loops and TriggerMode to Off unless a hardware trigger line exists.
3. Power the camera off, wait five seconds, power it back on. A warm restart keeps register state and proves nothing.
4. Time the boot: ping the camera and write down the seconds until it answers. The number feeds the timeout budget below.
5. Start only your driver. Watch the frame counter: in should climb above zero within a frame period or two of acquisition start.
6. If it stays at zero, compare your logged register plan against the camera's feature list, then work down the causes in the next section.

Set the timeout from measured times

A timeout value should come from the camera's measured cold-start path, not from habit. Add boot time, the driver's open-and-configure time and one frame period, then add margin:

Time the boot once on the bench: 5 s in this example. Take the open time from your own log; the failing run printed 5.51 s. The frame period comes from the stream rate, and the 640 × 512 thermal camera below streams at 50 Hz over GigE:

One frame lands every 1 / 50 Hz = 0.02 s, a rounding error at this scale. Total: 5 + 5.51 + 0.02 = 10.53 s. With 30 % margin: 10.53 × 1.3 = 13.69 s. Set the first-frame timeout to 15 s, and give it a retry that re-reads the log rather than one that loops blind.

The same arithmetic tells you what not to touch. At 640 × 512 with 8-bit pixels and 50 Hz, one frame is 640 × 512 = 327,680 bytes, so the stream runs at 327,680 × 50 = 16,384,000 bytes/s = 131,072,000 bits/s ≈ 131 Mb/s, about 13 % of a 1 Gb/s link. The failing configuration set GevSCPSPacketSize to 1500, and 1500-byte packets carry 131 Mb/s with room to spare. Packet size is not why the pipe is silent; leave it alone until frames flow and then drop.

If frames still do not flow

1. A trigger nobody fires. TriggerMode on with no trigger source leaves the camera armed and silent. Set it Off for free-run, or wire the trigger you actually have; hardware trigger stops after one frame shows how trigger and acquisition mode interact.
2. Acquisition mode left at a single frame. The failing run also set AcquisitionControl/AcquisitionFrameCount to 1: one frame, then silence. Live loops need Continuous, which is the reasoning behind continuous acquisition mode for live image loops.
3. Chunk data the driver reads but the camera does not send. The failing run switched chunk mode off at startup; a partial match surfaces as chunk errors rather than timeouts, and enabling the image chunk first covers that path.
4. Addressing that moved over the reboot, or packets that arrive but drop. Both live on the network side; the two checklists in the decision table above cover them.

If the failure mode is corruption after a power cycle rather than pure silence, the register story differs, and GigE Vision image corruption after a power cycle is the closer match.

Keep it fixed

Three habits keep the bug from returning with the next camera or driver release.

• Make the configuration file the only writer of registers. If a register matters to the stream, it is in the file, and a cold boot followed by a driver-only run proves it.
• Capture a user set instead of trusting defaults. Set the camera up once in the viewer, store the state into a user set with GenICam's UserSetSelector and UserSetLoad, and have the driver select and load that set before starting acquisition. The file then carries only deliberate overrides.
• Keep the cold-boot test in your bring-up script: power cycle, start the driver alone, and expect the frame counter above zero within two frame periods with no timeout line in the log. Ten seconds on the bench beats a morning of remote debugging.

More driver-side checklists like these sit on the cameras topic page.

Choosing the camera side of the integration

If you are specifying hardware for a driver-first build rather than rescuing one, weigh tooling as heavily as resolution: a camera whose feature list you can read end to end, that enumerates promptly after cold boots, and whose SDK examples match your interface pays for itself at bring-up. The catalog's GigE thermal line and the broader GigE area scan cameras category follow this same viewer-plus-driver integration path:

Bench the cold-boot procedure on any camera before it ships to the line. To narrow the field first, the camera finder filters by interface, resolution and spectrum, and the team answers integration questions through the contact page.