Trigger a machine vision camera from a DAQ or SCADA program

You have a SCADA package or a DAQ program timing the process, and you want the camera to snap exactly when the filler valve opens, the part crosses the beam or the press tops out. The camera came with its own viewer and SDK, and bridging the two worlds looks like a programming job nobody budgeted for. It is smaller than it looks: one digital output, one opto-isolated input, one resident camera session. This guide gives the wiring, the trigger settings, the pulse-to-image arithmetic for GigE and USB3, and the four checks that catch the mistakes that eat most first attempts.

Can a DAQ or SCADA program trigger a machine vision camera directly?

Yes. The DAQ's digital output drives a short pulse into the camera's opto-isolated trigger input, and the image travels over the camera's own interface into a resident SDK or GenICam session — the SCADA program times the shot but never carries the image.

Split the job by what each side does well. The DAQ or SCADA program owns event timing; it already knows when the valve opens. The camera session — an SDK client or GenICam program kept running on the vision PC — owns camera configuration and streaming, and publishes the latest frame number or filename as a variable. The SCADA side reads that variable and displays or logs it; it never parses image data.

Your program can also fire a software trigger — a command inside the same session that starts the exposure with no wiring. It works, but the command waits its turn in the host operating system, so shots land milliseconds late and unevenly; on a GigE link with a small packet size they can land seconds late, the classic software trigger delayed by seconds failure. When the shot must catch a moving part, send the hardware pulse. The resident session itself is exactly the pattern in the hardware trigger grab loop in Python.

Why does the save-to-file route cost a second per image?

Every image pays four tolls: the driver writes the file, the SCADA scan waits for its poll, the file is read back, then decoded for display. With a 1,000 ms poll and a 2.5 MB frame the chain lands near 1.1 s — one refresh per second.

Add the tolls up for a 2.5 MB frame — 2.5 MP mono at 8 bit is one byte per pixel:

• write to a 150 MB/s SSD: 2.5 / 150 ≈ 17 ms
• wait for the SCADA poll: up to 1,000 ms at a 1 s scan rate
• read the file back: ≈ 17 ms
• decode, scale and draw: ≈ 100 ms

Total ≈ 1,134 ms, so about 0.9 updates per second — one update a second in practice. The camera and the link finish their part in tens of milliseconds; the file and the poll consume everything else. There is a second cost the arithmetic misses: the viewer application owns the driver, so it must stay open and configured. A colleague closing it at shift change silently stops the snaps.

Decision: at one snap per second or slower, the file route is honest and easy to debug — display the file in SCADA, and annotate it on the way down with the overlay-and-save method. Below 500 ms per snap, stream into memory and let the file become an archive copy written in the background.

What do I need before I wire anything?

You need a camera with an opto-isolated input and its hardware manual, one spare digital output on the DAQ card, a resident SDK or GenICam session on the vision PC, and the Ethernet or USB3 link. A strobed light and controller are optional but standard for moving parts.

• A camera with an opto-isolated input. The I/O section of its hardware manual gives the pin numbers, the input voltage range and the series resistor — those decide the wiring.
• One spare digital output on the DAQ card, 0-5 V TTL or 0-24 V industrial, able to pulse at the cycle rate.
• A resident camera session on the vision PC: the SDK sample or a GenICam client holding configuration and streaming.
• A strobed light and its controller for moving parts: match the light to the part with the machine vision lights finder.

Pick the camera from the area scan cameras range or the camera finder, and pair it with a lens in the camera configurator once the field of view is fixed. The 2.5 MP GigE camera with a global shutter and C-mount used in the worked example:

How do I wire and configure the trigger, step by step?

Wire the DAQ output to the camera's opto-isolated input through the resistor its manual specifies, then set the session to external trigger, rising edge, timed exposure. The eight steps below go from a closed viewer to frames that arrive one per pulse.

1. Start the resident session, not the viewer. Launch the SDK sample or GenICam client that will stay running, and close any viewer GUI so it does not fight you for the camera.
2. Set the image basics. Pixel format mono 8 bit for the example, exposure mode timed, exposure 200 µs, gain as the scene needs.
3. On GigE, fix the packet size first. Set it to the largest value both ends accept before the first live grab (packet size before acquisition).
4. Turn on the external trigger. Trigger mode on, source set to the opto-isolated input line, activation on the rising edge. Names differ by camera family — the GenICam tree shows the exact values, and a wrong one raises the enumeration error rather than failing silently.
5. Set the acquisition mode to keep going. Continuous-with-trigger, so the camera does not stop after the first frame.
6. Wire the pulse. Digital output to the input pin, output return to the return pin, series resistor per the I/O section. Which side sources and which sinks is the first question — the opto-isolated GPIO direction guide settles it, and the GPIO-to-trigger wiring guide covers TTL levels and pull-ups.
7. Pulse at bench settings. Width 1 ms, period 1,000 ms. Manuals list minimum trigger widths of a few microseconds; 1 ms clears them with margin, and the slow period makes miscounts obvious.
8. Confirm it worked. Run 60 s and compare the frame counter to the pulse count — 60 and 60, not 60 and 59. Then set the real cycle and read the frame timestamps: pulse-to-exposure spacing should repeat within microseconds, while frame arrival spacing at the host reflects the NIC and driver (camera and host timing).

How much latency is there from pulse to usable image?

Plan on about 25 ms from pulse to image for a 2.5 MP frame on GigE: roughly 10 µs of trigger delay, 200 µs of exposure and 23 ms of transfer, with microsecond-level jitter. USB3 cuts that to about 7 ms; the file route stretches it back to 1.1 s.

