Frame grabber camera trigger pulse train without a function generator

You have two externally triggered cameras and a bench function generator ticking away at both of them, and you would like the bench back. The obvious move is to ask each frame grabber to generate the pulse train internally and route it to the camera's CC1 trigger line — and on most mid-range boards that call fails with an invalid-output-signal error, because the path from the onboard generator to the camera control lines does not exist. This explainer gives you the routing rule that decides the question in five minutes, the arithmetic that sizes a trigger train, and three committed ways to retire the function generator: free-running the cameras, clocking them from the machine, or handing the cadence to a multi-channel light controller. A 10 kHz worked example carries the numbers.

Why the grabber cannot generate the train

Camera Link carries four camera control lines, CC1 to CC4, as LVDS pairs driven by the frame grabber; the camera only listens. Next to them the board exposes external trigger inputs on its I/O connector, and the driver maps those inputs onto the control lines: on one widely used board family, external trigger 0 routes to CC1, external trigger 1 to CC2, and so on, set in the vendor's configuration utility. That is routing, not generation — an incoming edge goes back out on the mapped line, and nothing on the board invents edges.

The onboard pulse generator is a separate block. You create it with the SDK's pulse call, asking for a continuous train (a PULSE_MODE_TRAIN-style constant) and pointing it at a destination. On mid-range boards the legal destinations are internal timing signals only; point it at a control line and the call returns an invalid-output-signal error, because there is no path. There is no direct toggle either: no SDK function drives a control line from software, so a CC line moves only through input routing or through the action assigned to it in the camera file.

One document decides selection: the grabber's trigger routing table. It lists every path a signal can take, and a path that is not listed does not exist — read it instead of assuming either answer. Larger boards in the same family do document onboard pulse generation that reaches the trigger lines, so both outcomes are real; the table tells you which one you bought.

Three ways to retire the function generator

The requirement is specific: a steady, adjustable clock up to 10 kHz per camera, always on, with no synchronisation between the two. Work down this list and stop at the first line your cameras satisfy.

1. Free-run the cameras. If each camera only needs its own steady clock, the clock never had to be external. Set the trigger source to Off, command the rate with AcquisitionFrameRate, and the function generator leaves the bench. The ceiling is the camera, not the wiring: the maximum rate is 1 divided by exposure plus readout time, and 10 kHz leaves the whole frame 100 µs — line-scan territory. The free-running factory state you normally switch off, as hardware trigger configuration per camera explains, is exactly what you want here.

2. Clock from the machine. A PLC high-speed pulse output is the machine-grade replacement for the bench box: 24 V transistor outputs commonly source 100 kHz trains. Into a Camera Link grabber the pulse must arrive as 5 V TTL at the trigger input, which means a level shifter wherever the PLC only gives 24 V. Into a modern camera's opto-isolated input, the same 24 V pulse wires straight in. This is the first choice on an automated line, because the cadence then lives with the sequence logic that already owns the machine.

3. Hand the cadence to the light controller. When the lights strobe in step with the triggers, the box driving the LEDs can own the timing: its channels give you one or two independent clocks, the rates travel over the serial link, and matching levels connect straight to the camera inputs. The section below commits to the hardware.

One decision remains: shared or independent. A single pulse output fanned out to both trigger inputs gives one shared clock — the inputs are high-impedance loads of a few milliamps each, so one output carries both easily. Two independent clocks, the case here, need two channels: a two-channel controller, two PLC outputs, or two single-channel sources. If synchronisation becomes a requirement later, the shared clock is the wiring you keep; hardware sync for two cameras shows it driven properly.

Sizing the pulse train

Three numbers describe a trigger train, and each has a hard limit behind it:

The period is the reciprocal of the rate. Put the pulse width near a tenth of the period: wide enough to exceed the input's minimum detectable width — about 1 µs on TTL inputs, up to a few tens of microseconds on slower opto-isolated inputs — and narrow enough to free the line before the next edge. The rate can never beat f_max, because exposure plus readout has to fit inside one period. Cameras trigger on an edge, so set TriggerActivation to RisingEdge with an active-high source instead of trying to exploit the pulse width; how a pulse rate maps to delivered frames is covered in camera hardware trigger frame rate with external pulses.

Worked example: a 10 kHz line trigger

A line-scan camera watches a web moving at 1.0 m/s, and you want 100 µm of spatial sampling along the direction of motion. The line rate follows from speed over sample spacing:

1.0 m/s ÷ 100 µm = 1.0 ÷ 0.0001 = 10 000 lines per second, which is 10 kHz. The rest falls out of the period: T = 1 / 10 000 s = 100 µs. A 10 % duty cycle puts the pulse width at 10 µs, comfortably above any input's minimum. Set the exposure to 80 µs and the camera still owns 20 µs for readout and reset inside each period, so f_max = 1 / (80 µs + 20 µs) = 10 kHz exactly. Motion blur during exposure is 1.0 m/s × 80 µs = 80 µm, or 0.8 of the 100 µm sample spacing — acceptable for gauging, tight for print inspection.

