Hardware trigger stops after one frame: check acquisition mode

A camera delivers the first externally triggered image, then the host times out waiting for the next one. Increasing the requested image count or allocating more buffers does not change the symptom. Before changing cables or extending timeouts, check whether the camera was configured to finish acquisition after a single frame.

This troubleshooting procedure separates camera acquisition mode, external frame triggering, and host-side image retrieval. You will establish a repeatable one-pulse, one-image test, identify which layer stops, and verify that the corrected configuration survives application startup.

Separate acquisition mode from host grab count

There are three independent questions: how long the camera acquires, what starts each frame, and how many images the host expects. Confusing these settings can leave the host waiting for images the camera is no longer armed to produce.

With single-frame acquisition, an acquisition start normally permits one frame before the camera completes that acquisition session. A host request for several images does not necessarily restart the camera between frames. Exact behavior depends on the device and acquisition library.

For repeated external frame triggers, the usual configuration is continuous acquisition with frame triggering enabled. Here, continuous describes the acquisition session, not an instruction to expose without external pulses.

Node names such as AcquisitionMode, TriggerSelector, and TriggerMode are common in GenICam-based systems. Verify their availability, permitted values, and interaction in the camera's documented feature set.

The broader hardware-triggered acquisition workflow explains how configuration, stream startup, and image retrieval fit together. The specific distinction here is that a host loop can remain active after the camera's acquisition session has ended.

Test likely causes in order

Start with slow, deliberate pulses and a minimal capture application. Keep image processing, display updates, and disk logging outside the initial test.

1. Check for single-frame acquisition. Read the acquisition mode after applying your startup configuration. If it is single-frame, select continuous acquisition when supported, keep frame triggering enabled, and repeat the test. Recovery of repeated captures strongly supports an acquisition-mode mismatch.
2. Check whether the host stops after its first image. Inspect the grab-count argument, loop condition, callbacks, and cleanup path. A successful first frame can accidentally enter a stop or close operation. Correct the host lifetime independently of the camera mode.
3. Check whether later pulses reach an armed camera. Use documented trigger-ready information or input counters when available. Compare the external signal with the selected trigger source and activation edge. Correct the signal or configuration only after identifying the mismatch.
4. Check whether frames arrive but are not released or displayed. Inspect acquisition status, transport statistics, and buffer ownership. A stalled consumer can resemble a stopped camera even when acquisition continues.
5. Check pulse spacing and exposure constraints. Reduce the trigger rate substantially. If that restores capture, investigate timing limits rather than assuming the acquisition mode was responsible.

A timeout alone does not distinguish these cases. Record the last successful frame identifier, host grabbing state, effective acquisition settings, and available error counters before cleanup changes the evidence.

If capture statistics continue advancing while the display remains unchanged, use the first-frame preview freeze checks instead of treating the display as proof that exposure stopped.

Apply a repeatable configuration sequence

Use a documented configuration order, because some settings become unavailable while streaming. The following is a generic sequence, not executable code for a particular camera library.

open camera
stop acquisition if required by the documented configuration procedure
select continuous acquisition, if supported
select the frame-start trigger
enable that trigger
select the documented external input and activation edge
read back the effective settings
allocate and queue host buffers
start the host stream and camera acquisition
wait for documented readiness, where available
permit external trigger pulses
retrieve and validate each completed image
release each acquired buffer after use
stop acquisition and close cleanly when finished

Do not substitute a guessed input name or electrical connection. Confirm the input voltage range, polarity, pulse width, and wiring from the camera's documentation. For feature-level checks, follow the trigger source and line configuration procedure.

Read back settings after any configuration loader or startup callback that could overwrite them. Where settings remain readable during acquisition, a second readback can reveal library-side changes made during startup.

A viewer can provide a useful independent test, but compare effective settings rather than button labels. A continuously running acquisition session can still wait between external triggers. Close the viewer before testing an application that requires exclusive camera access.

Verify the fix with a timed pulse sequence

Use a hypothetical test of three pulses at 2 Hz, with acquisition armed before the first pulse. The expected exposure starts are separated by half a second, subject to the camera's documented trigger behavior.

Send pulses at relative times of 0 s, 0.5 s, and 1 s. Expect three completed images if every pulse is accepted and transport completes successfully. Do not assume host arrival timestamps equal exposure timestamps; transfer and scheduling add delay.

For this controlled test, a 2 s retrieval timeout provides margin over the nominal 500 ms inter-pulse interval. It is only a test setting, not a general recommendation. If the first pulse is manual, its delay can exceed any short timeout without indicating a camera fault.

