Camera acquisition high CPU usage: replace busy waiting

High processor load during camera acquisition does not necessarily mean image processing is expensive. A worker can consume a processor core while repeatedly checking an empty buffer queue, especially when triggers are absent. This troubleshooting procedure separates useful processing from idle polling, explains how blocking waits change the load, and shows how to keep shutdown responsive. Use it before replacing cameras or adding processing capacity.

Confirm whether the load exists without frames

Start with a controlled idle test. Keep the camera connected and acquisition initialized, but withhold triggers through the normal acquisition controls. Do not alter a machine safety circuit to create this condition. For a free-running camera, use a documented acquisition mode that permits a valid no-frame test.

Measure these quantities over the same interval:

• Process CPU time and elapsed wall time.
• Acquisition-worker CPU time, if your profiler exposes it.
• Delivered frame count and successfully processed frame count.
• Receive calls, empty results, timeouts, and transport errors.
• Application queue depth and outstanding buffer ownership.

High CPU consumption with no delivered images points toward waiting, retries, logging, or another background task. It does not prove which one is responsible. Sample the worker's call stack repeatedly to identify where it spends execution time.

If images actually stop arriving during normal production, start with acquisition-stall recovery diagnostics. An efficient wait will not repair a broken transport or a failed recovery sequence.

Isolate polling from processing and display

Disable downstream work in stages while keeping acquisition settings unchanged. Remove saving, display refresh, conversion, and inspection separately. Return each received buffer correctly even when processing is disabled.

The following comparisons distinguish common causes without assuming that every high-load condition is a polling problem.

Use a profiler rather than treating this table as a diagnosis. A thread repeatedly entering a nonblocking receive function can look similar to a thread repeatedly handling an immediate error.

For multi-camera applications, distinguish the transport's buffer pool from your application's processing queue. The callback and buffer-queue troubleshooting procedure covers ownership and callback faults that can coexist with inefficient waiting.

Put numbers on idle load and shutdown latency

CPU displays use different normalization conventions. Report your measurement explicitly instead of saying only that the application uses a certain percentage.

For an illustrative idle test, suppose a worker accumulates 12 seconds of CPU time during 12 seconds of elapsed time:

After replacing polling with a blocking wait, suppose the same test records 0.06 seconds of worker CPU time:

These are example measurements, not performance promises. A whole-process measurement can include multiple threads and exceed one core equivalent.

A finite wait of 50 ms produces approximately 20 timeout returns per second when no frames arrive, assuming little work between calls. That is very different from checking an empty queue hundreds of thousands of times per second.

The wait duration is not normally added to every frame's latency. A genuine blocking receive should wake when data becomes available. Verify that behavior in the documented API; a fixed sleep after a nonblocking check behaves differently.

Replace the busy loop with a documented blocking receive

Prefer the acquisition library's supported blocking receive, event wait, or waitable completion mechanism. A function named receive or fetch is not necessarily blocking: check its timeout argument, return statuses, and cancellation behavior.

Use this implementation sequence:

1. Confirm that the camera session is acquiring and the required buffers are queued.
2. Select a documented blocking receive operation with a finite timeout.
3. Check the stop request before entering the wait.
4. On success, process or transfer ownership of the buffer.
5. Return the buffer through its required release path, including on exceptions.
6. On an ordinary timeout, check the stop request and wait again.
7. On a transport or state error, enter a separate, bounded error-handling path.

The control flow should resemble this SDK-independent pseudocode:

while stop has not been requested:
    result = wait_for_completed_buffer(finite_timeout)

    if result is an ordinary timeout:
        continue

    if result is an acquisition error:
        handle_error_with_a_bounded_policy()
        continue

    try:
        process_or_transfer_buffer(result.buffer)
    finally:
        release_buffer_if_still_owned_here(result.buffer)

If ownership transfers to another worker, that worker becomes responsible for release. The receiving worker must not also return the same buffer.

Do not hold an application lock across a blocking receive if shutdown or buffer delivery needs that same lock. Otherwise, replacing polling can expose a deadlock that the original loop merely obscured.

Make the no-frame shutdown path interruptible

An indefinite wait is efficient only when another supported operation can wake it. Without cancellation, a stopped trigger source can leave shutdown waiting forever.

Choose the shutdown mechanism according to the available interface.

