Software trigger ownership in image acquisition

A live preview can look healthy while production acquisition misses frames, receives unexpected images, or waits indefinitely. Preview and inspection may share a camera but use different trigger generators, settings, and image queues. The first task is to identify which component actually requests each exposure.

This troubleshooting procedure separates preview behavior from production acquisition, checks the active trigger configuration, and verifies the relationship between requests, commands, and received frames. It applies to layered acquisition systems without assuming that any particular camera, driver, or application automatically generates software triggers.

Separate preview behavior from production acquisition

Treat preview as a separate operating mode until you have proved otherwise. A preview window might display free-running images, issue repeated software triggers, or show images acquired by another component. A moving picture does not establish how production acquisition works.

Start by closing the preview window and disabling its documented background acquisition function. Keep the production acquisition session open only if the software supports that arrangement. Record whether closing preview changes the camera settings or stops the stream.

Use the symptom to choose the first test:

If the preview itself stops updating, follow the separate preview channel checks. A display problem and a trigger-ownership problem can look similar, but require different tests.

Assign one owner to software-trigger commands

Trigger ownership means responsibility for issuing the command that requests an exposure. It is separate from responsibility for opening the camera, receiving buffers, or displaying images.

Several layers may participate:

• The camera executes its supported acquisition and trigger functions.
• The acquisition driver manages communication and buffers.
• A preview component may request images repeatedly.
• An inspection scheduler may request one image for each inspection cycle.
• A manual control may issue a diagnostic trigger.

Choose one trigger-command owner for each operating mode. If the acquisition layer automatically sends a command when an image is requested, the inspection sequence should not add another command unless the documented workflow requires it. If the application owns triggering, automatic preview triggering must not remain active during the production test.

Create a small ownership record containing the operating mode, trigger owner, stream owner, and image consumer. A mode transition should explicitly transfer responsibility rather than leaving two components active.

For failures caused by opening a session for each image, the closest companion is one-shot software-trigger timeout troubleshooting.

Read the active trigger configuration

Read settings from the running acquisition session, not only from a saved configuration file. Some applications apply their own settings after opening the device or starting preview.

Where the device exposes the corresponding GenICam features, inspect the following items:

1. Acquisition mode. Determine whether the session permits repeated frames or stops after a limited acquisition. Continuous acquisition can still use per-frame triggering; it does not necessarily mean free-running exposure.
2. Trigger selector. Identify the event being configured. Settings for an acquisition-start event are not interchangeable with settings for a frame-start event.
3. Trigger mode. Confirm whether triggering is enabled for that selected event.
4. Trigger source. Confirm that the selected source is software when software triggering is intended. A configured input line requires a different trigger path.
5. Command availability and readiness. Check the documented conditions for executing the software-trigger command. An open camera handle alone does not prove acquisition is armed.

Feature names such as AcquisitionMode, TriggerSelector, TriggerMode, TriggerSource, and TriggerSoftware are useful inspection points where supported. They are not a guarantee that every device exposes every feature or permits changes while streaming.

A typical per-frame software-trigger arrangement uses an appropriate frame-start selector, trigger mode enabled, and software as the source. Configure that combination only when the device documentation describes it for the intended acquisition mode.

If only the first frame arrives, investigate acquisition modes that stop after one frame. Although the trigger source may differ, the acquisition-state distinction still matters.

Run a counted acquisition test

Remove processing and display complexity before changing hardware. Use a short diagnostic sequence with preview disabled and one trigger-command owner.

1. Open the acquisition session and apply the intended settings through the documented interface.
2. Read back the settings after initialization completes.
3. Establish a fresh queue boundary using the documented stop, drain, or restart procedure.
4. Start acquisition and wait for the documented readiness condition.
5. Issue one software-trigger command.
6. Wait for a complete frame and record its identifier, timestamp, and completion status where available.
7. Release the image buffer according to the acquisition API.
8. Repeat for 20 requests without enabling preview or manual trigger controls.

For a simple single-frame-per-trigger test, define the intended relationship explicitly:

For example, 20 production requests should produce 20 commands, 20 distinct complete frames, and 20 inspection submissions under this test configuration. This relationship is a test target, not proof that command execution and image delivery are an atomic operation.

Suppose preview issues 20 commands while the inspection sequence issues another 20. The command count becomes 20 + 20 = 40. That exposes competing ownership even if fewer than 40 frames arrive because some commands were rejected.

