A triggered camera that reports a buffer-wait timeout is telling you one thing: no frame arrived inside the driver's wait window, and the usual culprit is the pulse source, not the camera and not the driver. This page is for engineers who trigger area scan cameras from an IMU, a PLC or a sensor line and who also see a stream of 'feature not implemented' messages at start-up. You will measure the pulse at the right pin, separate wiring faults from configuration faults, size the exposure against the trigger period with the arithmetic shown, and match one fix to each test result.
Why does the camera fail waiting for a buffer on an external trigger?
The camera is rarely the fault: a buffer-wait timeout means the driver's wait expired with no frame delivered, and at the trigger's 50 ms period a typical one-second wait spans about twenty pulse periods, so an empty wait means zero pulses arrived.
The grab call blocks on a buffer-fill event. When the wait lapses, the driver logs the timeout and then often logs a second error about a camera that is 'still streaming' during teardown. Read those as one fault: nothing was captured, so there is nothing to stop. The same chain shows up as a missing sync pulse in camera sync pulse missing: fix the acquisition timeout.
Put numbers on the promise. A source set to 20 Hz owes one edge every 1 / 20 Hz = 0.050 s = 50 ms. A driver that waits about one second per buffer covers 1000 ms / 50 ms = 20 pulse periods per wait. Zero frames in that window means zero of twenty expected pulses: a dead or misconfigured source, not a slow one.
Intermittent failures tell a different story. If the error appears on some launches and not others, the pulse count is coming up short mid-run, or the first edges land before the camera is armed. The soak test in the pulse-measurement section below separates a stalling source from a start-up race in one run.
Are the 'feature not implemented' errors the real problem?
Ignore them: 'not implemented' and 'not available' messages for AcquisitionFrameRateEnable and AcquisitionFrameRate are logged while the driver applies a free-run parameter set to a triggered camera, and in trigger mode those frame-rate controls are hidden by design.
In trigger mode your pulse train sets the cadence, so the camera marks the frame-rate enable switch and the rate value as unavailable. A driver written for free-run still tries to write them at connect, gets refused, logs the message and carries on into acquisition. The timing proves the layer: feature errors appear before the first grab, and the timeout appears during grabs. Frames stop when pulses stop, not when a frame-rate write fails.
The same read applies down the log. LineMode reported as not writable and LineSource reported as not available are normal on an input line: those controls belong to output lines, and the line wired for triggering is an input. Nothing is broken there either.
If the noise bothers you, delete the frame-rate parameters from the triggered configuration; the messages disappear and nothing else changes. When a feature you genuinely need refuses writes, follow GenICam attribute not writable: set the feature mode first.
How do I prove the trigger source is pulsing?
Measure at the camera's input pin, not at the source: a healthy trigger shows one clean edge every 50 ms, 200 edges in a 10 s window, swinging across the full logic range the input expects.
With a scope, probe the pin and clip the ground at the connector. A 50 ms edge is slow by instrument standards, so any bench scope resolves it, and the useful reading is the count, not the shape: a 10 s window at one edge per 50 ms owes 10 s / 0.050 s = 200 edges. Run a five-minute soak and expect 300 s / 0.050 s = 6,000 pulses; a shortfall marks the stall, and zero marks a source that never emits.
Without a scope, ask the camera itself. GenICam exposes a line-status readout (LineStatus per line, LineStatusAll for all lines at once); poll it at 1 kHz and count transitions. A 50 ms cycle toggles twice per period, so expect 40 transitions per second. The camera's own report already includes the cable, the connector and the level, which is exactly the path under suspicion.
If edges show at the source but never reach the pin, the fault is in the wiring: pin, polarity and ground, covered step by step in external trigger timeout: wrong pin or wrong ground.
How much exposure does the trigger period allow?
Keep exposure plus readout inside the 50 ms period: at that cadence the camera must finish each frame before the next pulse arrives, so with a 25 ms readout the exposure ceiling is 25 ms, and 15 ms leaves a 10 ms margin.
Worked example, with the readout figure taken from your model's frame-rate line (40 fps here is illustrative):
- Trigger period: T = 1 / f_trigger = 0.050 s = 50 ms, as established above.
- Readout: a camera that lists 40 fps at full frame implies about 1 / 40 s = 25 ms.
- Exposure ceiling: 50 ms - 25 ms = 25 ms.
- Set exposure to 15 ms: frame time = 15 + 25 = 40 ms, which fits the period with a 10 ms margin, an 80% duty cycle.
- Achieved rate: 1 / 0.040 s = 25 fps, above the pulse rate, so every pulse yields a frame.
Overshoot the budget and pulses go unserved: 30 ms + 25 ms = 55 ms per frame gives 1 / 0.055 s = 18.2 fps against 20 pulses per second, so about one pulse in eleven produces nothing. The full treatment, with the readout term measured rather than assumed, is in maximum frame rate on a hardware trigger: exposure plus readout time. If you only need a steady rate and have no source at all, some cameras offer an internal precision-trigger mode that holds the frame rate to a published tolerance; it sits in the acquisition feature set, not behind the frame-rate enable switch.
The scope habit transfers across trigger problems: checking lighting pulse timing and camera exposure overlap applies the same measurement to a strobe line.
Which line settings must match the pulse source?
The camera must listen on the line your source drives: set TriggerMode to On, point TriggerSource at the wired input, and set TriggerActivation to the edge your scope showed, rising for a pulse that idles low and jumps high.
Set ExposureMode to timed when the camera controls exposure length, or to width mode when the pulse duration is the exposure. After every write, read the value back: a preset that loads differently than it was written fails silently hours later, which is the pattern in camera trigger mode source readback mismatches. The line objects themselves are walked through in hardware trigger source not detected: check GenICam line settings.
On the hardware side, keep one ground reference between source and camera, or isolate the input. An opto-isolated input switches on current, so its series resistor must be sized for the LED; the arithmetic is in wiring a pulse into an opto-isolated input, with the resistor math. One pulse feeding two cameras is a fan-out job, not a daisy chain; the safe split is in fanning one trigger pulse out to several cameras.
When is a buffer timeout not the trigger's fault?
Rule the configuration out before blaming the pulse: a camera whose acquisition never started, whose trigger mode is still Off, or whose buffers are exhausted shows the same timeout as a dead source, and one readback separates the cases.
Acquisition mode comes first: a camera left in the wrong acquisition mode ignores pulses entirely, walked through in GigE camera ignores external trigger: check acquisition mode first. Then arming order: acquisition must start before the first edge is expected. If your first grab races the first pulse, poll the status call as shown in last valid buffer before first trigger: poll the status call.
Pipeline causes look identical from the log. A consumer that returns buffers slowly starves the queue, and a negotiated-down link (a USB3 camera on a 2.0 port, a GigE link fallen to 100 Mbit) caps throughput below your pulse rate; check the link rate and raise the buffer count before re-testing the trigger. The teardown error about a camera 'still streaming' belongs to this family: it is the driver de-initializing while a wait is still outstanding.
Which fix matches each test result?
Let the measurement pick the fix: pulses present at the pin point to software, pulses at the source but not at the pin point to wiring, and no pulses anywhere point to the source device itself.
| What you measure | Where the fault sits | The fix |
|---|---|---|
| 200 edges in 10 s at the pin | Configuration: mode, source or activation | Read back TriggerMode, TriggerSource and TriggerActivation; correct and re-arm |
| Edges at the source, none at the pin | Wiring: cable, level or ground | Swap the cable, tie one ground reference, match the amplitude to the input |
| No edges anywhere | The source is not emitting | Enable the pulse output, set it to the agreed rate, power-cycle and recount |
| 174 edges in 10 s instead of 200 | The source stalls mid-run | Soak for five minutes (6,000 expected) and clear contention at the source |
| Edges correct, camera armed, still timing out | Pipeline: buffers or link rate | Raise the buffer count; check the negotiated link rate and host load |
Work top to bottom. Each row takes minutes at the bench, and the first row that matches names the owner of the fix: pulse, wire, camera or host.
Which camera and cabling suit a pulse-triggered pair?
If the source is fixed but the pair still misses frames, upgrade the weakest link: a global-shutter camera with a dedicated trigger input, wired in shielded drag-chain cable, turns a marginal pulse chain into a production one.
A rolling-shutter pair triggered together still exposes rows at staggered instants, so global shutter is a requirement, not a preference. For the pixel-hungry end:
- Sensor format
- 1.1"
- Lens mount
- C-mount
- Interface
- USB3
- Resolution
- 12 MP
The MV-CH120-11UC puts 12 MP behind a global shutter on USB3, with a C-mount and a high-speed readout variant. Where the Ethernet link is the constraint instead:
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- Up to 3 MP
The MV-CU020-90GC is a 2.5 MP GigE camera with a global shutter on a 1/1.7-inch sensor and a C-mount. For the pulse and power runs:
- Type
- Power and I/O cables
- Length
- 6-8 m
- Type
- Frame grabber I/O cables
- Length
- 6-8 m
The LS-CBL-0300 carries power and I/O on an M8 8-pin connector, 8-core to open end, over 7 m rated for drag-chain service. The LS-CBL-0224 breaks frame-grabber I/O out on a DB9 female to open leads, 7 m, which suits a bench source on a screw-terminal board.
The camera finder filters the area scan cameras range by shutter and interface, and the matching leads sit under power and I/O cables.
How do I stop the timeout from coming back?
Prevention is a pulse budget with margin: hold the duty cycle at or under 80%, log the pulse count every session, and strip the free-run frame-rate parameters from the triggered configuration.
Run every triggered session against this checklist:
- Budget the frame at 80% duty or less: 40 ms of exposure-plus-readout inside a 50 ms period leaves 10 ms of slack for jitter.
- Soak the source before the run: 6,000 pulses in five minutes, logged to file, not eyeballed.
- Read back TriggerMode, TriggerSource and TriggerActivation at session start; a preset that did not load shows up in seconds.
- Keep the triggered configuration free of free-run frame-rate parameters, so the not-implemented noise never returns.
- Use one ground reference, or one properly isolated input per camera; mixed grounds turn ground offset into spurious edges.
Work the chain in that order and a buffer timeout stays a ten-minute measurement: prove the pulse, read back the lines, then touch the driver. To size a new triggered pair, start at the system configurator, check the accessories finder for trigger cabling, and browse the trigger-side guides on the systems topic page; the applications team answers set-up questions through the contact page, and free expert support comes with every order.
Questions
Can one trigger pulse drive two cameras at once?
Yes, but split it electrically rather than chaining it through a camera output. Feed both trigger inputs from one buffered driver, set both cameras to the same edge and the same exposure, and give each run one ground reference or its own isolation. At 20 pulses per second the bandwidth demand is trivial, so keep the two cable runs about equal in length and the exposure starts will align far tighter than any software sync.
Why does the timeout appear only on some runs?
Intermittent timeouts mean an intermittent pulse train. Count edges over a long window instead of trusting one launch: the target rate owes 6,000 pulses in a five-minute soak, and a count such as 5,700 shows the source stalls under load or its output resets. A count of zero from the first frame points instead at a dead source or a camera that was never armed, which the line-status readback separates in seconds.
Does the AcquisitionFrameRateEnable error block frames?
No. The write is attempted once, while parameters load before the first grab, so it cannot cause a timeout that happens during acquisition; the two errors live in different layers. In trigger mode the camera hides frame-rate control because the pulses set the cadence, the write is refused as not implemented, and acquisition continues. Delete the frame-rate parameters from the triggered configuration and the message disappears without any other effect.
What pulse amplitude does a camera trigger input need?
Read the rated range from the data sheet of your model, because families differ: non-isolated lines usually accept low-voltage logic only, while opto-isolated inputs switch on current, so a higher-voltage pulse works once a series resistor limits the LED current. Scope the idle level too. A line that idles at the active level delivers zero frames no matter how many edges you count at the source.
Do I need a sync box for a hardware-triggered stereo pair?
No. One pulse fanned to both trigger inputs aligns the exposure starts within the electrical skew of the split, typically well under a microsecond at this rate, so no extra synchronizer is needed. What matters is the shutter type and the exposure match: use global shutters, set equal exposure times, and keep rolling-shutter cameras out of a measurement chain.