Smart camera image buffers full: match capture to processing rate

A smart camera that runs clean for hours or days, then reports its image buffers full and stops taking pictures, has a timing problem rather than a broken camera. Captures are landing faster than processing can clear them, so the camera's small, fixed ring of image buffers fills and new captures are refused until processing drains the queue. This page gives you the queue arithmetic, a worked example at a 100 ms cycle, the causes ranked by probability, and the fixes in the order to try them: gate the capture, cut the per-image processing time, or move the inspection to a vision controller. One fact to hold onto throughout: while the buffers are full, no images are taken, so the parts presented in that window leave uninspected.

What the buffers-full status actually means

A smart camera acquires into a ring of image buffers: acquisition writes each new capture into the next free buffer and the inspection engine consumes them from the front of the queue. The ring is small and fixed — 32 images on the platform behind this failure pattern, and comparable counts on comparable smart-camera hardware. While processing keeps pace, the queue never holds more than an image or two.

When every buffer holds an image that has not been processed yet, the camera sets IMAGEBUFFERS_FULL in its CameraStatus and refuses further captures. The refusal is deliberate: the alternative would be overwriting an image nobody has inspected. The flag clears itself — no reset function block exists or is needed — as soon as processing finishes enough images to free at least one buffer, and capture resumes on the next trigger.

Clearing is not the same as being fixed. If the average processing rate still trails the capture rate, the next capture consumes the single freed buffer and the flag re-sets at once. You see the status alternate between full and ready a few images at a time for as long as the ratio holds at or above one.

Two neighboring conditions are not this fault. A camera that sits at not-ready right after power-up or program load has a ready-gate problem, covered in Smart camera misses first images after load: fix the ready gate. And frames that vanish one level up — a PC or controller pulling from a network camera faster than its software consumes them — follow the same arithmetic at the receive queue; Acquisition faster than processing: fix the frame rate gap works that case.

How fast the queue fills

Queue behavior is plain arithmetic. Two rates matter: the arrival rate λ, the images per second that capture delivers, and the service rate μ, the images per second that processing finishes on average. The queue grows whenever λ exceeds μ, and it grows at exactly the difference between them.

Two properties of that last line drive every decision below. Fill time scales linearly with N, so a camera with 16 buffers fills in half the time of a 32-buffer camera under the same load. And the ratio that decides stability is utilization, ρ = P_avg / C: the queue is stable below 1 and fills in finite time at or above 1.

P_avg is not a datasheet number and not your best-case number. It is the mean of measured processing times across your worst real parts, outliers included, over at least one full shift.

Worked example: 100 ms capture against 101.5 ms average processing

The case comes from the field: one capture roughly every C = 100 ms, so λ = 1000 ÷ 100 = 10 images/s, an inspection that normally finishes within 100 ms, and a ring of N = 32 buffers. The load assumption: 1 image in 100 needs 250 ms — the kind of outlier that deep template searches and dense scenes produce — and those outliers arrive in runs rather than spread evenly.

The rule: average the processing time across the mix, convert the average to a service rate, and divide the buffer count by the rate deficit.

• Average processing time: P_avg = 0.99 × 100 ms + 0.01 × 250 ms = 99 ms + 2.5 ms = 101.5 ms
• Service rate: μ = 1000 ms/s ÷ 101.5 ms = 9.852 images/s
• Rate deficit: λ − μ = 10 − 9.852 = 0.148 images/s
• Time to fill the ring: t_fill = 32 ÷ 0.148 = 216 s, about 3.6 minutes

A single slow run is more damaging than the average suggests. If ten consecutive images each take 250 ms, one second delivers 10 images while processing completes 1000 ÷ 250 = 4: the queue grows by 6 images in that second. Five such seconds add 5 × 6 = 30 images on top of the one or two normally in flight — enough to fill all 32. That is why clustered outliers trip the flag even when the daily average looks safe.

Result: utilization ρ = 101.5 ms ÷ 100 ms = 1.015, and the ring fills in about 3.6 minutes of continuous running.

The decision: budget ρ at 0.85 or lower — on a 100 ms cycle, P_avg ≤ 85 ms. Service then reaches 1000 ÷ 85 = 11.8 images/s, so after any full event the camera drains the ring in 32 ÷ 11.8 = 2.7 s and capture resumes. Outlier debt pays back comfortably too: 1% outliers at 250 ms cost 36,000 × 1% × 150 ms = 54 s of processing debt per hour, against 3600 × (1 ÷ 0.85 − 1) = 635 s of spare service capacity per hour, roughly 12 times the debt. Above ρ = 0.90, plan for periodic full events and treat the flag as an alarm rather than a buffer.

Likely causes, in order of probability

Rank the suspects before changing anything; each row has a test you can run from logs and counters.

