Genlock and multi camera synchronization for machine vision

Two cameras watching the same moving part are only as good as their shared clock. If the frames do not start together, the part moves between the two exposures and the measurements disagree. The word genlock comes from analog broadcast video, where slave cameras phase-locked to a master's sync signal. Digital machine-vision cameras do the same job with trigger lines, and over GigE with the IEEE 1588 time protocol. Below are the master-slave wiring pattern, the drift and skew numbers that decide whether you need hardware triggering, and the tests that prove a rig is synchronized before it goes over the line.

What genlock meant, and what replaced it

On an analog video rig, genlocking meant this: one device, the master, generated a composite sync signal — the timing pulses with or without the video on them — and every slave camera phase-locked to it. All cameras then ran at exactly the same frame and line rate. Two limits came with it. Genlock locked the rate and never the latency: it said nothing about how long each camera took to deliver a picture. And it belonged to broadcast video, tied to composite signals that no machine-vision sensor accepts.

Digital cameras kept the master-slave idea and changed the carrier. Two patterns exist today. In a reference or genlock mode, the sensor free-runs with its timing phase-locked to an incoming reference, so frames keep flowing with no command per frame. Far more common in industrial cameras is edge-triggered mode: each rising edge on the trigger input starts exactly one frame. The master publishes a pulse train, every slave fires on it, and because the pulses can just as well come from a PLC or an encoder, capture also ties to the machine event.

The wiring: one master, every slave

The master runs a continuous acquisition loop. Its frame-start output — many cameras can emit an exposure-active signal instead — is wired to the trigger input of every slave. Each slave is set to trigger mode, source pointed at the wired input line, rising edge, exposure timed from the trigger. Every sensor then starts each frame within the wiring skew, which stays in the sub-microsecond class on short cable runs.

Choose the output signal deliberately. Frame-start output: each slave keeps its own exposure length, so a close-up camera can expose longer than a wide one. Exposure-active output: every slave captures inside the master's exposure window, so all sensors see the same light pulse — the right choice when a strobe fires. The same shared-trigger pattern scales past two cameras; the guide on multi-camera exposure synchronization with a shared trigger shows how exposure timing stays consistent across the set.

Master and slave do not need to share a bus. The two cameras below carry the same 6 MP, 1/1.8" mono rolling-shutter sensor; one delivers frames over GigE, the other over USB3, so one rig can mix interfaces without changing the sensor family.

What synchronization fixes, and what it leaves alone

A shared trigger fixes the frame period and the phase: frame n starts in every camera within a microsecond or so. It does not equalize latency. After the common start, each camera exposes for its own set time, reads the sensor out at its own pace, and the host receives the frame when its interface delivers it.

Run the arithmetic for a two-camera pair. Camera A exposes 2 ms and reads out in 10 ms, so its frame is ready about 12 ms after the shared start. Camera B exposes 2 ms and reads out in 8 ms, ready about 10 ms after the same start. Both saw the part at the same instant; the frames simply became available 2 ms apart. With different frame rates, arrival order even swaps from frame to frame. The fix costs nothing: merge streams by timestamp or frame counter, never by arrival order. Exposure and frame rate interact more than the numbers suggest — the video exposure versus frame rate guide shows why a still can come out brighter than the video feed — and readout time, not just exposure, sets the frame period, as the binning versus readout comparison lays out.

The numbers: drift, skew and the shift they cause

T_frame is the frame period, Δf_rel the relative clock tolerance between two free-running cameras in seconds per second, v the part speed, Δt the skew between captures.

Hardware triggering earns its cable on moving parts. Two cameras left free-running, both set to 30 fps, share nothing after power-up. Crystal oscillators typically hold ±20 to ±50 ppm. Worst case, one camera sits at +50 ppm and the other at −50 ppm: a relative offset of 100 ppm = 1×10⁻⁴ s per second. At 30 fps the frame period is 1/30 s = 33.3 ms, so the pair drifts one full frame apart in 0.0333 s ÷ 1×10⁻⁴ s/s = 333 s, about 5.5 minutes. With ±20 ppm parts the same arithmetic gives 0.0333 ÷ 4×10⁻⁵ = 833 s, about 14 minutes. Free-running synchronization lasts minutes, not a shift.

Now the shift on a part moving at 300 mm/s. Free-running cameras worst case capture half a frame apart, 16.7 ms: Δx = 0.3 m/s × 16.7×10⁻³ s = 5.0 mm. Software triggering, where a host command reaches each camera with scheduling skew around 5 ms, gives 0.3 m/s × 5×10⁻³ s = 1.5 mm. A hardware-triggered pair holds skew near the wiring itself: a published measurement of a synchronized high-speed rig found worst-case skew of about 350 ns, which at 300 mm/s is 0.3 × 350×10⁻⁹ = 0.105 µm, or 0.005 pixels at a 20 µm object-space pixel; the same study reports about 0.03 pixels on its own rig. Cable delay barely moves the number — signal needs roughly 5 ns per metre of trigger cable, so a 10 m difference between two runs adds about 50 ns.

