Pause and resume camera acquisition in a vision system

Breaking out of a frame-receive loop does not necessarily stop the camera. It may only stop your application from collecting images while acquisition, transfers, or callbacks continue elsewhere. This distinction matters when you pause an inspection, change recipes, or close an application without leaving resources active.

To pause and resume camera acquisition predictably, separate image production from image reception and processing. The procedure below helps you define pause behavior, coordinate those layers, handle pending buffers, and verify that resumed images belong to the new acquisition session. Exact commands and their order must follow the camera and acquisition library documentation.

Choose what pause must stop

Decide what the operator's pause request means before choosing an API call. Stopping processing, stopping reception, and stopping exposure are different operations.

Choose the least disruptive behavior that meets the requirement. If you need exposure to stop, merely ignoring frames is insufficient. If you only need inspection decisions to stop, repeatedly closing the camera may add unnecessary work.

The frame-grabber acquisition overview explains the separation between the camera, transport, and receiving hardware. An object called a frame grabber in software is not necessarily a physical acquisition card.

1. Map ownership and vendor controls

List the resources involved: device connection, acquisition object, receiving worker, callbacks, queued frames, and downstream consumers. Identify which component creates, owns, stops, and destroys each resource.

Use explicit application states such as Idle, Starting, Running, Pausing, Paused, Stopping, and Error. A pause request should move through a transition, not immediately claim completion.

1. Find the documented camera acquisition start and stop operations.
2. Find the receiver's start, stop, cancellation, and buffer-release operations.
3. Check whether acquisition runs continuously, for a finite frame count, or in response to triggers.
4. Check whether a stop operation completes the current exposure, aborts it, or only prevents subsequent acquisition.
5. Establish whether callbacks can still execute after a stop call returns.

Give a single lifecycle coordinator authority to execute transitions. UI buttons and inspection logic should submit requests rather than independently closing the same device.

Keep the acquisition objects alive for as long as receiving work uses them. The guide to keeping acquisition alive when callbacks disappear addresses this ownership problem in more detail.

2. Make frame waits interruptible

A worker blocked indefinitely inside a frame wait cannot promptly observe a pause request. Use a documented cancellation mechanism where available. Otherwise, use a finite wait and check the requested state between waits.

A receive timeout is not automatically a camera failure. In externally triggered operation, a quiet trigger source may legitimately produce no frame. Distinguish an expected timeout from a disconnected device, a transfer error, or a worker that has stopped running.

A library-independent control pattern is:

while shutdown has not been requested:
    read requested lifecycle state
    if state requires acquisition to stop:
        acknowledge that the receive worker is quiescing
        hand control to the lifecycle coordinator
        wait for resume or shutdown
    else:
        wait for a frame with cancellation or a finite timeout
        if a complete frame arrived:
            pass it onward with its session identifier
        else:
            classify timeout, cancellation, or acquisition error

This is control logic, not a replacement for vendor API examples. Some libraries require stop commands on a particular thread or prohibit concurrent calls during a frame wait.

For example, a 20 ms wait timeout gives the worker a periodic opportunity to inspect its state. It does not guarantee a 20 ms pause: scheduling, command execution, and pending transfers add delay.

Do not hold a shared lifecycle lock while waiting for another thread to exit. That thread may need the same lock to acknowledge the pause.

3. Quiesce triggers and stop production

For a full acquisition pause, prevent new image requests before dismantling the receiving path. Coordinate this with the machine sequence so no required inspection silently disappears.

1. Mark the application as Pausing and stop accepting new inspection work.
2. Suppress software triggers at their source, or request that the external sequence stop issuing acquisition triggers.
3. Account for triggers already accepted by the camera.
4. Request camera acquisition stop using the documented procedure.
5. Stop or quiesce reception at the point required by the acquisition library.

The exact stop sequence varies. A library may combine camera and receiver control, or require a cancellation operation before a camera command can execute. Follow that contract rather than imposing a universal call order.

Changing trigger mode is not a generic stop command. Some devices require acquisition to stop before trigger settings change. Others can remain armed while waiting for an event, which is useful but different from being stopped.

If you suppress external triggers, verify the event source rather than assuming the camera has stopped because no new images appear. An active receiver with an armed camera is a valid paused state only when that behavior was deliberately specified.

4. Drain or discard pending frames

Stopping production does not erase exposures, transfers, SDK queues, or application queues already in progress. Define a policy for each queue.

• Drain: finish handling accepted work before declaring the pause complete.
• Discard: release pending images without inspection, and record that they were intentionally omitted.
• Retain: preserve selected images for later handling, with explicit age and session checks.

Draining suits an inspection where every accepted part must receive a decision. Discarding suits a preview or a recipe transition where old images would be misleading. Retaining images needs the most careful bookkeeping.

Assign a session identifier to acquisition work and increment it when starting a new session. Carry it with each frame and reject processing output from earlier sessions after resumption. Capture the identifier when work is accepted, not when a delayed callback finally completes.