One number kills the area-camera version of this example: 10 kHz is 10 000 frames per second. If your cameras are area scan and the rate you actually need is 60 fps, the period is 16.7 ms and a 1 ms pulse at 6 % duty does the job, with the same arithmetic and much cheaper hardware.

Wiring the source into the system

Two architectures, decided by the camera interface.

Camera Link. The source feeds the grabber's external trigger input at 5 V TTL, the driver maps that input to CC1, and the camera file assigns CC1 its action (frame start, exposure start) — to the camera, the control line is just a command input. A current Camera Link board such as the MV-GC1102IOL terminates the camera control lines on its cable, and the route from its trigger input is set in software, not in solder; today's frame grabbers keep that mapping in the configuration utility rather than in jumper blocks. On the host side, a frame grabber I/O cable with a DB9F at the card and 7 m of open leads at the source keeps the connection serviceable.

GigE, USB3 and CoaXPress cameras. Here the grabber is out of the trigger path entirely: the pulse wires to the camera's own input on its GPIO connector, and the data link just carries frames. Two PoE network cards power the pair and leave triggering to the camera inputs:

Configuration is pure GenICam: TriggerSelector to FrameStart (LineStart on a line-scan camera), TriggerSource to the input line, TriggerActivation to RisingEdge, ExposureMode to Timed. Whether you need the GPIO cable at all is its own question — do I need a camera GPIO cable for image acquisition answers it. When a wired camera stays silent, GenICam line settings for a missing trigger source is the checklist, and why a GigE camera ignores its external trigger covers the acquisition-mode trap above it. For the source side, camera trigger cable selection for a signal generator settles connector and grounding choices, and the I/O side of cables carries the rest.

One box for lights and cadence

When the lights strobe in step with the triggers, stop generating timing separately. A digital light controller with per-channel strobe becomes the cadence master: rates and pulse widths travel over the serial link and store with the recipe, so nobody bumps a knob on the way past. Two digital controllers cover the two common shapes:

All 2 share: Output voltage 24 V. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The 4-channel, 200 W control box runs four independently switched 24 V channels — two camera-and-light pairs plus spares, or one shared clock on a single channel. The 2-channel, 240 W controller gives each camera its own higher-power channel, which is the exact shape of the two-independent-clocks case. Both take their settings over RS-232, so the cadence is a recipe value rather than a dial position; a constant-voltage 24 V channel meets a camera opto input rated 3.3 to 24 V with no converter in between, and only 5 V TTL destinations need a 5 V source. The range lives in light controllers and the light controller finder.

Checks before you cut cable

• Rate ceiling: divide 1 by exposure plus readout and compare with your clock. At 10 kHz the budget is 100 µs per frame.
• Input voltage window: a 3.3 to 24 V opto input accepts the 24 V PLC or controller channel; a 5 V TTL input accepts 5 V only. One label on the cabinet drawing prevents the most common dead input.
• Minimum pulse width: keep the width above the input's minimum — about 1 µs on TTL, up to tens of microseconds on slow opto inputs — and near 10 % duty.
• Polarity and edge: active-high source, TriggerActivation RisingEdge, exposure mode Timed.
• Camera Link route: the input-to-CC mapping has to exist in the grabber's configuration, and the camera file must assign CC1 an action; Camera Link frame grabber compatibility for line scan lists what else that interface demands.
• Shielding: a shielded I/O cable with the shield landed at the grabber end; the DB9-to-open cable above is the pattern.
• Two boards in one PC: adding the second grabber is when interrupt and memory conflicts appear — frame grabber resource conflicts walks through the resolution.

When the usual answer is wrong

Free-running is wrong the moment the pair must fire together: two internal clocks drift apart, and software cannot recover phase after the fact. Go back to one shared clock fanned out to both inputs, as the shared-clock wiring earlier in this guide shows.

The pulse train itself is wrong when motion is the master. On a web or conveyor the encoder is the timing source and the camera follows it line by line — encoder-triggered line scan capture covers that wiring, while a fixed 10 kHz clock smears the image every time the line speed changes.

Keep one exception open: a high-end grabber whose routing table lists the onboard generator as a legal source for the control lines really does replace the function generator with a register write. That is the first thing to check on any new board and the last thing to assume.

And if the bench box is ticking analog cameras rather than Camera Link ones, the trigger question folds into a bigger migration: replacing an obsolete analog NTSC frame grabber with USB3 Vision is that path.

The decision, case by case: no synchronisation needed — free-run both cameras and shelve the generator. Externally triggered Camera Link pair — one 5 V source per grabber trigger input, routed to CC1. Networked cameras — pulse the GPIO inputs from the PLC or from controller channels. Two independent clocks — two channels, full stop. To match cards, cables and controller in one pass, configure the controller step of the system builder; the systems topic page gathers the related guides, and the contact page reaches us with the two rates and the camera input types, which is all we need to lay out the wiring.