Continuous camera acquisition mode for live image loops

A live preview that displays one image and then waits indefinitely does not necessarily have a transport fault. The camera may have finished exactly the acquisition you requested. This troubleshooting sequence is for applications that start acquisition, repeatedly fetch images, and update a display. Start with the camera's acquisition mode and trigger state, then test buffer ownership and consumption speed. The goal is a stream that stays active, not a loop that repeatedly stops and starts the device.

Distinguish a completed acquisition from a stalled stream

Continuous camera acquisition mode permits repeated image acquisition until a stop condition occurs. It does not, by itself, guarantee free-running images. An enabled frame trigger may still require a separate event for every exposure.

Likewise, a successful buffer fetch only proves that an image reached the application's output queue. It does not prove the camera remains armed or that another exposure will follow.

Use the observed sequence to choose your first test:

For a trigger-driven station, the closest companion is hardware trigger stops after one frame: check acquisition mode. Here, the emphasis is the persistent live-image loop and the distinction between producing and consuming frames.

Read acquisition mode and trigger state separately

Change acquisition settings while the stream is stopped unless the device documentation explicitly permits live changes. Read the values back after writing them; a saved configuration or startup routine can restore an earlier setting.

1. Identify the remote camera controls. Do not confuse a host library's fetch policy with the camera's exposure policy.
2. Select continuous acquisition when supported. GenICam devices commonly expose an AcquisitionMode feature with a Continuous entry. Use the entries actually advertised by your device.
3. Check finite acquisition limits. A multi-frame mode or host-side image limit can intentionally stop delivery after a fixed count.
4. Inspect the relevant trigger selector and mode. For a free-running baseline, disable the applicable frame trigger where supported. For triggered operation, retain the intended source and provide repeated events.
5. Read everything back immediately before starting. Record the active configuration, rather than relying on what a settings dialog previously displayed.

A library option that runs acquisition in the background does not necessarily change the remote camera's acquisition mode. Similarly, a function that retrieves one buffer is not necessarily a single-frame acquisition command.

If software triggers are intentional, use software-trigger image timeout diagnosis to check the relationship between trigger issuance and image retrieval.

Run a minimal start-once acquisition loop

Remove display rendering, file writing, inference, and image conversion from the first test. Fetch and return images while logging their identifiers, status, and receipt times.

The following is lifecycle pseudocode, not an SDK-specific implementation:

configure_camera_while_stopped()
prepare_acquisition_buffers()
start_acquisition_once()

try:
    while application_is_running:
        buffer = fetch_with_finite_timeout()
        try:
            record_identifier_and_status(buffer)
            if buffer_is_complete(buffer):
                preview_copy = copy_required_pixels(buffer)
            else:
                preview_copy = none
        finally:
            return_buffer_to_acquisition(buffer)

        if preview_copy is not none:
            offer_latest_preview(preview_copy)
finally:
    stop_acquisition()
    release_acquisition_resources()

Follow your SDK's documented preparation, camera-start, stream-start, and cleanup order. Some APIs combine these operations; others expose them separately.

Use a finite fetch timeout so shutdown remains manageable. For example, a free-running test at 10 frames/s has a nominal frame interval of 100 ms. A 500 ms timeout spans five nominal intervals, but remains only a diagnostic choice, not a guaranteed bound. External triggers can legitimately arrive much later.

During diagnosis, log the first timeout and the stream state before attempting recovery. Repeated stop/start calls can conceal the original configuration fault and prevent useful counter comparisons.

Return buffers without keeping borrowed image views

A fetched buffer usually belongs to an acquisition pool. Returning it makes that storage available for another transfer. Keeping every buffer indefinitely can exhaust the pool even when the camera remains active.

A context manager may return the buffer when its scope ends. However, an array created from that buffer may still reference the same memory. Sending that array to a GUI does not automatically transfer ownership or preserve its pixels.

Choose one documented ownership pattern:

• Copy the required pixels into application-owned memory, then return the acquisition buffer.
• Use a supported ownership-transfer mechanism and release the buffer when the consumer finishes.
• Process directly inside the buffer's valid lifetime only when processing is short and bounded.

Do not assume that reshaping an array copies its data. Also check pixel format, row stride, padding, and component layout before interpreting the payload.