Causes 1 and 2 cover most cases of this pattern. Cause 4 explains the complaints that arrive as a report that the system ran fine for weeks: processing time drifts as part appearance drifts, and a loop that allocates and frees memory every frame adds spikes on top. Keep the loop's memory behavior flat — Reuse image buffers instead of per-frame allocation shows the pattern — and when a vision library is called from C#, Preventing memory leaks when calling a vision library from C# gives the ownership rules that stop the slow growth.

Fix the capture side first

Slowing or gating capture is the cheapest fix and costs no image quality.

1. Trigger on the part, not on a timer. A part-present sensor driving the hardware trigger means the camera shoots only when there is something to inspect, and idle time becomes free queue capacity. If the trigger line misbehaves — one shot, then nothing — start at Hardware trigger stops after one frame: check acquisition mode; software-issued captures that return late or not at all are covered in Software trigger image timeout: why one-shot capture misses frames.
2. Lengthen the period until the budget holds. With the worked example's P_avg of 101.5 ms, the period must satisfy C ≥ 101.5 ÷ 0.85 = 119 ms; the next practical setting is 125 ms, which is 1000 ÷ 125 = 8 images/s. You trade 2 images/s of throughput for a queue that drains instead of filling.
3. Hold triggers while the flag is set. At the 85 ms budget the camera frees the whole ring 2.7 s after a full event. Pausing triggers for that window turns a stuck camera into a short, visible pause.

Cut the processing time per image

Processing time falls fastest when processing sees less image. Two levers, in order of payoff:

• Restrict the region. Run every tool on the part's ROI rather than the full frame, and bound matching search areas to the neighborhood the position result allows. A guided search costs a fraction of a full-frame search.
• Reduce the pixels. Downscale after capture and match on the reduced image — Downscale images after capture and match on-camera resolution shows how to keep coordinates aligned. Pixel-limited operations fall roughly in proportion to pixel count, so 6 MP reduced to 1.5 MP is close to a 4x cut in their share of the budget.

Processing time also scales with image size and with the number of tools chained behind them; the machine vision processing time versus image size guide works through that relationship. Re-measure the p99 after every change: the budget applies to the p99, not to the best case.

The cleanest version of the fix is a camera that bounds the whole inspection in firmware:

The LS-SMC-0063 runs its 1.6 MP inspection on camera at 60 fps. That is a 16.7 ms service time — 1000 ms ÷ 60 — which leaves room for outliers inside most pick-and-place cycle times.

When the defect needs pixels, keep the processing on camera and step up the sensor:

The MV-SC5060XM-08M-WBN keeps 6 MP on the sensor and inspects on camera, so the ring stays in firmware while you hold resolution for small features.

For presence, code and orientation checks at the low end, a vision sensor covers the same timing logic:

When the ring is the wrong tool: move to a vision controller

If the inspection genuinely needs more than about 85% of the cycle — high resolution plus heavy tools — stop budgeting and re-house the queue. A vision controller acquires into software buffers you size in memory, drains several cameras on one timeline, and turns the fixed firmware ring into a queue you can monitor and enlarge.

A controller sized for several GigE cameras on one pipeline:

The MV-VC5525-256G70-NN pairs an Intel Core i5 (12th gen) and 32 GB of memory with 5+ LAN ports and PoE camera ports, so several cameras feed one inspection process.

Two disciplines transfer with the move. Size the receiving queue for the worst burst, not the average: one second of captures at 10 images/s against a stalled consumer is 10 images you must hold somewhere. And keep the callback path short, because most multi-camera stalls are the consumer blocking the acquisition thread — Multi-camera acquisition freezes: callbacks and buffer queues dissects that failure and its fix.

Checks before you close the ticket

• Measured utilization. Mean processing time over the worst shift part mix sits at or below 85% of the capture period, and p99 at or below 100%.
• Reconciled counts. Trigger count and completed-image count match across one production minute — no hidden bursts, no silent skips.
• Rehearsed recovery. Force a full event by issuing triggers with processing deliberately stalled, stop the triggers, and time the recovery: the flag must clear within N ÷ μ (2.7 s at the 85 ms budget) and capture must resume on its own.
• Wired counter. A missed-shot counter driven by the flag event lands in production data, so any future event shows up as a number rather than as a customer complaint.
• No tuning for a dead flag. If the status never returns to ready while triggers are stopped and the queue should be empty, stop adjusting timing: that is outside queue behavior and belongs in a support ticket. Long-running smart cameras have other failure modes with their own recovery paths — Smart camera fatal error after days running: network failure recovery is the pattern to compare against.

Log one shift of per-image processing times and compute ρ before ordering anything. Above 0.85 points at the capture side or the ROI; below 0.85 with a recurring flag points at the trigger path. The smart camera finder and the system configurator size a replacement or an add-on, and a quote request with your cycle time and processing log lets us tell you which side of the ratio to fix. The rest of the acquisition-loop guides sit on the systems topic page.