Industrial camera trigger modes compared: free run to PTP scheduled

Every machine-vision camera you can buy today offers more than one way to decide when a frame starts, and the choice shows up directly in image position, blur and timing. Free run, hardware trigger, software trigger, gated exposure, burst, sequencer, ring-buffer pre-trigger and PTP 1588 scheduled trigger all answer the same question — what starts this exposure — with different latency, wiring and determinism. This guide names each mode, gives the latency numbers you can hold a vendor to, and matches modes to inspection tasks: presence checks, in-fixture metrology, high-speed events, multi-camera sync and failure forensics. A worked example puts the arithmetic in one place, so you can decide in minutes whether a photoeye and a hardware trigger line will hold a part inside tolerance on your belt. If your camera already mis-triggers, the linked guides cover the wiring and configuration side.

The short answer: one mode per job

Two modes cover most production lines. When parts arrive one at a time and anything on the machine can produce a pulse — a photoeye, a PLC output, a proximity switch — use a hardware trigger and treat the rest as special cases. Use free run when parts are continuous or when host software picks the frames anyway. The remaining six modes earn their keep on specific problems: exposure control from the signal itself, multi-frame events, per-frame parameter changes, looking backwards in time, and simultaneous multi-camera capture.

Free run: continuous acquisition

The camera cycles at a fixed frame rate with no external signal. The ceiling on that rate is the sensor readout plus your exposure time: the fastest cycle is exposure plus readout, so a longer exposure lowers the maximum frame rate.

The cost is latency. On a request for 'the frame happening now', the camera must finish reading out the current frame, capture a new one in full, then transfer it — on the order of one to two frame periods. At 30 fps that is up to two frame periods of wait, and a fast belt moves a part many millimetres in that window. That is why free run suits live monitoring and host-driven selection, and why it fails when one part must be captured once at a fixed position. The continuous acquisition mode guide shows the host-side loop that pairs with it.

Hardware trigger: the workhorse

An edge on the camera's trigger input starts the exposure, resetting the sensor timing to that instant. With good hardware, the delay between edge and the start of exposure is a few to a few tens of microseconds. Budget 20 µs when you plan a station, and treat a camera whose data sheet will not quote a figure with suspicion. The repeatability of that delay, not its absolute size, is what holds a part in the same pixels every cycle.

In GenICam terms you enable TriggerMode, set TriggerSource to the physical input line, and pick the edge with TriggerActivation — rising or falling. TriggerSelector chooses which acquisition step the line starts; FrameStart is the everyday choice, and FrameBurstStart appears on burst-capable cameras. Before blaming wiring, check that acquisition is armed at all: a camera left in the wrong mode ignores the line entirely, a trap covered in hardware trigger configuration per camera and in a GigE camera ignoring its external trigger.

Two practical limits shape the design. The camera must re-arm between frames, so pulses arriving faster than the re-arm time are dropped — the guide to camera hardware trigger rate with external pulses works through that arithmetic. And the trigger input lives on the I/O connector as its own line: whether you need a camera GPIO cable answers the cabling question before you order. Stations that display over HDMI and take a PLC pulse have the wiring side covered in PLC external trigger solutions for HDMI cameras.

On the host side, one wait call per frame keeps the queue from drifting — the hardware trigger grab loop in Python is a working pattern. For a PLC-driven station, start from a GigE model in the area scan cameras range, with the trigger line set up in the vendor tool before your own code runs:

Software trigger: one command, no extra cable

A command from your software — TriggerSoftware in GenICam terms — starts a single frame. The camera takes its power over the data link, PoE for GigE and bus power for USB3, so a software-triggered station needs one cable and no I/O wiring at all.

Latency is the trade. The command crosses the network, gets parsed, then queues behind whatever the camera is already doing; plan on milliseconds, not microseconds. That is correct when the host owns the timing — a robot reporting 'at position', an operator click, a test-sequence step — and wrong when a part is crossing a beam. The two classic failure modes are a one-shot capture that misses the frame because nothing was waiting, and a command fired while the camera was still busy; see why one-shot software capture misses frames and diagnosing the trigger-ready timeout.

Smart cameras take the same command over industrial protocols instead of a GenICam call — a TCP message, a Modbus register write, a Profinet call — so a PLC can request an inspection with no PC in the loop:

Pulse-width and gated trigger

Gated triggering ignores edges: the sensor exposes for exactly as long as the trigger line is high, so the width of your electrical pulse sets each frame's exposure individually. Use it when the exposure must change from part to part and the PLC can shape the pulse — thick versus clear glass, bright versus black parts on one line.

Line scan and 3D cameras use the same signal differently: the gate defines how many lines make up one image block. The numbers come from the belt, not the camera. At 200 mm/s and a sampling of 0.1 mm per line, the sensor clocks 200 ÷ 0.1 = 2000 lines per second, and a 120 mm part spans 120 ÷ 0.1 = 1200 lines — hold the gate high for that window and one block equals one part.

Burst and sequence trigger

Burst mode answers one trigger event with a preset number of frames captured back to back. It exists for events too fast to re-trigger mechanically: a hammer strike, a drop test, an injection-moulding shot. Do the maths on the link before the test day: frames pile into the camera faster than the cable drains them, so the onboard buffer must hold the whole burst — burst capture beyond link bandwidth covers the sizing.

