Multi image capture per trigger: get an image set from one shot

Some inspections need more than one image from a single inspection event: a normal and a processed frame, one image per light wavelength, or a short burst that freezes different phases of motion. Many cameras and smart sensors can deliver that image set from one trigger, but the feature is not always obvious, and a quick test with a vendor viewer can raise expectations your own acquisition code does not meet. This guide shows how to find the multi-frame capability in the camera's GenICam feature tree, how to configure it so one trigger returns several frames, how sequenced lighting gives you the same result with any camera, and how to verify you really collected the whole image list.

What "multiple images per trigger" means

There are two distinct mechanisms, and mixing them up is the most common source of disappointment:

• Multi-frame acquisition. The camera is set to a mode such as MultiFrame or Burst, with a frame count greater than one. A single trigger — software or hardware — starts the capture of N frames, which arrive as N separate buffers on the host.
• Vendor multi-capture imaging. A smart sensor or camera with on-board processing returns several different images per trigger: a normal image plus processed or filtered versions produced by its own imaging pipeline. Those extra payloads exist only if the device's firmware builds them.

A plain area scan camera, such as an MV-CU020-90GC industrial camera, supports the first mechanism through standard features. The second belongs to vision sensors and smart cameras that run their inspection on the device — the smart cameras category covers that class.

The GenICam standard feature naming convention calls the relevant nodes AcquisitionMode (values typically include SingleFrame, MultiFrame, Continuous) and AcquisitionFrameCount. When AcquisitionMode = MultiFrame and AcquisitionFrameCount = 4, one trigger produces four frames.

Step 1: Verify the feature exists before writing code

Do this with a generic GenICam browser or a small script against the GigE Vision transport — never assume the vendor's desktop tool is the only way.

1. Connect to the camera and enumerate its full feature tree, including categories that are collapsed by default.
2. Read AcquisitionMode and list its allowed values.
3. Look for nodes named AcquisitionFrameCount, AcquisitionBurstFrameCount, or anything containing "Multi", "Burst" or the vendor's imaging-mode name.
4. For each candidate node, read its minimum, maximum and increment to learn the real limits.

If you cannot find a node you expect, the diagnosis path in GenICam exposure feature discovery for missing attributes applies to acquisition nodes too: check the exact node name, the register cache, and whether the node is only writable in a particular acquisition state. The related GenICam node not existing: diagnose feature access errors guide covers the error you get when a feature simply is not there.

Step 2: Configure the camera for a multi-image set

Order of operations matters: most cameras only accept acquisition settings while acquisition is stopped.

1. Stop acquisition (AcquisitionStop).
2. Set AcquisitionMode to MultiFrame.
3. Set AcquisitionFrameCount to the number of images you want per trigger.
4. Optionally set AcquisitionFrameRate or the inter-frame delay to control spacing inside the burst.
5. Re-arm with AcquisitionStart.
6. Fire one trigger — TriggerSoftware for a software shot, or one hardware pulse if the trigger source is a line input.

For software triggering from a custom application, the pattern in software triggered image capture from a GUI button shows how to keep the trigger write and the image collection on separate paths so the UI does not block the burst.

With a frame count of 4 at a sustained 30 fps, expect the whole set in roughly 0.13 s plus exposure time and transport. Budget your host-side timeout accordingly — a timeout sized for one frame will abort mid-burst.

Step 3: Collect the whole buffer list

The second most common failure is on the host, not the camera. The camera sends N frames; the code takes the first and moves on.

1. Set the acquisition queue depth to at least AcquisitionFrameCount frames at full resolution.
2. After each trigger, loop until you have received N images or a timeout expires.
3. Tag each frame with its index in the burst, not just its arrival time.
4. Only then run your processing on the ordered set.

This is the same buffer discipline described for multi-camera work in multi-camera acquisition freezes: callbacks and buffer queues, and the frame-rate verification habits in high speed camera recording without dropped frames apply to bursts as well.

Getting different image types, not just more frames

If you need a normal image plus a processed or filtered image from one event and your camera has no on-board pipeline, build the set with lighting instead. Sequence the light sources and trigger one frame per channel:

• Frame 1: bright-field light on → normal appearance image.
• Frame 2: dark-field or structured light on → defect-enhanced image.
• Frame 3: another wavelength or coaxial light → texture or surface image.

A light controller with strobe outputs switches channels on command, so one inspection cycle produces a genuine multi-image set from any camera. The technique and its colour-sequencing variant are covered in multi wavelength light: sequence colours to get more from one camera.

The LS-CTL-0322 above is a 4-channel digital LED light controller, 16-24 V, AC100-240V 50/60 Hz, 8 A total output — four independently switchable channels, which is exactly what a three-light sequence needs.

Smart cameras and vision sensors take a different route: the device runs the pipeline itself and can return several image types per inspection. An integrated model such as the LS-SMC-0063 smart camera builds lighting into the unit, so one acquisition can carry different illumination outputs.

Check the device's own documentation for which image types it returns per trigger — that list is firmware-specific and cannot be inferred from the sensor alone.

Hardware trigger timing for bursts

When a PLC or sensor drives the trigger, the pulse must be long enough and clean enough for one acquisition cycle, and the controller must not re-trigger before the burst completes. The frame-rate arithmetic and pulse-width considerations in camera hardware trigger frame rate with external pulses apply directly; for a burst, treat the retrigger timeout as the whole collection time from the formula above, not one frame period. If your PLC logic uses one-shot rising-edge instructions, the PLC one-shot trigger programming guide explains how to keep a single event from firing multiple triggers.

Checklist before you commit

• Feature tree lists AcquisitionMode with a multi-frame or burst value.
• AcquisitionFrameCount maximum covers your set size.
• Host queue depth ≥ frame count × largest expected image size.
• Collection timeout covers the whole burst, not one frame.
• Loop drains all buffers per trigger and preserves frame order.
• Retrigger during a burst behaves as your process expects.
• If using sequenced lights: each channel's strobe duration fits inside its exposure window.

When one-image-per-trigger is the right answer

Multi-frame capture is not always the fix. If the images you want differ only by lighting, but your cycle time budget is tight, a single frame with simultaneous multi-channel lighting and colour separation may be enough. If the "extra" images you saw in a vendor viewer are products of that vendor's on-board processing, no host-side setting will recreate them on a different camera — you either use a device that supports that pipeline or compute the processed images yourself after capture. Matching the mechanism to the device first saves days of driver debugging.

If you are unsure which cameras or controllers fit your inspection cycle, run the system configurator, browse the area scan cameras finder, or ask us through the contact page with your frame count, image size and cycle time.