Camera trigger mode source readback mismatches: find the real value

You write TriggerMode On and TriggerSource Line0, read the pair back, and one value reports the old setting. The station free-runs or fires from Software while your interface shows hardware trigger. Three causes cover nearly every case: a TriggerSelector context switch, a stale host-side cache, or a second writer. This procedure isolates the cause in one session — one raw register read, then a 40-check transition matrix — and leaves you a write sequence and a checklist that keep the tuple stable across restarts.

Check the three causes in this order

GenICam SFNC names these features, and the order below runs from the cheapest test to the deepest. One raw device read separates all three causes before you touch transport hardware.

A configuration GUI that looks passive applies its stored preset the moment it connects. Close configuration panels, startup scripts and demo clients, and give one application sole responsibility for settings during the whole test.

What the GenICam standard requires

The SFNC trigger block has four features plus a command: TriggerSelector picks the configuration — FrameStart, FrameBurstStart and AcquisitionStart are the standard entries — and under it TriggerMode (On or Off), TriggerSource, TriggerActivation (RisingEdge or FallingEdge), and the TriggerSoftware command that fires a software trigger on demand.

Three SFNC rules decide most mismatches. First, the camera stores a separate mode and source pair per selector entry, so a selector change swaps the whole pair. Second, free running is TriggerMode Off — the standard defines no freerun source value. A source that stays readable while the mode is Off is the stored source for the next arm, not an active one. Third, valid source values are the entries the camera's own enumeration lists; write nothing else. When Line0 or Software is missing from that list, the fix is line discovery, not cache work — start with trigger-source discovery and line settings.

Every feature also publishes its access mode. A node that reads RW while idle can drop to RO while acquiring, so a rejected write during acquisition is correct camera behavior rather than a cache fault. The node access-state checks cover that path.

Get one raw device read

Your normal getter goes through GenApi, which caches register values as the camera's XML describes. Your own write refreshes the cache; a change made by any other client does not, until the declared validity time expires. The getter reports what your process last saw. The raw read reports what the camera holds. On a GigE camera, one GVCP READREG command per feature is a fresh read by construction, and the whole tuple is three commands. On USB3, use your library's direct-register function.

Read the tuple — selector, mode, source — in one pass and log both paths with 1 ms timestamps:

14:22:03.512  acq=stopped  selector=FrameStart  write=TriggerSource=Line0  raw=Line0  cache=Software

A separate configuration utility is a fair cross-check once you close your application and run it alone; its preset-on-connect makes it a writer like any other. A reconnect of your own handle is a weak test — some libraries reread every cached node at open, others serve XML defaults until first access — so use the raw read, whose result does not rest on library behavior.

The write sequence that keeps the tuple intact

Configure with acquisition stopped, in this order:

1. Stop acquisition and wait for the stop to finish; on a grabber chain, stop the host side too.
2. Write TriggerSelector where the camera implements it, then read it back.
3. Read the baseline tuple twice — normal getter and raw read. Both must agree before you start.
4. Write TriggerMode Off, the SFNC editing state: the stored source stays but goes inert. Reread all three features.
5. Write TriggerSource to a value the enumeration lists, check the setter status, reread the tuple.
6. Write TriggerMode On, reread the tuple.
7. Restart acquisition, reread after the first frame, then run the functional test in the worked example.

Stop at the first value that comes back wrong and capture that log line: the tuple taken after the failing write names the defective step. Corrective writes destroy the evidence.

Startup routines need the same discipline. A sequence that writes settings with no final readback passes commissioning and fails at the next power cycle; the trigger-overlap startup verification guide shows that failure with the same tuple log.

The 40-check transition matrix

Two target transitions — Off to On with source Line0, and On to Off — under two read policies — your normal cached getters and forced raw reads — ten repetitions each:

The decision rule: zero disagreements in 40 checks clears the configuration path. Two or more of 40 — a 5% rate — confined to the cached policy while raw reads stay clean convicts the host cache: your process is reading back its own last write. Fix it in the library's cache policy by forcing a device read for the trigger block after every write.

Keep write order and acquisition state identical between the two policies, and keep every write on one thread. If the matrix disagrees only with debug logging on, you have a race between a background worker and the configuration thread — serialize them, as described for safe parameter access in a capture loop. If the camera has no TriggerSelector, the tuple is two features and the same matrix logs 80 values.

Worked example: 20 parts per second on Line0

A fill-level check photographs bottles at 20 parts per second; a PLC transistor output pulses Line0 on the rising edge with 2 ms exposure.

The camera must finish readout inside that 50 ms budget, and pulses closer together than its frame period are dropped — the guide on frame rate under external pulses covers that ceiling. Test the pipeline first with no wiring at all: 10 TriggerSoftware commands must return exactly 10 frames. Then connect the line: 20 pulses, 20 frames, no more. When the source is a mechanical relay rather than a transistor output, set LineDebouncerTime to 1000 µs as the starting value — the SFNC defines the feature in microseconds — and shorten it until the frame count matches the pulse count.

Flush the host buffer before counting, or the frame you time is one exposure old; a stale queued frame reads as a missed trigger.

When it is the camera, not the readback

When the raw read agrees that the device state is wrong, or the tuple is right and the camera cannot hold the line rate, the camera is the fix. Compare area scan cameras in the camera finder on frame rate and interface; trigger cabling and breakout parts are in the accessories finder.

The two 12 MP examples in this guide split by interface. The LS-CMR-0053 is the GigE member: 12 MP on a 1/1.7-inch rolling-shutter sensor at 9 fps.

The LS-CMR-0166 is the USB3 member: 12 MP, 1/1.7-inch sensor, 4000 × 3000 pixels at 30 fps.

Rate arithmetic, not readback, decides between them. At 9 fps the frame period is 111 ms, so the trigger ceiling is about 9 parts per second — an estimate taken from the continuous-mode rate. At 30 fps the period is 33 ms, which fits the 50 ms part pitch of the worked example with 17 ms of margin.

On Camera Link and CoaXPress chains, frame grabbers carry host-side controls that reuse the same names: TriggerSource in the grabber node map arms the grabber, not the camera. Configure both ends and treat two nodes that share one label as two features.

Prove the fix and keep it fixed

• Rerun the matrix: 0 of 40 checks disagree, cached and raw paths identical.
• Cold start: close the application, reopen it, and confirm the startup tuple matches after init writes finish.
• Line test at rate: 20 pulses return 20 frames with the buffer flushed first.
• One owner: no second client connected, apply-on-connect disabled in any tool you must keep.
• Every write checked for errors and followed by a readback inside the same function.

If the tuple is correct and acquisition still stops after one frame, the cause is acquisition mode, not readback — continue with trigger stops after one frame. When disagreement survives the matrix on both policies, send the 40-line log with both read paths and the software versions to technical support. For a new station, start at the camera configuration step and state the trigger behavior separately from the interface choice.