Conversely, 20 commands and 20 received frames do not prove correct processing if one buffer was submitted twice. Track the frame identifier together with a session identifier, because device counters may restart after reconnection.

For pipelines with concurrent processing, use the principles in matching asynchronous inspection results to frames.

Distinguish trigger readiness, timeout, and stale buffers

A receive timeout does not prove that no exposure occurred. The command may have been accepted before transfer, scheduling, or processing delayed delivery. Sending another command immediately can create ambiguity about which request owns the eventual image.

Build a conservative timing budget for a deliberately serialized diagnostic test:

As a worked example, assume exposure takes 8 ms, readout takes 12 ms, transfer takes 5 ms, processing takes 15 ms, and control overhead takes 10 ms:

These are application assumptions, not product specifications. Real cameras and pipelines may overlap stages. This sum describes the chosen serialized test, not the maximum performance of an overlapping system.

Set receive timeouts from measured request-to-frame latency under the intended load. If the longest observed latency is 120 ms, an initial diagnostic timeout of 200 ms provides 80 ms of additional allowance. That is a starting test value, not a universal recommendation.

If readiness fails before the command is issued, use software-trigger readiness diagnostics. Increasing the image-receive timeout will not fix an acquisition session that never becomes ready.

Also check stale buffers. An image already waiting in a queue can satisfy a receive call without belonging to the latest request. Establish queue boundaries through supported API operations, and avoid arbitrary buffer flushing while another thread still owns images.

Track configuration changes across the session lifecycle

Settings can change at several boundaries: device open, configuration load, preview start, production start, acquisition stop, and session close. A driver may temporarily apply settings and later restore earlier values, but that behavior must be verified in its documentation.

Capture a readback snapshot at each relevant boundary. Include acquisition mode, selected trigger event, trigger mode, trigger source, and any documented automatic-trigger option in the acquisition layer.

A useful comparison is:

• Saved configuration before the application opens.
• Active settings after the driver initializes.
• Active settings after preview starts.
• Active settings after production starts.
• Device settings after the application closes and another supported tool reconnects.

Do not run competing acquisition tools simultaneously unless the device explicitly supports that access pattern. A second tool can introduce ownership conflicts or prevent the first session from operating normally.

When settings revert after restart, follow startup configuration and readback checks. The same principle applies here: verify the final applied state, not merely the file you intended to load.

Record startup writes in order. A correct trigger-source write can be undone by a later configuration load, making a successful write appear ineffective.

Check the hardware path without assuming trigger support

Software-trigger ownership is primarily an acquisition architecture question. Replacing a camera or interface card will not resolve two software components issuing competing commands.

When planning a replacement, compare area scan cameras through the camera finder, then verify the exact device's documented trigger features and supported acquisition software.

The LS-CMR-0053 provides a GigE camera option for interface planning. Its catalog listing alone does not establish the software-trigger behavior required by your application.

The LS-CMR-0166 provides a USB3 camera option. Confirm trigger support, command availability, and driver behavior before selecting it for this workflow.

Review frame grabbers and the accessories finder when the acquisition path requires an additional host interface. A network adapter and a dedicated acquisition device may expose different control paths; verify where the trigger command actually terminates.

The LS-FGB-0004 is a GigE card option. Its presence does not define which software layer owns camera triggering.

If a dedicated acquisition device sits between the application and camera, the guide to frame-grabber acquisition paths explains why the control and image paths must be checked together.

Verify the fix and prevent ownership regressions

Repeat the counted test after every change, then repeat it with production processing enabled. Finally, test the transition from preview to production and back. Ownership must remain unambiguous during transitions, not only after a clean startup.

Use this acceptance checklist:

• One active command owner: preview and manual controls cannot generate competing production triggers.
• Readback matches intent: acquisition mode, trigger selector, mode, and source are verified after startup.
• Commands are logged: each production request has a traceable command attempt and outcome.
• Frames are distinguishable: complete frames carry available identifiers and session context.
• Buffers have one owner: every acquired buffer is released through the documented API.
• Timeout recovery is explicit: delayed frames are reconciled before another request is issued.
• Restart behavior is tested: closing and reopening does not silently change the intended arrangement.
• Failure states are visible: command rejection, incomplete transfer, and processing failure are recorded separately.

A short test establishes the trigger relationship; a longer run under representative load checks whether that relationship survives scheduling and processing delays. Keep both tests in the commissioning procedure.

For an existing system, send the ownership record, settings readback, and counted-test log through technical support. For a new acquisition path, start with the camera configurator and confirm documented trigger compatibility before ordering.