Software trigger delayed by seconds: fix the packet size

You write the software trigger feature to a GigE camera, the call blocks for seconds, and the frame still arrives. Nothing in your trigger logic is wrong. On a GigE Vision camera, a software trigger is a command on the control channel, and the command is complete only when the camera's acknowledgement comes back. Lose that acknowledgement and your SDK waits out its timeout, resends, and returns late: tens of milliseconds normally, whole seconds occasionally. The most common cause is not code at all. Large stream packets that speed up image transfer can make some camera firmware drop command acknowledgements, and the retry timeout is what you are measuring. This guide shows how to confirm it in ten minutes, what to change, and the two other causes worth checking: exclusive session access and the Ethernet link itself.

What the fault looks like

The signature is an intermittent pause on the feature write that fires the software trigger. A typical trace shows calls returning in about 90 milliseconds, with occasional outliers near 5 seconds. The trigger still executes and the image is clean, so acquisition looks healthy while your cycle time jumps. It reproduces in a plain console application as well as through a managed wrapper, which rules out the language binding, and it survives cable and switch swaps.

Stress it by cycling open, configure, acquire and close in a loop, timing each pass: this fault fails within a handful of passes and keeps failing at a similar rate. Distinguish it from two neighbours. If the write returns promptly but no frame ever arrives, that is the one-shot capture that misses frames, covered in Software trigger image timeout: why one-shot capture misses frames. If the write returns but the camera never fires at all, work through Camera trigger ready timeout: diagnose software triggering.

Why one lost acknowledgement costs seconds

A software trigger is not a fire-and-forget pulse. It travels as a command on the control channel: your SDK sends the request, the camera executes it, and the acknowledgement has to come back before the write call returns. Every feature write rides the same handshake — exposure, gain, packet size — which is why runtime feature writes stall the same way; the mechanics are the ones behind Access GigE camera registers at runtime from your control code.

When a reply is lost, the sender waits out its timeout and resends. The stall you measure is that wait:

The timeout belongs to the driver stack, not your code, and it is sized in seconds, which is why the symptom is seconds and not milliseconds. The arithmetic above is illustrative — five seconds fits two attempts at a 2.5-second timeout as well as one attempt at five seconds — but either way, a lost reply is the only thing on that path expensive enough to explain the number.

Why does a reply go missing? Inside the camera, the control channel and the image stream share firmware and the same Ethernet interface. Some camera firmware releases carry documented errata in which the acknowledgement for a control command is dropped when the stream runs at large packet sizes. The stream keeps flowing, so nothing looks wrong on the network; only the control write pays.

Check the packet size first

Highest probability, least invasive test. Set the stream packet size to 1500 bytes — the payload of a standard Ethernet frame, accepted by any switch without jumbo support — before starting acquisition, then re-run the identical timing loop. In the recorded trace behind this symptom, the open-configure-acquire-close loop failed within three passes at the large packet size, then ran more than twenty clean passes at 1500 bytes, with write times back near 90 milliseconds.

The same setting governs stream throughput, so it deserves a deliberate choice rather than a leftover default; Set GigE camera packet size before starting acquisition shows where it lives in the feature tree and how to set it before the stream starts.

If 1500 bytes removes the stalls but you need jumbo frames for bandwidth, treat the loss as a firmware defect: check the release notes or errata for your exact camera model, plan an update through the manufacturer's official channel, and re-run the timing log at the larger size before you go back.

Then check exclusive session access

Some control operations require exclusive access to the camera session, and they block other access until the holder releases it. A viewer application left open, a diagnostics tool, or a second thread in your own process polling features can contend with the trigger write and delay it. A five-second wait is longer than a typical contention pause, which places this second in the order, not first.

The test takes two minutes: one process owns the session. Close every other handle and application, re-run the loop, and watch whether the stalls track the second tool being open. Where several programs need camera state, have the owning process publish the status instead of opening parallel sessions — the ownership pattern is laid out in Software trigger ownership in image acquisition. The same discipline carries to USB3 stations, where multi-camera control transfers freeze until serialised (Multi-camera USB control transfer freezes: serialise and recover).