If the stream stops after consuming the available pool rather than immediately after one image, continue with multi-camera acquisition freezes: callbacks and buffer queues. Those ownership checks also apply to a single camera.

Separate acquisition speed from display speed

A live display and an inspection pipeline often need different queue policies. A preview usually benefits from the newest image. An inspection may require every image, matched to its trigger and part identifier.

Keep acquisition independent of GUI event handling. Use the GUI framework's documented thread-safe update mechanism, and do not let a slow display hold acquisition buffers.

For a latest-image preview, use a bounded application queue and replace an obsolete preview copy when necessary. Do not silently apply that policy to inspection images that must all be processed.

Consider an illustrative stream delivering 20 frames/s. Its nominal frame interval is:

If the consumer needs 80 ms per image, its maximum steady processing capacity is:

A queue with room for four additional images would fill in roughly:

This simplified estimate assumes steady arrivals and processing times. More buffers delay the failure; they do not fix sustained overload. Reduce processing work, change the preview policy, or reduce the incoming rate where the inspection permits it.

Prove where the next image stops

Once configuration and ownership are correct, compare evidence at successive stages. Do not treat a motionless preview as proof of a stopped camera.

Record these observations during the same test:

• Camera acquisition or exposure status, where available.
• Accepted trigger count, where available.
• Transport-completed and incomplete-buffer counts.
• Fetched frame identifiers and their documented meaning.
• Application queue depth and displayed image identifier.
• Host receipt times measured with a monotonic clock.

Feature names and counter availability vary. A frame identifier can also have device-specific reset or wrap behavior, so interpret it using the documentation.

If exposure activity stops after the first image, return to acquisition mode, trigger readiness, and finite-count settings. If camera activity continues but host delivery does not, investigate the transport and acquisition provider. If fetched identifiers advance while the display identifier stays fixed, investigate the GUI path.

For timing interpretation, use camera buffer timestamp latency. Device timestamps and host timestamps cannot be subtracted meaningfully unless their clock relationship is established.

When transfer errors or incomplete buffers appear, move to camera frame acquisition timeout diagnosis. A timeout without transport errors is not enough evidence to blame the cable, interface, or camera.

Check compatibility before replacing hardware

Acquisition mode is a configuration issue, not a reason by itself to replace a camera or add an interface card. First confirm that the acquisition provider supports the device, operating system, pixel format, and required control features.

If one application streams successfully while another does not, compare startup settings and provider selection before changing hardware. The guide to frame grabber SDK support explains that compatibility boundary.

When replacement is genuinely required, compare area scan cameras through the camera finder. The LS-CMR-0053 is a GigE area scan camera. Its listing is a hardware selection reference, not evidence of compatibility with a particular acquisition library.

For host interfaces, review frame grabbers and the accessories finder. The LS-FGB-0004 is a GigE interface card. Confirm its driver and acquisition-stack requirements separately from the camera settings.

Matching interface labels alone does not establish complete compatibility. Verify supported software versions, host expansion requirements, power arrangements, and camera discovery before ordering.

Verify the fix and prevent regression

A successful repair should survive more than an immediate retry. Test repeated retrieval, normal processing load, and an orderly shutdown without restarting acquisition inside the image loop.

Use this acceptance checklist:

• Configuration: Read back continuous acquisition and the intended trigger state after startup.
• Retrieval: Fetch a defined sequence, such as 100 frames, while recording identifiers and status.
• Ownership: Return every fetched buffer, including incomplete images and exception paths.
• Timing: Check queue depth and image age under representative processing load.
• Preview: Confirm that displayed identifiers advance independently of acquisition logging.
• Exceptions: Make a processing operation fail deliberately and verify that buffer cleanup still runs.
• Shutdown: Request closure while a fetch is waiting and confirm that the application exits through documented cleanup.
• Persistence: Reopen the application and confirm that startup settings have not restored a finite acquisition mode.

Continuous operation is not always the correct production setting. A deliberate single-image measurement may need a finite acquisition. A hardware-triggered inspection may correctly wait between parts. Preserve that intended behavior rather than forcing free-running exposures to hide a missing trigger.

Once the minimal loop works, reintroduce conversion, processing, and display one stage at a time. For hardware selection, start with the camera configurator; for a configuration review, send the mode readbacks, trigger arrangement, and acquisition log through application support.