An encoder-triggered line scan camera hands your acquisition callback a frame flagged incomplete: the web stopped, the encoder paused, or the link dropped data, and the frame holds fewer lines than the height you set. Three questions follow. How many lines can you trust? Which timeout raised the flag? And what is sitting in the rest of the buffer? The answers below come with arithmetic you can run on the frame object itself, a worked example at 12,000 lines per second, and a decision for each case. They apply to any line scan cameras driven from an encoder through an asynchronous loop, whatever the SDK.
Count valid lines from the payload, never from the buffer
An incomplete frame arrives with a status flag and a byte count. The byte count is the truth: it says how much of the frame actually reached your callback. The buffer's allocated height is not truth, it is capacity.
Width is the line length you configured, in pixels, and bytes per pixel follows the output format: 1 for 8-bit mono, 3 for packed 8-bit RGB. Line padding is the filler some sensors add to align each row, and ignoring it overstates your valid-line count; the padding case is covered in buffer height larger than you set: padding lines and the node map.
Two fields can hand you the count directly: the transport's payload-size field, where PayloadSize on a GigE Vision camera states the frame size in bytes, and the delivered image height when the camera writes the partial height into the frame. GigE Vision splits a frame across many Ethernet packets, so delivered bytes are counted at reassembly. Trust the smaller of the reported height and the arithmetic; when they disagree, the payload wins, because it is what crossed the wire.
Who raised the flag: two timers and one test
The flag has two possible owners. The camera raises it when its frame-completion timer expires: the frame needed Height lines of encoder-synchronized triggers, the pulses stopped, and the camera flushed what it had. The host transport raises it when fewer bytes arrive than the camera announced, which is a link problem, not a trigger problem.
In the healthy case the encoder drives everything: one pulse is one line, and the set number of lines closes the frame.
The rates that matter:
The test is the remainder of delivered bytes divided by bytes per line. A zero remainder, landing at your last logged encoder pulse, means the camera flushed a clean partial frame on its timer. A non-zero remainder, or a status that names packets, means data was lost in flight: chase the link, not the encoder. GigE Vision packet loss shows as horizontal lines in live images, and an MTU mismatch between driver and NIC raises the same flag.
The timer also sets a floor on pulse spacing. Take a frame timeout of 0.5 s: the camera needs a pulse at least every 0.5 s, which is 2 pulses per second, and any moving web beats that. A stopped web breaks the rule 0.5 s after its last pulse, and the partial frame appears. Lengthen the timeout or cut the frame height for margin; the cost is noticing a real stop later.
A reused buffer keeps the last frame's pixels
Buffers cycle through a queue: fill, deliver, return, refill. Nothing in that cycle zeroes memory, and no layer of the stack promises to. The lines past the valid count in a recycled buffer are the previous frame's lines, a real image of an earlier part, not zeros and not noise.
Reading to buffer height therefore shows a straight seam with old product below it, and a classifier will happily score the ghosts. The slow-motion version of the same fault, repeated content across frames, is covered in identical lines between consecutive frames: stale buffer or readout.
The decision: copy the valid region out before the frame returns to the queue, the discipline in push the camera buffer back only after copying your frame data, and never index past the valid-line count. Zeroing is a secondary defense where your code allocates the buffers; it makes stale data obvious but changes nothing about what counts as valid.
For the frame itself the safe default is to discard and grab a new one, as in incomplete frames stay incomplete: discard, requeue, grab a new one. Line scan adds one nuance: the valid prefix is genuine data. A surface-defect search can act on 300 mm of a part; a length measurement cannot.
Worked example: 4K line, 1.2 m/s web, stop at 3,000 lines
Use a 4K GigE line scan camera for the numbers:
- Lens mount
- M42
- Interface
- GigE
- Sensor format
- APS-C
- Shutter
- Global
Its listing prints 4096×8 effective pixels and an M42 mount. Assume 8-bit mono output and no line padding. Set the lens to cover 409.6 mm of web, so the cross-web pitch is 409.6 mm ÷ 4096 pixels = 0.1 mm per pixel, and match the along-track sampling to it at 0.1 mm per line.
- Web speed: 1.2 m/s = 1200 mm/s.
- Line rate: 1200 mm/s ÷ 0.1 mm = 12,000 lines/s. The line period is 1 ÷ 12,000 = 83 µs, so exposure must close inside 83 µs.
- Frame height: 8192 lines. One frame spans 8192 × 0.1 mm = 819.2 mm of web and completes in 8192 ÷ 12,000 = 0.68 s.
- The web jams after 3,000 lines. Bytes per line: 4096 × 1 = 4096 B. Delivered payload: 3,000 × 4096 = 12,288,000 B, about 12.3 MB.
- Valid lines: 12,288,000 ÷ 4096 = 3,000, remainder zero, a clean camera-side flush covering 3,000 × 0.1 mm = 300 mm of web.
- The full buffer is 8192 × 4096 = 33,554,432 B, about 33.6 MB. The 8192 − 3,000 = 5,192 unwritten lines hold the previous part.
Is 12 kHz the reason frames go incomplete? No. The LS-LCM-0016 is a 2K GigE line scan camera rated at 58 kHz with TDI, and the example rate is about a fifth of that ceiling.
- Lens mount
- M42
- Interface
- GigE
- Line length
- 2K
- Pixel size
- 7 μm
Tell the four cases apart
| What you observe | Cause | Decision |
|---|---|---|
| Payload divides by bytes per line exactly, ending at the last encoder pulse | Camera flushed the frame on its timer | Process the valid prefix or discard; keep pulses flowing through stops and splices |
| Non-zero remainder, packet status in the log | Link lost data | Fix the NIC, MTU and cabling; leave the encoder alone |
| Flag appears only at full speed with the encoder steady | Bandwidth shortfall | Throttle the camera or move to a faster interface |
| Old product below a straight seam in the image | Code read past the valid-line count into the recycled tail | Crop every downstream operation to the valid-line count |
The third row is its own problem: incomplete frames from bandwidth: fix packets and throughput covers the acute case and incomplete frames in long GigE acquisitions the sustained one. On the host side, real throughput comes from the NIC or grabber, and frame grabbers are chosen for exactly this. A dual-port PoE NIC such as the MV-GE2002P powers and carries data for one or two GigE cameras.
- Interface
- GigE
- Ports
- 2 ports
Checks before you release the line
- Force one deliberate stop during commissioning and confirm the valid-line count against the encoder's pulse count for that frame.
- Log valid lines divided by frame height on every frame, not just the flagged ones, and alarm under a floor such as 95%.
- Copy the valid region, then requeue the buffer; never hand the full buffer downstream.
- Derive bytes per line from the sensor's actual row size, not from width times bit depth, whenever the sensor pads rows.
- Mount the encoder on the driven roll so splices and breaks either keep pulses coming or stop them cleanly; see encoder-triggered line scan capture: wiring quadrature inputs and encoder ticks per pixel for line scan.
- Pick the trigger path deliberately; line scan camera encoder trigger: software or hardware lays out the trade.
When the usual fix is the wrong one
Zero-filling the buffer and processing full height is wrong twice: it hides the fault and inspects stale pixels with confidence. Raising the timeout to cure a link problem is worse, because it masks packet loss and stretches latency for every frame. Stitching or averaging across the seam mixes two different parts into one image. And moving to an area scan camera in line scan mode trades the encoder's length fidelity for trigger simplicity; it does not change buffer hygiene, since the same partial-frame rules apply.
The decision, per case
Encoder stopped or slowed past the timeout: keep the valid prefix for defect search, discard it for metrology, and fix the pulse stream. Link lost data: the frame is suspect end to end, so discard it, then repair MTU, NIC or cabling. Bandwidth shortfall at speed: the camera is not the limit, the pipe is, so throttle or upgrade the interface. Stale tail read past the valid-line count: not a camera fault at all, so crop to the count and the artifact disappears.
If you are sizing the station around these numbers, start at the camera step of the configurator, browse the systems topic, or contact us with your line rate and frame height. Those two numbers are where the valid-line arithmetic begins.
質問
Are the lines in an incomplete line scan frame unusable?
No. Every line the sensor clocked out before the timeout is genuine data, captured under the same exposure and encoder sync as a complete frame. Only the region past the valid-line count is untrustworthy, because it was never rewritten for this frame. If your inspection can act on a short image, such as a surface-defect search, process the valid prefix and flag the part as partially scanned; a full-length measurement should discard it.
Is the incomplete flag set in the camera or in the host?
Either. The camera raises it when its frame-completion timer expires before the set line count is reached; the host transport raises it when the bytes that arrive are fewer than the bytes the camera announced. You can separate the two: a payload that ends exactly on a line boundary matches a camera-side flush after a stopped encoder, while a ragged payload or a packet-specific status points at the link.
Should I zero the buffer before queueing it again?
Only as a secondary defense. Zeroing makes stale data easy to spot, and where the SDK lets your code allocate the buffers you can do it once at start-up. It does not change what counts as valid: a zeroed tail is just as wrong to inspect as an old-image tail. The primary rule stays the payload-based valid-line count, and copying only that region out before the buffer returns to the queue.
Can I stop the camera from flushing partial frames?
Only by feeding it lines. The frame stays open while encoder-synchronized triggers keep arriving, so the fix is a pulse stream that never pauses longer than the frame timeout, through splices, stops and reversals. Lengthening the timeout or cutting the frame height buys margin but delays detection of a real stop; arming acquisition per part with a presence sensor removes the idle frames entirely.
Does line padding change the valid-line arithmetic?
Yes. Divide the delivered payload by the padded bytes per line, not by width times bit depth. If the camera inserts filler bytes to align each row, the true line size is larger and ignoring it overstates your valid-line count by the ratio of padded to unpadded size. The check is simple: a correct line size divides the payload with zero remainder; any remainder means the final partial line is not usable.