Hardware trigger source not detected: check GenICam line settings

You set the trigger property on your camera, pointed it at Line2, and the images keep arriving far faster than your 1 Hz pulse. The camera is not broken and the pulse is probably fine: a trigger source on its own does not arm hardware triggering. Triggering is a chain of GenICam features — line selector, line mode, trigger selector, source, activation, mode, acquisition start — and every link has to be in place before a pulse does anything. Worse, the acquisition library in your pipeline can rewrite that chain at startup and quietly leave the camera in a state you did not ask for. This article walks the whole chain, shows how to verify it after acquisition starts, and covers the ExposureActive override that makes a triggered camera look like it is free-running.

The symptom and what it actually means

The classic picture: a command-line pipeline sets trigger=Line2, the stream runs, and frames arrive at the camera's internal frame rate instead of the pulse rate. Two very different faults produce this:

1. The trigger chain is incomplete, so the camera never left continuous acquisition. The trigger property was accepted but the surrounding features were never set.
2. The chain was set, then overwritten. Your application framework initialized the camera after you configured it and wrote its own defaults — including a different TriggerSelector — leaving the camera armed in a way your pulse does not satisfy.

Neither is a wiring problem yet. Diagnose the configuration first, with the stream running, and only then reach for the multimeter. If you do get to wiring, the camera GPIO wiring guide covers pin damage and power faults, and the camera trigger common reference checklist covers the ground-reference mistakes that make a good config look dead.

The GenICam chain, feature by feature

A hardware trigger needs every one of these features set, in roughly this order:

What each one does:

• LineSelector picks which physical I/O line the following line features apply to. Setting LineMode without selecting the right line first configures a different pin.
• LineMode = Input turns that pin into an input. Some lines power up as outputs or unused; a trigger on an output line is ignored.
• TriggerSelector = FrameStart says the trigger starts a frame. This is the feature most often silently changed, as covered below.
• TriggerSource = Line2 names where the pulse comes from. This is the one property most wrappers expose — and the one people set alone.
• TriggerActivation picks rising or falling edge. Match it to your pulse source; a 1 Hz square wave triggers on one edge only, so polarity errors halve or zero the rate rather than free-running it.
• TriggerMode = On actually arms the mechanism. Off means continuous acquisition, whatever the source says.
• AcquisitionStart begins the armed state. Some libraries issue it for you; some require an explicit call.

Likely causes, in order of probability

Work down this list; each has a test you can run in a minute.

1. The library overwrote your settings at startup

Acquisition libraries commonly reconfigure the camera when the stream starts: packet size, auto exposure, and trigger features. You set the chain with a tool, launched the pipeline, and the pipeline's initialization code rewrote it. The tell-tale variant seen in the field: you set TriggerSelector = FrameStart, and after the library initializes, the camera reports TriggerSelector = ExposureActive with the same trigger source. ExposureActive expects a trigger per exposure, so a frame-rate-paced pulse train or an unsatisfied exposure trigger makes the camera behave unpredictably — including appearing to free-run.

Test: read the features back after the stream starts, not before. With a GigE Vision camera you can attach a generic GenICam feature browser to the device while the pipeline runs and print TriggerSelector, TriggerSource, LineMode, TriggerMode and TriggerActivation. If they differ from what you set, the library is the culprit.

Fix: configure through the library, not around it. Set the full chain using the library's own feature-access API (most expose raw GenICam features), or find the property that stops the library from touching trigger settings. If the library offers no such hook, set the features in your code immediately after the camera is opened and before acquisition starts, and verify by readback.

The hardware triggered image acquisition in Python walkthrough shows where in code to place these calls so they are not racing the library's own initialization.

2. The line was never set to Input

TriggerSource names a line; it does not configure it. If Line2 is still in its power-up mode, the camera never looks at the pin.

Test: select the line and read LineMode. Fix: set LineSelector = Line2, then LineMode = Input, before arming the trigger.

3. TriggerSelector points at the wrong event

FrameStart is what you want for one pulse per image. Other selectors exist on many cameras — ExposureActive, FrameBurstStart — and a wrapper may default to one of them.

Test: read TriggerSelector after startup. Fix: set it back to FrameStart through the library, and check whether the library rewrites it on the next start.

4. TriggerMode never went On, or AcquisitionStart never ran

If the wrapper's trigger property silently failed — wrong line name, feature not present on this camera — the camera stays in continuous mode.

