GigE camera buffer was incompletely grabbed: fix lost packets

The acquisition throws an error, the live image keeps rendering, and the failure comes and goes with the hour. That combination — a message worded like "The buffer was incompletely grabbed", sometimes with code 0xe1000014 — is packet loss on the GigE Vision stream, and it is almost always fixable at the network layer. The message names its own suspects: the network adapter, the switch or the Ethernet cable. Here you get the two camera settings that fix most cases, a bandwidth calculation that shows whether the link can carry your stream at all, and the hardware order to work through when the settings are not enough.

What an incomplete grab actually means

GigE Vision sends pixels as numbered UDP packets, and UDP has no retransmission. The camera fires each frame as a burst of packets; if the NIC, the switch or the cable drops one, the lines it carried never arrive. The SDK counts the packets each frame needs, finds the total short and rejects the buffer rather than hand you a torn image. That is why the live view still looks fine — a few lost packets leave a few missing lines — and why the error is intermittent: a loss rate of a fraction of a percent still kills frames, because one missing packet ruins the frame it belongs to.

When the loss rate climbs you see it directly: grey or black horizontal stripes across saved frames. That visible version of the same cause is covered in GigE Vision packet loss: horizontal lines in live images.

Set packet size and inter-packet delay first

Both settings sit in the camera's transport layer category in your SDK's feature tree, and together they fix most incomplete grabs.

Packet size. At the default 1500 bytes, even a moderate stream leaves the camera as tens of thousands of packets every second — each one a chance to drop and an interrupt for the NIC to serve. Raise the packet size to the largest value the whole path accepts, 9000 bytes on most cameras, and the same stream travels as about six times fewer packets. Fewer packets means fewer headers, fewer interrupts and fewer drops.

Inter-packet delay. This inserts an idle gap between stream packets, so they leave the camera at a steady average rate instead of one burst the NIC must absorb. Apply it after packet size, start small and raise it until the errors stop; delay you do not need is throughput you keep.

A useful target is to hold the average near 800 Mb/s so bursts and OS jitter have somewhere to go. The gap after each packet is its transmission time at the target rate minus its time at line rate:

Your SDK enters that delay in the camera's own tick unit, so convert the 18 µs with the tick frequency the camera reports. Note the logic: a 600 Mb/s stream loses nothing under an 800 Mb/s cap, which is why a small delay fixes errors without costing frame rate.

Packet size has one hard failure mode:

If the camera refuses the value you set, the driver and the device have disagreed about the path MTU; the fix is in GigE Vision packet size exceeds MTU: cap auto-negotiation. Set both values before you start acquiring, for the reason in set the GigE camera packet size before starting acquisition.

Worked example: a 2.5 MP stream at 30 fps against a gigabit link

Work out whether the link can carry the stream before touching hardware. The example camera is the MV-CU020-90GC, a 2.5 MP colour GigE camera with a 1/1.7" sensor and a global shutter.

The inputs: 2.5 million pixels per frame from the sensor specification, one byte per pixel for an 8-bit pixel format, 30 fps as the application requirement, and 1,000 Mb/s as the line rate of a gigabit link. The rule: required stream rate equals pixels × bytes per pixel × fps × 8, and the stream must sit well under the line rate once per-packet overhead is added.

The extra 66 B per packet covers IP and UDP headers, Ethernet framing, preamble and inter-frame gap. So the 600 Mb/s payload rides the wire at roughly 630 Mb/s and leaves about 370 Mb/s of headroom on a healthy link — bandwidth is not the problem here, link quality is. If that same link silently negotiates down to 100 Mb/s, the stream needs six times what the link carries and every frame arrives short; that failure and its fix are physical, covered in GigE camera packet size error when your link drops below gigabit.

The decision for any camera: under about 700 Mb/s on the wire, treat incomplete grabs as a link problem and work the hardware list below. Between 700 and 900 Mb/s, add inter-packet delay and trim the stream — smaller ROI, binning, lower frame rate — before trusting it. Over 900 Mb/s, one gigabit port cannot carry the stream: split it across two NIC ports or move the camera to a 2.5G or 10G link.