Then check the link

After packet size and session, the link is the remaining suspect, and it leaves different fingerprints. A link that renegotiates or drops speed announces itself at the next acquisition start: a GigE link below gigabit commonly raises a packet size error, as covered in GigE camera packet size error when your link drops below gigabit. Lost stream packets show up as blank or torn frames, a separate diagnosis with its own test in GigE Vision stream packet loss: diagnose blank frames.

A control write that stalls while the stream stays clean and the link holds gigabit points back to causes one and two. Confirm the basics anyway: both ends at 1 GbE, no renegotiation events in the switch log, and clean port counters.

What 1500-byte packets cost in bandwidth

Dropping the packet size is not free, so put a number on it. Every stream packet carries roughly 60 bytes of Ethernet, IP, UDP and stream protocol headers. At 1500-byte packets that is 60 / 1500 = 4 percent overhead; at 9000-byte jumbo frames it is 60 / 9000 ≈ 0.7 percent. A 1 GigE link moves 125 MB/s on the wire:

Now divide by a frame. A 12 MP mono frame at 8 bits is 4000 × 3000 pixels × 1 byte = 12,000,000 bytes = 12 MB. At 120 MB/s that is 10 frames per second; at 124 MB/s it is about 10.3. The packet size change costs a third of a frame per second at this resolution, while one five-second stall costs 5000 milliseconds against a 90-millisecond write. On any station where trigger latency matters, 1500 bytes is the right starting point, and you raise it only when a measured bandwidth test says the 4 MB/s difference matters.

Reproduce, fix and set a pass criterion

1. Log the write. Wrap the trigger write in a monotonic, high-resolution timer and record every duration. Run at least 50 writes; the mean says the link is healthy, the worst case says whether acknowledgements are going missing.
2. Set the packet size to 1500 bytes before acquisition and re-run the identical loop. Outliers gone: cause confirmed, keep the setting or plan the firmware update. Outliers persist: continue.
3. Close every competing handle. One session owner, no viewer tools, no parallel feature polling from other threads. Re-run and watch whether stalls track any second tool.
4. Check the link. Both ends at 1 GbE, no renegotiation in the switch log, clean port counters.
5. Agree the pass criterion before you call it fixed: for example, 100 consecutive writes with a worst case under 200 milliseconds, plus 20 open-configure-acquire-close passes with none exceeding its cycle budget.

Prevention and the decision

• Packet size policy. Start at 1500 bytes. Raise it only after a bandwidth test shows the payload difference matters, and re-run the trigger timing log after every raise or camera swap.
• Firmware policy. Read the release notes when you qualify a model; install updates only from the camera manufacturer or its authorized distributor, matched to the exact model and current version.
• Session policy. One process owns each camera for the whole shift; other programs read its status, never the camera.
• Timing design. When the trigger moment must be exact, take it from the machine controller as a hardware trigger, and keep software triggering for setup and slow cycles.

The decision, case by case. Outlier stalls of one to five seconds on a clean stream: set the packet size to 1500 bytes now and qualify a firmware update before returning to jumbo frames. Stalls that track another tool being open: restructure to a single session owner. Stalls alongside acquisition errors or a sub-gigabit link: repair the link first, then re-measure the writes. None of the three fixes is a rewrite of your trigger code.

If you are standardizing cameras for a multi-camera trigger chain, these GigE Vision area scan models share the same control-channel handshake, so the same packet size policy applies from day one:

Their differences are interface, shutter and sensor format rather than the handshake, so match those to the station:

All 3 share: Binning Supports 1 × 1, 2 × 2, 4 × 4; Lens mount C-mount; Humidity 20% RH to 95% RH (no condensation); Compatibility GigE Vision V2.0, GenICam; Certification CE, RoHS, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

To check interface and bandwidth fit against your cycle, use the camera finder or start at the camera configurator; the area scan cameras category lists the full range, and more acquisition-side fixes sit under the systems topic.