Hardware trigger configuration per camera: stop the free run default

The photo eye fires, the machine expects exactly one frame, and the camera streams continuously instead. The wiring is rarely the fault: the device came up on its power-up defaults, and the default is free run. This page is for engineers wiring PLC, photo-eye or motion pulses into one or more GigE or USB3 cameras, multi-camera rigs included. You will write the five GenICam nodes that arm the trigger input, order them so the SDK's own grab-start configuration cannot overwrite them, prove each camera is armed with one status read, and size the Ethernet links so the pulse rate survives the hardware.

Why does my camera stream in free run when the trigger line is wired?

Because acquisition start leaves every GenICam node at its power-up default, and that default is continuous free run: the sensor's internal clock fires each frame, so nothing arriving on Line1 changes anything.

Grab-start sample code usually registers a convenience configuration that turns software triggering on, or registers nothing at all — either way, the node writes that matter are left to you. A viewer session can look correct while your process is wrong, because the viewer wrote its own settings while it held the device; your process opens the device fresh and the defaults return. The first diagnostic split is simple: frames arriving with no pulses at all means free run is still active, not a broken cable. The acquisition-mode checks behind that symptom are walked through in GigE camera ignores external trigger: check acquisition mode first.

Which GenICam settings switch a camera to hardware trigger mode?

Four writes arm the input and one read proves it: TriggerSelector FrameStart, TriggerMode On, TriggerSource Line1, TriggerActivation FallingEdge, then AcquisitionStatusSelector FrameTriggerWait with a read of AcquisitionStatus.

What each write does:

• TriggerSelector = FrameStart selects the acquisition stage being configured. FrameStart arms every frame, so the camera waits before each one, indefinitely.
• TriggerMode = On enables the trigger just selected.
• TriggerSource = Line1 points at the first physical input; name the line the pulse is actually wired to — Line2 or Line3 on multi-input models.
• TriggerActivation = FallingEdge acts on the high-to-low transition a sinking output produces; RisingEdge suits a sourcing output.

Order matters: TriggerMode, TriggerSource and TriggerActivation apply to the trigger chosen by TriggerSelector, so write TriggerSelector first. Enumerations are case-exact strings, and a near-miss throws an invalid-value error — the symbolics check in GenICam enumeration invalid value: check symbolics before you set is the five-minute fix. Leave AcquisitionMode at Continuous so every pulse yields one frame for as long as pulses keep coming.

# Illustrative bring-up. Node names are GenICam standard; cam is the
# device handle the SDK returns on open, the helper calls stand in for
# the SDK's setters, and StartGrabbing is the grab-start call used in
# most SDK samples.
cam = sdk.open('192.168.1.10')        # one handle per camera
armed = False                         # bool; True = waiting on the selected edge
cam.set_string('TriggerSelector', 'FrameStart')
cam.set_string('TriggerMode', 'On')
cam.set_string('TriggerSource', 'Line1')
cam.set_string('TriggerActivation', 'FallingEdge')
cam.set_string('AcquisitionStatusSelector', 'FrameTriggerWait')
armed = cam.get_boolean('AcquisitionStatus')
cam.StartGrabbing()

When do I write the trigger settings so the SDK does not overwrite them?

Write the five nodes after the device is open and after any SDK-registered configuration has run, and always before the grab-start call, because a configuration registered on acquisition start can rewrite the camera's nodes at every start.

Typical samples ship a grab-start configuration that enables software triggering — convenient for one camera in the lab, fatal for a triggered rig. Do not register it, or place your writes where they run after it; the grab-start hook in common sample code (an OnGrabStart handler) is exactly where such a configuration acts. Then run the same sequence per camera:

1. Open each device by address or serial and keep one handle per camera, keyed by serial — never by enumeration order, which can change between boots.
2. Remove or bypass the SDK's built-in grab-start configuration, or fix where your writes sit relative to it.
3. Write TriggerSelector, then TriggerMode, TriggerSource and TriggerActivation as above.
4. Read all four back and stop on any mismatch; camera trigger mode source readback mismatches: find the real value shows how to find the value that actually took.
5. Set AcquisitionStatusSelector to FrameTriggerWait and confirm AcquisitionStatus reads true — armed and waiting.
6. Start grabbing, one acquisition thread per camera.
7. Tap the sensor once and confirm the status drops to false and exactly one frame lands.

How do I prove the trigger is armed before the first real pulse?

AcquisitionStatus read with AcquisitionStatusSelector on FrameTriggerWait is the proof: true means the camera sits on the selected edge waiting, and false immediately after a test pulse means that edge was accepted.

The bench sequence takes a minute. Armed reads true at start; tap the sensor once and the flag drops for the frame's capture and readout, then returns to true, with exactly one frame in the buffer. While you are at it, select the same line with LineSelector and read LineStatus idle and during a pulse: an idle level that never matches the wiring convention points at the pull-up, not the camera. Count rates too — ten pulses in one second should produce ten frames, and the arithmetic of trigger rate against frame rate is worked through in camera hardware trigger frame rate with external pulses.