Then the hardware, in this order

NIC first. An onboard laptop port or an ageing desktop port is the most common culprit: small receive buffers, shallow interrupt handling, no jumbo support. A dedicated PCIe NIC fixes all three. Enable the driver's packet-processing performance options — the measured gain is quantified in the GigE Vision high-performance NIC driver article — and set the adapter's receive buffers to their maximum.

MV-GE2002P is a dual-port PoE NIC, full height, with two gigabit ports for cameras.

Switch second. For a single-camera bench, remove the variable entirely and cable the camera straight into the NIC. If a switch must stay, enable jumbo frames on it and keep office traffic off the camera link; one backup job bursting onto a shared port pushes a marginal stream over.

Cable last, but not never. A damaged or badly terminated run can drop the link to 100 Mb/s, where nothing survives, and marginal pairs below that show up as exactly this intermittent loss. Run one continuous cable with no couplers, keep it clear of motor cables and respect its bend radius. In electrically noisy shops, moving a run from CAT5e to CAT6 is a recurring fix. On any axis that moves, use a cable rated for the flexing: LS-CBL-0199 is a 3 m GigE camera cable with screw locks, built for drag-chain duty.

Fixed runs in every length live in the camera data cables category, from 1 m patch cords to over 20 m.

Multi-camera hosts: divide the link first

Two cameras bursting into one switch uplink is the classic intermittent-loss setup — each camera alone fits the link, together they do not. Budget the bandwidth before wiring, as in multi-camera GigE bandwidth budget: divide the link first. If the cameras share a trigger, their bursts collide packet-for-packet — the case in multiple GigE cameras on one trigger: why frames arrive incomplete. Stagger the cameras by giving each a different inter-packet delay, or give each camera its own port. A frame grabber such as MV-GE1104 gives each camera an isolated gigabit port, and LS-FGB-0004 is the NIC equivalent, a PCIe x4 card with PoE on every port.

Host-side causes that mimic a bad network

If packet size, delay and hardware are right and grabs still fail, the drops are happening inside the host: the OS receive buffer the SDK streams into is too small for a burst of jumbo packets, the NIC shares an interrupt with a busy device, or the acquisition thread is starved until the SDK's queue backs up. On Linux, most camera SDKs capture through raw packet sockets, and undersized socket buffers drop packets before your code ever sees them — raise the OS receive-buffer limits and use the stream path the SDK documents for best performance.

When the wording is buffer overflow or queue full rather than incomplete grab, the host queue is the failure, and the GigE camera buffer overflow checklist walks that path on a widely used acquisition library. A timeout with no image at all is a third, distinct failure, covered in GigE Vision stream timeout: check packets, buffers and MTU.

Prevention checklist

Run this list before signing off the cell:

• Negotiated speed reads 1000 Mb/s, full duplex, in the NIC driver — never 100.
• The packet size read back from the camera equals what you set, and jumbo frames are on for the NIC and any switch.
• Receive buffers and driver performance options are raised on a dedicated NIC, not the onboard port.
• One camera per port, or a written bandwidth budget for shared ports.
• The cable run is continuous and strain-relieved, clear of motor cables, drag-chain rated where it moves.
• A soak test of at least 500 frames completes with the SDK's dropped-packet counter at zero.

The soak test is the acceptance criterion: an error that appears a few times an hour hides in a ten-frame demo.

When it is not packet loss at all

Two other failures get blamed on the network and are not. Frames that arrive whole but tear under processing were copied too late in the callback — the fix is in torn frames in a camera callback: copy the buffer before you queue it. Images that drift against the trigger are a grab-recovery and link-timing problem, in camera image stream out of sync: recover the grab and check the link. The rest of the link-level failures — MTU errors, timeouts, multi-camera budgeting — sit with the systems guides.

Next step: if you would rather have the budget checked before wiring, send the camera model, resolution and frame rate through the contact page, or start the system configurator at the camera step and pair the camera with a NIC and cable that carry it. When the camera choice itself is still open, the camera finder filters GigE models by resolution, shutter and interface.