Preview dropped frames: diagnose stalls and resource limits

A frozen preview does not necessarily mean the camera stopped acquiring. Images can arrive correctly while display work falls behind, buffers remain occupied, or another process prevents exclusive access. For an inspection station, those faults require different fixes. This workflow separates preview dropped frames from actual acquisition loss, measures the resources involved, and identifies when controlled device recovery is appropriate. Start with evidence rather than increasing memory or replacing hardware.

1. Identify which stage stopped progressing

Treat acquisition, processing, recording and display as separate stages. A status message about dropped frames may refer to only one stage, so establish what the software actually counts.

Record these observations over the same interval:

• Completed acquisition buffers received by your application.
• Incomplete frames and transport errors, where the acquisition software exposes them.
• Frames processed and inspection decisions completed.
• Frames written to storage.
• Preview updates and the age of the displayed image.
• Available memory, process memory and outstanding buffer count.

Use frame identifiers and timestamps where available, but check their documented meaning. An identifier gap can reflect filtering, an intentional discard or an acquisition fault; it is not sufficient evidence alone.

For a broader investigation involving several producers, use the workflow for isolating overload from multiple image sources. It helps distinguish one slow preview from shared system saturation.

2. Establish a minimal acquisition baseline

First stop the acquisition through the application's supported controls. On production equipment, coordinate the interruption with process controls without changing protective functions.

Then test one camera, one acquisition process and one stream. Close other preview utilities, background acquisition services and abandoned application sessions. Leave required transport services running.

1. Record the current camera settings and software versions before changing anything.
2. Disable recording, image analysis, overlays and unnecessary pixel conversion.
3. Acquire frames without displaying them, using a supported buffer-handling example or diagnostic utility.
4. Count completed frames and errors over a fixed interval, such as 60 seconds.
5. Enable preview alone, then processing, then recording, repeating the measurement after each addition.

Keep frame dimensions, pixel format, trigger conditions and requested rate unchanged between comparisons. Otherwise, a successful test may simply have reduced the workload.

If acquisition remains stable without preview, investigate the display path before the camera connection. If errors persist in the minimal test, display optimization is unlikely to fix them.

A preview that always stops immediately deserves a different starting point from one that gradually falls behind. Follow the first-frame preview channel checks when only the initial image appears.

3. Calculate the incoming data and buffer budget

Estimate payload throughput before changing memory limits. Use the actual acquired payload size when the software provides it. Padding, packed formats, metadata and multiple image planes can make a simple width calculation inaccurate.

For an unpacked image without padding, the following estimate is useful:

Consider a hypothetical image measuring 1920 × 1200 pixels, stored as one byte per pixel and acquired at 60 frames/s:

• Frame size = 1920 × 1200 × 1 = 2,304,000 bytes.
• Payload rate = 2,304,000 × 60 = 138,240,000 bytes/s, or about 138 MB/s.
• Sixteen acquisition buffers require 2,304,000 × 16 = 36,864,000 bytes, or about 37 MB.

These are decimal units, with 1 MB equal to 1,000,000 bytes. They describe image payload, not required link bandwidth, total memory traffic or total application memory.

If the same image becomes a three-byte color display image, each converted frame occupies 6,912,000 bytes. A separate pool of sixteen converted images adds about 111 MB. Recording queues and analysis copies add further allocations.

More buffers can absorb a temporary scheduling delay. They cannot correct a sustained processing deficit. Suppose acquisition delivers 60 frames/s but a downstream stage handles only 45 frames/s:

The estimate assumes steady rates and initially empty spare slots. Increasing the queue postpones the failure; reducing work or changing the queue policy addresses its cause.

4. Separate preview policy from inspection policy

A preview usually needs a recent image, not every acquired image. Inspection and traceable recording may need every frame. Give those consumers different policies.

For a display-only queue, a bounded latest-frame policy can replace an older waiting image with a newer one. Count these replacements as intentional preview discards. Do not include them in transport-loss statistics.

For inspection or recording, silent replacement is usually unacceptable. Use a bounded queue with an explicit overload response, such as a controlled acquisition pause where supported or a reported process fault. Match that response to the inspection requirements.

Keep display calls, storage writes and lengthy processing outside the acquisition callback. The callback should perform only the supported handoff and bookkeeping, then return promptly. Respect any documented requirement to update the user interface on its own thread.

As a starting test, limit preview refresh to 10 updates/s while acquisition continues at its required rate. Compare acquisition errors, CPU load and displayed-image age against the original configuration. This is a diagnostic setting, not a universal performance target.

If displaying a copied image, make that copy before returning the acquisition buffer. If displaying from a leased buffer, retain ownership only as the software documentation permits. The guide to camera buffer lifetime in managed code explains why a valid image reference can still point to reused storage.