Which edge and pulse width does the trigger input need?

Match TriggerActivation to the sensor's output: a sinking open-collector photo eye pulls the line low, so use FallingEdge; a sourcing PNP output raises it, so use RisingEdge; and give opto-coupled inputs a pulse of at least 1 ms on the bench.

Most camera inputs idle high through a pull-up. An NPN, open-collector output sinks the pin low to signal, so the camera sees high-to-low — FallingEdge. A PNP output ties the pin to supply — low-to-high, RisingEdge. Pulse width follows the same logic: the pulse must outlast the input's response. Phototransistor opto-couplers switch in tens of microseconds, so a 1 ms bench pulse carries roughly a 50× margin, while differential or TTL-class inputs accept microsecond pulses. The guaranteed minimum for a given input lives in its I/O appendix, so treat 1 ms as the conservative bench default rather than a universal figure. When the camera never acknowledges the line at all — level never seen, wrong line named — the checks in hardware trigger source not detected: check GenICam line settings sort it out.

How many triggered cameras can one Ethernet link carry?

Budget a practical ceiling near 118 MB/s per 1 GbE port with 9 kB jumbo frames, so three cameras pulsing at 10 Hz with 6 MB frames need 180 MB/s and will not fit — plan one camera per port, or step up to 2.5G or 10G hardware.

Worked example: a 6 MP mono sensor at 8 bits per pixel moves about 6 MB per frame (6,000,000 pixels × 1 B). At a 10 Hz pulse rate, each camera loads its link with 10 × 6 MB ≈ 60 MB/s.

Three cameras through one switch port: 3 × 60 = 180 MB/s against a 118 MB/s ceiling — frames drop. Two cameras on one link: 120 MB/s, under 2 MB/s from the ceiling, which leaves no headroom for burst and retransmit. Apply a 20% headroom rule and the working budget on 1 GbE is 118 × 0.8 ≈ 94 MB/s — even two such cameras exceed one port. The decision falls out of the arithmetic: one camera per port at this rate.

The bench numbers assume a 6 MP mono GigE camera with a 1/1.8" sensor and a C-mount:

Check the table's arithmetic once: 118 × 0.8 = 94.4, and 94.4 ÷ 60 = 1.57, so one stream; 280 × 0.8 = 224, and 224 ÷ 60 = 3.7, so three; 1,150 × 0.8 = 920, and 920 ÷ 60 = 15.3, so fifteen. Packet size does not create bandwidth, but raising it toward 9 kB cuts CPU and interrupt load enough to reach these ceilings — the procedure is in set GigE camera packet size before starting acquisition. USB3 sidesteps the table: a USB3 port moves roughly 350-400 MB/s in practice, so two to five cameras of this size fit per controller before the host becomes the limit.

For two cameras the clean build is one port each — power and data ride one cable per camera. The MV-GE2002P is a dual-port PoE NIC, full height V2.0, with two GigE ports.

Four or more triggered cameras need more ports, and one camera per port still applies. The MV-GT2104 is a quad-port copper 10GbE NIC; the MV-GE4004 is a quad 2.5G Ethernet adaptor.

One limit sits behind the table: the ports of a multi-port card share the host slot. Four 10G ports at full rate need about 4.6 GB/s (4 × 1,150 MB/s), while a PCIe Gen3 x4 slot supplies about 3.9 GB/s (four lanes at 985 MB/s), so check the host interface before loading every port at line rate.

What still breaks multi-camera triggering after the settings are right?

The remaining failures are order and ownership: settings written after acquisition starts, one shared grab loop for all cameras, or callbacks bound to a device handle that re-opens and changes identity between runs.

In the order they usually bite:

• AcquisitionMode left at SingleFrame — the first pulse frames, the second is ignored; hardware trigger stops after one frame: check acquisition mode is the walk-through.
• Startup writes skipped on one device — iterate the serial-keyed handle map every boot, never 'the first camera found'; writes that land at the wrong moment are covered in camera trigger overlap configuration: verify startup writes.
• One shared grab loop — give each camera its own acquisition thread and buffer pool, so a slow save callback on camera A cannot delay camera B.
• Callbacks bound to the device object — bind to serial number and map serial to callback, so a reconnect cannot re-route frames to the wrong handler.
• Pulse period shorter than exposure plus readout — with overlap off, a pulse landing inside readout is dropped silently; keep the period above frame time and confirm saved settings on boot, as in camera startup frame rate: verify saved settings and readback.

What do I order for a three-camera triggered bench?

For the bench in this guide: three triggered GigE cameras, a quad-port NIC so each camera gets its own port, and one pulse source wired to all three Line1 inputs — then the configurator finishes the lens, cable and accessory list.

The camera configurator walks camera, lens, light and extras in order, and the area scan cameras page filters by interface, resolution and shutter. Ports and frame grabbers sit under frame grabbers, with the accessories finder for the NICs. If the pulse source, strobe timing or link budget deserves a second opinion before ordering, /contact/ reaches the applications team.