Worked example — 2.5 MP mono, 8 bit, GigE, 200 µs exposure:

• Frame size: 2,500,000 pixels × 1 byte = 2.5 MB.
• Payload rate: a 1 Gbit/s link moves 125 MB/s at line level; with GigE Vision overhead and 9,000-byte jumbo frames the practical payload is about 110 MB/s.
• Transfer: 2.5 MB ÷ 110 MB/s = 0.023 s ≈ 23 ms.
• Delay plus exposure: trigger-to-exposure delay is a camera setting in the microsecond range; take 10 µs, plus the 200 µs exposure = 210 µs.
• Total: 210 µs + 23 ms ≈ 23 ms, call it under 25 ms with the host hand-off.
• Repeatability: the hardware path repeats within 1-2 µs.
• Sustained rate: 110 MB/s ÷ 2.5 MB ≈ 44 frames/s — the link's ceiling; the sensor's own maximum frame rate is the second ceiling, and the lower of the two governs.

The same frame on USB 3.0 at about 380 MB/s: 2.5 ÷ 380 ≈ 7 ms, total under 10 ms.

Decision: at a 500 ms cycle the in-memory path spends 23 ms of every 500. The file path spends 1,134 ms and cannot finish inside the cycle — past roughly one snap per second, nothing file-based survives.

Which camera interface keeps up with my cycle rate?

GigE payloads run about 110 MB/s, USB 3.0 about 380 MB/s and 10GigE about 1,000 MB/s, so a 12 MB mono frame takes 109 ms on GigE but 32 ms on USB3. At two snaps per second GigE still carries 20 MP; past five per second, use USB3 or 10GigE.

Times in the table are transfer only, mono 8-bit frames, exposure excluded:

Decision: one snap every 500 ms or slower leaves headroom on GigE even at 20 MP — 182 ms of a 500 ms budget. Ten snaps per second at 12 MP needs 109 ms of wire time inside a 100 ms cycle, which GigE loses and USB 3.0 wins at 32 ms. Two USB3 models that cover the faster cases:

The MV-CS200-10UM pairs 20 MP with USB3.0 on a rolling shutter, so keep it for parts that hold still while the frame reads out. The MV-CH120-11UC's 12 MP global shutter is the conveyor-safe pick.

Where does the light fit in the trigger chain?

The camera's strobe output mirrors the exposure as a pulse into the light controller's trigger input, so the light flashes only while the sensor integrates — the SCADA program never sequences the light at all. On a part moving 100 mm/s, a 200 µs flash smears the image by 0.02 mm.

Flash time is blur time. Blur = part speed × flash duration: 100 mm/s × 0.0002 s = 0.02 mm of smear. Cut the flash to 100 µs and the smear halves to 0.01 mm — at 20 µm per pixel, that is the difference between one pixel of blur and half a pixel. Set the exposure first, then let the strobe follow it.

The strobe pulse is short by LED-controller standards, so the controller must switch on within a few microseconds of the trigger edge; wire it and read the timing per the camera strobe output timing guide. Brightness drifting between snaps — warm LEDs, aging emitters — is a measurement problem of its own; one approach pairs the trigger pulse with a measured light reading to stabilize lighting changes between machine vision triggers. For parts that need both a short bright flash and a longer ambient frame, alternate two exposure times per trigger without a serial detour.

When should a vision controller replace the DAQ as the trigger source?

Swap roles when the snap feeds an inspection decision: a vision controller hosts the camera session and runtime, generates the trigger and light pulses from its own built-in I/O and light channels, and hands the PLC a pass or fail — the DAQ keeps process control and never touches the camera.

This is the standard layout on a dedicated inspection station: the controller's own program logic fires the trigger within microseconds, its light channels drive the illumination, and the plant SCADA keeps reading results over the network like any other sensor. The DAQ keeps what it is good at — valves, motors, temperatures — and the camera leaves the SCADA PC entirely. Browse the vision controllers range; one unit sized for a four-light station with network room to spare:

The MV-VC3301H-128G66 pairs an Intel Core i3 and 8 GB of memory with five or more LAN ports, four built-in light channels and a VM6200Pro license included.

What goes wrong most often on the first try?

Four failures cover most first attempts: the camera is still in free run, the trigger source points at the wrong input line, the acquisition mode stops after one frame, and the pulse is too short to register. Each has a one-line test and fix below.

• Camera in free run. The pulse lands but every image is unsynced. Turn the trigger on in the session and kill the free-run default (per-camera trigger configuration).
• Wrong input line. The source feature points at a line the pulse never reaches. Pulse candidate lines one at a time and watch the frame counter; the enumeration values differ per family (trigger source not detected).
• One frame, then silence. The acquisition mode stopped after the first shot; set it to keep acquiring (acquisition mode fix).
• Pulse too short to register. A microsecond-wide test pulse can sit under an input's minimum; debug at 1 ms and shorten only once the chain is proven.
• One image where you wanted a burst. That is a mode question, and the multi image capture per trigger pattern answers it.

Once the frame counter tracks the pulse count for a full minute and the frame timestamps sit steady, the SCADA side reduces to filenames and flags. Size the rest of the station — camera, lens, light, mounts — in one pass here:

Send the camera and DAQ card part numbers through the quote form if you want the wiring and resistor values checked against a specific model before ordering, or reach us through contact. The remaining trigger and timing fixes live on the machine vision systems topic page.