Record the following observations:

• The host stream and camera acquisition were started before the first pulse.
• Each pulse produced exactly one completed image.
• Available frame identifiers advanced without unexplained gaps.
• Acquisition remained active between pulses.
• No image arrived during a deliberate interval without trigger pulses.

Repeat the sequence after closing and reopening the application. A fix that depends on settings left behind by a viewer is not yet a repeatable startup configuration.

Only increase pulse frequency after the slow test passes. If failures appear as spacing decreases, continue with the external-pulse frame-rate checks. Exposure, readout, overlap behavior, and transfer capacity then become the relevant constraints.

Distinguish repeated triggers from bursts and extra edges

One image per external pulse is different from several images produced by one pulse. Continuous acquisition does not itself request a burst, and a larger host grab count does not define how one trigger expands into multiple frames.

If the requirement is several exposures following a single external event, investigate documented burst or sequence features. The multi-image capture per trigger guide addresses that different acquisition pattern.

Unexpected images at the beginning or end of a pulse sequence need a separate test. Observe the signal at the camera input using suitable measurement equipment and the documented electrical reference. Startup transitions, contact bounce, or an unintended activation setting can create additional accepted edges.

Check which trigger selector is active before changing settings. An acquisition-start trigger controls a different event from a frame-start trigger. Configuring one does not automatically establish the behavior of the other.

If no external pulses are involved and the application issues software commands instead, use the software-trigger timeout diagnosis. Extending a retrieval timeout cannot replace a missing trigger command or correct the wrong trigger source.

Keep buffer handling separate from exposure control

Adding buffers can absorb temporary delays in image processing, but it cannot extend a single-frame acquisition session. It also cannot recover frames that were never exposed.

As a simplified capacity example, suppose images arrive at 10 frames per second and processing pauses for 0.4 s:

That pause creates demand for approximately four additional image slots. Actual buffer requirements also include buffers already in use, transport behavior, and scheduling margin. This calculation describes temporary storage, not a camera specification.

Release acquired buffers according to the library's ownership rules, including error paths. If you retain images for later processing, determine whether the returned array owns its memory or references a reusable acquisition buffer. Copy image data before releasing the buffer when the documented lifetime requires it.

Use a bounded queue when processing cannot keep pace indefinitely. Decide explicitly whether overload should stop acquisition, reject new work, or discard images. Buffer growth is not a sustainable substitute for adequate processing capacity.

Check hardware requirements before ordering

Changing cameras is usually premature when a repeatable configuration change restores acquisition. If you are selecting new hardware, compare area scan cameras through the camera finder, then request confirmation of the trigger features your application needs.

The LS-CMR-0053 is a GigE rolling-shutter camera. Treat it as an interface comparison candidate, not confirmation of external-trigger support.

The LS-CMR-0166 is a USB3 rolling-shutter camera. Its catalog summary likewise does not establish trigger input wiring or supported acquisition modes.

For either candidate, verify the following before choosing:

• Documented external frame-trigger support and available acquisition modes.
• Input electrical limits, connector pinout, and required cable.
• Minimum pulse width, activation options, and trigger-ready reporting.
• Exposure and readout behavior at the intended pulse spacing.
• Host operating-system, acquisition-library, and interface compatibility.
• Image quality and shutter suitability for the actual part motion.

If you are using vision controllers, check camera interfaces, driver compatibility, and acquisition software support separately. A suitable camera port does not establish the application's trigger configuration or buffer lifecycle.

Finish with a restart and acceptance checklist

Before returning the station to its normal operating sequence, verify that:

• Startup explicitly applies and reads back the required acquisition settings.
• Frame triggering remains enabled while continuous acquisition is selected.
• External pulses begin only after acquisition is ready.
• The host receives the intended image count without stopping early.
• Every acquired buffer is released, including during exceptions.
• Timeout handling distinguishes an expected wait from an acquisition fault.
• A clean application restart reproduces the same behavior.
• Stop and restart operations do not create unintended exposures or duplicate image handling.

The usual continuous-acquisition fix is wrong when the application intentionally needs one frame per separately started acquisition session, or when the camera documents a different trigger architecture. In those cases, implement the documented start-and-complete cycle rather than assuming a host image count will control the device.

For a new installation, start with the camera configurator. For an existing station, send the effective settings, pulse timing, and observed frame counts through application support so the acquisition behavior can be checked before hardware changes.