For a finite-timeout design, an illustrative 50 ms wait leaves up to roughly 50 ms of remaining receive time before the worker next checks its stop flag. Scheduling, processing already underway, and cleanup add to that interval. This is not a real-time guarantee.

For your own blocking queue, use a dedicated sentinel object that cannot be mistaken for a frame. Do not insert it into a transport-managed buffer pool or camera API unless that interface explicitly documents such a mechanism.

Stop or coordinate producers before declaring the queue finished. If the queue is bounded and full, a blocking sentinel insertion can itself stall shutdown. Provide a documented application policy for draining, discarding, or interrupting that queue. Multiple consumers also need a deliberate notification strategy; one consumed sentinel does not automatically wake every worker.

Never destroy the camera session while another thread can still access its buffers. The slow pipeline-stop diagnostic guide explains how to separate wait time, worker joins, and cleanup delays.

Verify behavior under idle, active, and failed conditions

Repeat the original idle measurement using the same duration, settings, and CPU normalization. Confirm that CPU time falls without hiding errors or changing the delivered frame count during active acquisition.

A practical validation sequence is:

1. Run without triggers for 30 seconds and record CPU time, timeout count, and errors.
2. Resume normal triggering and measure receive-to-processing delay.
3. Request stop while no frame is available and measure worker exit time.
4. Request stop while processing is active and check buffer release.
5. Repeat start and stop 20 times to expose lifecycle races.
6. Test a documented disconnection or timeout scenario on a controlled bench setup.

Choose longer runs when the original symptom appears only after extended operation. Inspect median and worst observed shutdown times, not just the average.

Check memory and outstanding buffers alongside CPU. A change that lowers load but leaves buffers retained is not a successful fix. Use the buffer-ownership memory troubleshooting guide when retained images or unreleased buffers appear during these tests.

Keep timeout logging aggregated. One summary per measurement interval is often more useful than writing a message for every expected idle timeout.

Check the integration before changing hardware

Busy waiting is a software behavior, not a reason by itself to replace a camera. Confirm the supported operating system, acquisition library, transport component, and driver combination. Obtain updates and documentation only from the manufacturer or its authorized distributors.

When a regression follows an update, record exact installed versions and compare against the documented compatibility requirements. The SDK build-mismatch diagnostic procedure helps separate compatibility failures from scheduling problems.

The same waiting principles apply across camera interfaces. The LS-CMR-0053 is a GigE catalog example.

The LS-CMR-0166 is a USB3 catalog example.

These examples identify interface choices; they do not establish support for a particular receive or cancellation API. Verify that behavior in the software documentation before selecting hardware.

Use the area scan cameras category and camera finder when camera selection is genuinely part of the project. For dedicated acquisition hardware, compare vision controllers against measured camera traffic, processing demand, and I/O requirements—not against CPU consumption caused by an empty polling loop.

Know when blocking waits are not the complete answer

A blocking receive reduces idle polling. It does not reduce the work required to inspect each image, correct a transport fault, or make an undersized processing pipeline keep up.

For example, a serial inspection stage taking 40 ms per image can process at most approximately 25 images per second:

If images arrive at 30 per second, the queue grows unless you reduce work, introduce valid parallelism, or apply a deliberate frame-handling policy. Additional buffers postpone exhaustion; they do not remove the sustained mismatch.

Specialized low-latency designs may intentionally use bounded spinning before blocking. Treat that as an explicit tradeoff supported by latency measurements and a processor budget. It should not be an accidental infinite loop.

Adding a fixed sleep can serve as a temporary diagnostic, but it is not equivalent to event-driven waiting. It can add frame pickup delay and still fail to provide a reliable shutdown path.

Prevention checklist and next step

Before accepting the change, confirm that:

• The idle worker blocks rather than repeatedly testing an empty queue.
• Ordinary timeouts and acquisition errors follow different paths.
• Stop requests are handled when no images arrive.
• Every acquired buffer has exactly one final release owner.
• Queue capacity and full-queue shutdown behavior are defined.
• Locks do not prevent completion delivery or cancellation.
• Active throughput and image latency remain acceptable.
• Logs capture useful counters without flooding the system.
• Camera resources are closed only after dependent workers exit.

Keep the measurements with your application configuration so later updates can be checked against the same baseline. If hardware selection remains necessary, start with the camera configuration step. For help matching acquisition requirements to parts, send the measured frame load, idle CPU results, and shutdown target through applications support.