Release borrowed buffers according to the SDK's ownership rules. A view into SDK-managed memory may become invalid when the receiver stops or reuses its buffers. Copy an image only when necessary, and do not retain a pointer after returning its buffer.

Declare Paused only when the selected completion conditions are satisfied. These might include no active receive call, no outstanding callback, and no previous-session work in the processing queue.

5. Resume in the documented order

Resume should be an explicit transition, not simply a jump back into the frame-wait loop. A receiver cannot obtain images if the camera remains stopped, and a running camera can produce unwanted images before reception is ready.

1. Confirm that the connection and acquisition objects remain valid.
2. Restore any configuration required by the chosen pause method.
3. Prepare buffers, callbacks, and receiving workers.
4. Arm reception and camera acquisition in the documented order.
5. Re-enable the trigger source only after the receiving path is ready.
6. Validate a complete frame from the new session before declaring normal inspection operation.

For externally triggered operation, the system may correctly be armed without receiving a frame. Represent that state explicitly. Confirm readiness through documented status information; use a controlled test trigger only when the machine sequence permits it.

Check frame completeness, dimensions, pixel format, and session identity. Reset any temporal processing state that should not bridge the pause, such as a running average or motion estimate.

If acquisition unexpectedly produces only a single image after resumption, review finite acquisition and trigger-mode checks. That is a different problem from a worker that never restarted.

6. Shut down and recover explicitly

Pause retains resources for reuse. Shutdown releases them. Mixing these operations often creates intermittent access conflicts or callbacks into destroyed objects.

A controlled shutdown normally prevents new work, quiesces production, stops receiving activity, waits for workers and callbacks, releases buffers, and closes the connection. Use the documented ordering for your library.

Avoid destroying a receiver while another thread is executing one of its methods. Do not forcefully terminate a worker as the normal shutdown mechanism; it may leave locks or resources in an undefined state.

Recovery needs its own path. If a connection is lost during pause, do not report a successful resume merely because a local flag changed. Reopen through the supported API, restore required settings, recreate receiving resources when necessary, and validate acquisition again.

For persistent access errors, follow the checks for acquisition-device access conflicts. If pauses fail only under processing load, use the isolation approach for acquisition stalls under load before introducing repeated reconnection attempts.

Verify timing and repeatability

Measure pause completion against the behavior you promised. A UI acknowledgment, the final received frame, and the end of exposure are different events.

A conservative planning estimate for serial pause stages is:

Assume an application budget of 5 ms for dispatch, 20 ms for wait exit, 12 ms for remaining transfer work, and 3 ms for cleanup:

These are hypothetical application values, not specifications for any listed product. Stages may overlap, and scheduling delays can exceed the estimate. Measure under representative load before treating it as an acceptance limit. Host timing alone does not prove when the sensor stopped exposing.

Test at least these conditions:

• Pause while no trigger is arriving.
• Pause during an exposure or transfer.
• Pause with processing slower than acquisition.
• Resume after a long idle period.
• Request shutdown while already paused.
• Disconnect during pause and attempt controlled recovery.

As a project-specific stress test, run 100 pause/resume cycles and log transition durations, incomplete frames, queue depth, and session identifiers. Passing this test is useful evidence, not a universal reliability qualification.

Check interfaces before ordering

Lifecycle control is primarily a software contract, but interface and driver compatibility still matter. Start with area scan cameras and the camera finder to establish the required transport and imaging format.

For a GigE camera example, review LS-CMR-0053. Its listing identifies the interface and shutter type; check the manufacturer's documentation for acquisition commands and trigger behavior.

When the host needs an acquisition interface, compare frame grabbers through the accessories finder. A shared interface name does not establish operating-system, driver, SDK, or application compatibility.

The LS-FGB-0004 is a GigE interface card. Verify the complete host and software combination rather than treating the camera and card as a validated pair.

If the acquisition application runs on a vision controller, check its supported camera interfaces and software environment as part of the same review. Controller hardware does not replace explicit lifecycle management.

When a lighter pause is the better choice

A full acquisition stop is unnecessary when your only requirement is to suspend inspection decisions while retaining live preview. Continue receiving, discard unneeded processing work deliberately, and keep queue growth bounded.

Suppressing triggers can also be preferable when the documented operating mode allows the camera to remain armed. Conversely, a device that cannot retain a usable acquisition session may require documented teardown and recreation instead of a lightweight resume.

Before deployment, confirm the following:

• The pause definition states whether exposures, transfers, or only processing must stop.
• Each resource has a clear owner and a documented stop operation.
• Blocking waits can end without forced thread termination.
• Pending frames have an explicit drain or discard policy.
• Resumed work cannot be confused with previous-session images.
• Shutdown and communication-loss recovery have separate tested paths.

Use the camera configuration starting point to plan the imaging hardware. For help checking an acquisition combination, send the interface, SDK version, operating system, and required pause behavior through application support.