Software trigger, PTP or hardware trigger

Software triggering is the free choice when nothing moves between frames: the skew exists but nothing turns it into error. PTP is the choice for GigE fleets that cannot share a wire: cameras that implement IEEE 1588 align their clocks over the network and schedule frame starts on the common timebase, microsecond class on a clean local link. The PTP GigE camera synchronization guide walks through master, slave and the timestamp check that proves the offset before you trust it. Hardware triggering is the choice whenever the part moves or two cameras must measure one instant: 350 ns against 5 mm is the whole argument.

For a fast high-resolution slave you want global shutter and a short exposure; the camera below pairs a 12 MP sensor with a global shutter on USB3, as the high-speed version of its series.

Rolling shutter, global shutter and same-instant capture

The trigger puts the frame start at the same instant on every sensor; what the sensor does next differs. A rolling shutter exposes the rows one after another, so the bottom of the frame sees the world later than the top, by a large share of the frame period on a fast scene. A global shutter latches every row at the same instant, so one frame is one moment in time.

That decides which cameras can share geometry across a moving scene. The 2.5 MP GigE camera below has a global shutter, so two of them on one pulse train capture the same instant in both frames.

Rolling-shutter cameras still synchronize perfectly well as starts. Both cameras in the table below use the same 12 MP, 1/1.7" rolling-shutter sensor, one at 9 fps over GigE and one at 30 fps over USB3, and both are right for still scenes and trigger-to-start timing. For moving geometry measured across cameras, spec global shutter instead.

All 2 share: Sensor size 1/1.7". Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Setting the rig up in the order that works

1. Assign roles. The camera wired to the machine event, or the one with the most stable timing, is the master; every other camera is a slave.
2. Set the slaves first: trigger mode on, source set to the wired input line, rising edge, exposure timed from the trigger, frame period capped at the master's. A slave left in single-shot acquisition fires once and then ignores the pulse train; the guide on hardware triggers that stop after one frame is the fix for that exact symptom.
3. Set the master last: continuous acquisition, frame-start output enabled, exposure chosen so the strobe lands inside the window.
4. Wire one pulse to every slave. Fan out from the master's output rather than daisy-chaining camera to camera: each hop adds delay, and one loose connector drops everything downstream of it.
5. Prove it. Fire a short LED flash in view of all cameras and confirm every frame catches it; then run the part at production speed and compare measured positions across cameras. On the host side, the Python hardware-trigger grab loop shows the slave-side pattern of waiting one frame per pulse, and reading the camera GPIO pins while capturing lets you timestamp the master's own pulse.

Checks before you build

• Drive budget. A camera GPIO output drives one or two opto-isolated inputs cleanly; past that the edge slows and slaves miss frames. A trigger distribution board solves it — the GPIO trigger routing guide shows one input fanned out to six cameras with the skew held flat.
• Isolation and ground. Opto-isolated inputs forgive long runs and separate supplies. Non-isolated TTL inputs need a common ground between master and slaves; the camera GPIO wiring guide covers the damage patterns to design out before they cost a camera.
• Cable budget. Count about 5 ns per metre of trigger cable; a 10 m difference between two slave runs adds roughly 50 ns, well inside a 1 µs budget.
• Shutter. Global shutter on every camera that must share the same instant of a moving scene.
• Frame period. Identical on every camera in the pulse train, or an integer divisor of it, or the merge logic meets frames out of order.
• Mounting. A synced rig is a measuring instrument: fix master and slaves to one rigid base plate or camera stand so the calibrated geometry survives vibration; the stands category covers slide tables and brackets built for exactly this.

When the usual answer is wrong

• Mixed frame rates. Triggering slaves faster than they read out drops frames. Set every camera to the same period, or trigger slaves at a divisor of the master rate and merge on frame numbers.
• Exposure longer than the interval. A slave with 40 ms exposure cannot follow a 33.3 ms pulse train; shorten the exposure or slow the trigger. When slaves run different exposures on purpose for HDR, keep the pulse common and the settings aligned as the multi-exposure consistency guide describes.
• No wiring path. A camera across the cell or on a moving carriage cannot always receive a cable; that is where PTP over the existing GigE link wins, provided both cameras implement it.
• No trigger input. A camera without trigger I/O cannot join the pulse train; swap it for one that has the input, or run that pair on PTP or software timing and accept the slower scene.

The decision

• Scene still between frames: software trigger, spend nothing.
• Scene moves, or two cameras measure the same instant: one master camera's frame-start output into every slave's trigger input, merged by timestamp — sub-microsecond skew for the price of a cable per camera.
• GigE fleet, no wiring path, PTP on both cameras: schedule on the common clock and prove the offset with timestamps.

Shortlist on the area scan cameras category page, filter by interface and shutter in the camera finder, and step through the camera configurator to match camera, lens and trigger accessories before you order cable. If a rig needs a second pair of eyes, the contact page reaches the applications team. More timing and camera-side guides sit on the cameras topic page.