Test: read TriggerMode during streaming; a value of Off with images flowing means continuous acquisition. Fix: set TriggerMode explicitly and start acquisition through the library. If the camera then waits and produces nothing, you have won half the battle: the camera trigger ready timeout guide covers the software side of a camera that is armed but never fires.

5. The pulse, the wiring or the edge is wrong

Only now suspect the physical layer. Check the edge polarity against your pulse source, the pin assignment on the camera's I/O connector, and the shared ground between pulse source and camera.

Test: if the camera has a line-status readback, watch it while pulsing — you should see the input toggle. Fix: correct the edge, the pin or the ground. For rate limits once triggering works, see camera hardware trigger frame rate with external pulses.

Step-by-step diagnosis

1. Start your pipeline and let the stream run.
2. Attach a generic GenICam feature browser to the camera and read, in this order: TriggerMode, TriggerSelector, TriggerSource, LineSelector, LineMode, TriggerActivation.
3. Compare each value against the chain above. Note every mismatch.
4. If TriggerSelector reads ExposureActive or anything other than FrameStart, your library rewrote it — fix in code, not in the tool.
5. If LineMode is not Input on the selected line, set it and confirm TriggerSource names the same line.
6. If TriggerMode is Off, the camera is in continuous acquisition; arm it through the library.
7. Once all six values are right, pulse the line and count frames. One pulse, one frame: done.
8. If values are right but no frames arrive, move to wiring: line status readback, edge polarity, ground reference.

Hardware that keeps the chain honest

The camera side is only half the system. A few practical notes on the parts around it:

• Camera choice. Any GenICam-compliant industrial camera exposes the full feature chain, but small board-level and consumer-derived cameras sometimes implement only a subset. A machine-vision area scan camera with a proper I/O connector, like the MV-CU020-90GC or the MV-CS200-10UM, gives you LineSelector and LineMode as documented features. Browse the area scan cameras category or the camera finder at /shop/cameras/ and filter on interface to match your frame grabber or NIC.

• Cabling. The trigger pulse has to reach the right pin. An I/O cable with open leads, such as the LS-CBL-0300, lets you wire exactly the input and ground your pulse source needs, and survives drag-chain service on a moving line. See the cables category for camera data, power and I/O options.

• Pulse source. A strobing light controller with a trigger output, or a PLC output, gives a clean edge at a defined voltage. The LS-CTL-0322 is one example of a multi-channel digital controller that can drive lights in step with the line; the full range is under light controllers.

If your pulse comes from a PLC hardware-interrupt arrangement and you want the PLC side of the story too, the S7-1200 hardware interrupt OB reference covers identifying the interrupt source there.

Software triggers from a command-line pipeline

A related question worth settling: with trigger=Software, can a command-line launcher fire the trigger? No. gst-launch and similar tools build the pipeline and walk away; there is no hook to call the TriggerSoftware command at chosen moments. The camera will either wait forever or fall back to continuous mode. Move the pipeline into a script — Python with GStreamer, or the vendor's SDK — where you hold a camera object and can execute the software trigger per frame. Once you are in code, the same GenICam chain applies: TriggerSelector FrameStart, TriggerSource Software, TriggerMode On, then the command per image.

Prevention: make the readback part of start-up

Once the fault is fixed, keep it fixed:

• Set the whole chain in one place, through the library, at startup — never with an external tool that the library will override.
• After arming, read back TriggerMode, TriggerSelector and LineMode and fail loudly on mismatch, before any product runs down the line.
• Log the readback with every run; a one-line log entry turns the next regression into a five-minute fix.
• If you run several cameras, the dual camera trigger troubleshooting guide extends the same checks to multi-camera timing.

Checklist before you blame the camera

• Stream running, readback taken after startup — not before.
• TriggerSelector = FrameStart (not ExposureActive).
• TriggerSource names the line you actually wired.
• LineSelector on that line, LineMode = Input.
• TriggerActivation matches your pulse edge.
• TriggerMode = On and acquisition started through the library.
• Pulse source and camera share a ground; line-status readback toggles when pulsed.
• One pulse produces exactly one frame at the receiving end.

If every box is ticked and the camera still free-runs, collect the six readback values and the library version and bring them to us through the contact page — with those numbers, the fault is usually identifiable in one pass. For a complete light-camera-controller bundle, the system configurator walks the same chain in hardware form.