5. Check memory pressure and buffer ownership

Watch memory throughout the test, not just at startup. Compare process memory with system availability and the number of buffers checked out to consumers.

A steadily rising outstanding-buffer count suggests a missing release or a consumer holding frames too long. Stable acquisition buffers with rising application memory instead suggest accumulating copies, processing objects or recording queues.

Check each exit path:

• Normal completion returns or releases each buffer exactly once.
• Exceptions and canceled operations also release their buffers.
• Display widgets do not retain acquisition-backed images indefinitely.
• Recording queues have a defined capacity and overload response.
• Repeated starts and stops do not create additional unreleased pools.

If the backend exposes a documented memory limit, compare that limit with the measured payload and buffer count. Increase it only within the supported process and system memory budget. A larger allocation may also require stopping and restarting acquisition through the documented sequence.

Allocation can fail even when some system memory remains available. Process address-space limits, driver constraints and buffer requirements may matter. For resource-allocation failures, follow the acquisition resource-exhaustion checks rather than assuming all free memory is usable by the receiver.

6. Test competing access before resetting the device

Device ownership problems often appear at startup or after an application exits incorrectly. They can resemble a nonresponsive camera even when CPU and memory usage are low.

Check for another acquisition utility, a duplicate application instance or a background service holding the device. Include processes running in another session. Do not terminate an unfamiliar service without understanding its role.

Use the application's documented stop, close and disposal sequence. Release stream resources and device handles in the order required by its software interface. A preview window closing does not necessarily mean the underlying acquisition handle closed.

The exclusive-access conflict workflow provides a focused path when an interface reports that it is already owned. If conflicts occur only during simultaneous startup, review multi-camera discovery contention.

If ownership is clear but minimal acquisition still fails, try the vendor's documented recovery procedure. Obtain utilities, drivers and firmware only from the manufacturer or its authorized distributors. Apply a device reset or power cycle only when the documentation calls for it and the machine state permits it.

Recovery restores operation; it does not establish the root cause. Preserve logs and settings before resetting whenever practical.

7. Check hardware fit before ordering a replacement

Replace hardware only after identifying the limiting stage. A faster host interface will not fix a display-thread deadlock, and a new camera will not release buffers retained by application code.

When comparing area scan cameras, use the camera finder to narrow the interface and acquisition requirements. Confirm payload format, triggering and supported software through the candidate's documentation.

The LS-CMR-0053 is a GigE camera candidate whose acquisition requirements should be checked against the measured workload.

For host-side options, review frame grabbers through the accessories finder. Check the interface, driver support, host expansion requirements and shared system resources rather than relying on connector appearance.

The LS-FGB-0004 is a GigE host-interface candidate to evaluate against those requirements.

These examples are not a validated camera-and-card pairing. Verify operating-system support, software compatibility, power arrangements and sustained throughput before selecting either component. The camera and frame-grabber compatibility checks explain what an upgrade assessment should include.

8. Verify the fix under the original workload

Restore the required acquisition settings and add each consumer back individually. Test the worst expected combination of preview, inspection and recording, not just an idle desktop.

Run a short comparison first, then a longer trial covering normal startup, operation and shutdown. For example, compare 60-second diagnostic runs before attempting a 30-minute workload trial. Choose final acceptance duration from the process risk and operating pattern.

Record the same counters throughout:

• Acquired frames and incomplete frames.
• Inspection and recording completion counts.
• Intentional preview replacements.
• Queue depth and displayed-image age.
• Process memory and outstanding buffers.
• Acquisition errors during shutdown and restart.

A successful latest-frame preview may discard waiting display images while preserving every required inspection frame. Conversely, a smooth preview is not proof that recording retained every image.

When loss persists without display or processing, continue with the camera frame-rate bottleneck investigation. When the application stops receiving frames entirely, use the acquisition-timeout diagnostic workflow.

9. Keep a short prevention checklist

Before accepting the station, confirm the following:

• Separate counters: preview discards cannot hide acquisition or inspection loss.
• Bounded queues: every consumer has a capacity and a documented overload response.
• Buffer ownership: normal, error and cancellation paths all release resources correctly.
• Memory budget: acquisition pools, converted images and recording queues fit together.
• Single owner: startup prevents duplicate applications from opening the same device unexpectedly.
• Controlled recovery: stop, cleanup and restart follow documented procedures.
• Repeatable evidence: logs include settings, timestamps and the stage that first stopped progressing.

If a hardware change is justified, start with the camera configurator. For an unresolved stall, send the measured payload, queue behavior, error counters and minimal-test findings through technical support so the next step addresses the failing stage rather than the visible symptom.