Sequence mode gives every frame its own trigger and its own parameter set. You preload the sets — exposure, gain, region of interest — and the camera loads the next set on each incoming trigger, so frame 1 is a short exposure under a ring light and frame 2 a long exposure under a coaxial light, without the host touching the camera mid-cycle. Vendors expose this as sequencer sets: each set carries the settings for a group of camera features, selected in order. Pair it with illumination switching and one camera does the work of several — sequencing light colours shows the lighting side of the same idea, and lighting operating modes compared covers strobed versus continuous drive.

Whenever the exposure is short, put the flash on a channel of a light controller and time it inside the exposure window, so the light — not the shutter — freezes the motion:

Pre-trigger ring buffer

The camera records continuously into onboard memory and keeps its most recent frames — the last thousand, on cameras built for this. When the trigger arrives, it hands over those images plus everything after, so you see the seconds before the event, not only after it. That is the mode for failure forensics: the crash nobody can predict, the intermittent jam, the power dip. It costs either several gigabytes of camera memory or a PC-side ring buffer fed at full frame rate. Nothing else looks backwards in time; every other mode starts at the trigger.

PTP 1588 scheduled trigger

The Precision Time Protocol synchronises the clocks of Ethernet devices to a master, and GigE Vision cameras hold microsecond-class alignment to it. You then schedule a capture at an absolute time — 14:32:07.500, say — and every camera on the network exposes at that instant, simultaneously rather than cascaded.

The constraint is equally clear: PTP cannot fire spontaneously. The capture moment must be a future time you already know, which makes scheduled triggering the tool for multi-camera stereo, multi-view gauging and coordinated inspection — not a replacement for the wire from your photoeye. For two-camera setups without a shared network clock, wiring one common pulse is the other route, with its own arming pitfalls covered in the USB stereo trigger pair guide.

Worked example: hardware trigger versus free run at 0.2 m/s

Inputs first, each with its origin:

• Belt speed 0.2 m/s (200 mm/s), a small-parts conveyor.
• A 6 MP camera on a 1/1.8-inch sensor. The 1/1.8-inch format is about 7.2 mm wide, and a common 6 MP arrangement is 3072 pixels across, so pixel pitch is 7.2 ÷ 3072 = 2.34 µm. Real sensors of this class sit at 2.3–2.4 µm; use 2.3 µm.
• Free run at 30 fps: frame period 1 ÷ 30 = 33.3 ms.
• Hardware trigger latency 20 µs, the middle of the few-to-few-tens range.
• Exposure 1 ms, with a 10 µs strobe flash inside it.
• Budget: at most one pixel of motion blur, so 2.3 µm.

The rules in words: position jitter equals part speed times trigger-to-exposure latency; motion blur equals part speed times exposure time, or flash time when a strobe freezes the scene; the worst-case wait for a fresh free-run frame is about two frame periods.

Free run at 30 fps: worst case 2 × 33.3 ms = 66.7 ms for a full fresh frame. The part travels 200 mm/s × 0.0667 s = 13.3 mm in that window, so frame-to-frame position varies by up to 13 mm. For a presence check on a 100 mm part that is harmless; for a dimension taken against a fixed reference it is unusable.

Hardware trigger: jitter = 200 mm/s × 0.00002 s = 0.004 mm = 4 µm, about 1.7 pixels. The part lands within two pixels of the same place on every shot.

Exposure without strobing: a 1 ms exposure smears the image by 200 mm/s × 0.001 s = 0.2 mm, which is 0.2 mm ÷ 2.3 µm = 87 pixels of blur. Holding blur under one pixel with shutter alone needs 2.3 µm ÷ 200 mm/s = 11.5 µs of exposure, which starves most scenes at sane gain. With the 10 µs strobe, blur = 200 mm/s × 0.00001 s = 2 µm = 0.9 pixel, inside budget.

Decision for this belt: hardware trigger plus a strobed light — 4 µm of jitter and under one pixel of blur. Free run stays for the operator screen only. Generalise the threshold: the moment part speed × (latency + effective exposure) grows past a tenth of your position tolerance, free run is out.

When the usual answer is wrong

• Parts overlap or arrive continuously: a photoeye fires ambiguously, so free run with host-side selection beats triggering.
• The PLC pulse itself jitters by milliseconds: a hardware trigger faithfully reproduces bad timing. Move the decision into the camera — sequencer sets or a scheduled PTP capture — or trigger from a part-present sensor at the imaging point instead.
• The interesting moment comes before any sensor you could mount: only the ring-buffer pre-trigger shows the past.
• Exposure must change part to part and the PLC cannot shape pulses: pulse-width gating needs a controllable pulse source, and without one, sequence mode with preloaded exposures is the answer.
• The burst exceeds the link: if the camera buffer cannot hold N frames at that resolution, cut resolution or burst length before blaming the network.

Checks before you commit

• Write the timing budget: part speed × (trigger latency + effective exposure), in µm, against pixel pitch and your tolerance. Ten minutes of arithmetic saves commissioning days.
• Match the input stage: opto-isolated PLC outputs and TTL lines are not interchangeable, so know which your camera accepts before the cable is cut.
• Count the I/O you need: trigger in, strobe out, an encoder for line scan, and one spare line for the next add-on.
• Multi-camera station: decide shared wire versus PTP early, because it changes the network design, not just one setting.
• Keep a free-run mode in the application for focus and setup, even on a fully triggered station.

Ready to pick parts? The camera finder filters by interface and mount, the configurator walks camera, lens, light and controller as one system, and the light controller finder narrows the strobe side. More acquisition-timing guides sit under the systems topic. Bring the timing budget with you — it settles most selection questions on the spot — or send it through the contact page and we will match the mode to your line.