Can the trigger be sent from software instead of a wire? On a line scan camera or a laser profiler the answer splits cleanly, because two triggers with different jobs feed the acquisition. The encoder input must stay hard-wired: the motion phase it carries exists nowhere else. The frame trigger can move to the network: set the camera to software triggering and send a global trigger event. This guide gives the decision rule for each signal, the latency arithmetic that sizes the software path, and a worked example with every number carried through.
Two triggers, two jobs
A line scan camera advances one sensor line at a time and assembles those lines into an image of moving material, so two signals steer the process. The frame trigger starts acquisition: it opens the scan window when a part arrives. The line trigger advances the sensor by one line, and on moving material it comes from the encoder, through a divider that turns ticks into line triggers. Cameras expose both as trigger-source settings, with the encoder wired to dedicated inputs as the quadrature pair A and B.
The frame trigger answers when to start. The line trigger answers where the part is right now. A network event can carry the first answer; it can never carry the second.
The wiring side of the encoder input — differential pairs, direction sensing, the index channel — is walked through in encoder-triggered line scan capture: wiring quadrature inputs.
What an encoder pulse carries that software does not
An encoder pulse marks a fixed slice of travel. A 2048 pulse-per-revolution encoder on a 200 mm measuring roller gives 2048 ÷ 200 = 10.24 pulses per millimetre; decoding quadrature ×4 raises that to 40.96 ticks per millimetre. That mapping is the whole value of the signal: lines land at equal steps of travel, so pixels stay square whatever the speed does.
A pulse stream synthesized in software has no such mapping. The PC knows only its own clock, not where the web is. At 1 m/s the encoder above demands a tick every 97.7 µs (10,240 Hz before quadrature), or every 24.4 µs at ×4. A 1 ms software timer emits one pulse for every 41 ticks the motion actually made, and its jitter shifts line to line: straight bars come out wavy, a speed change stretches the image, and a web that halts mid-scan leaves a torn one.
Quadrature also carries direction — B leads A one way and lags it the other — and the camera uses that to hold image orientation. Polling cannot track direction at these rates either.
A PLC in ordinary scan logic sits in the same place: a 1–10 ms cycle cannot emit a clean 24.4 µs pulse train. Encoder counting belongs in counter hardware, not the PLC's standard scan logic, and the same physics holds one wire further along, at the camera's line trigger input.
The frame trigger is where software wins
The frame trigger only has to fire before the part enters the field, and an event can do that from anywhere. Set the camera's frame trigger source to software, configure the global trigger in the vision platform's communication manager, and a message from a PLC, WMS or upstream station opens the next scan window. The same event path can drive a network-managed controller's output, whose physical pulse lands in the camera's trigger input in place of the photoelectric sensor.
The budget is travel, not jitter:
An event on a switched GigE LAN, including the platform's processing, typically costs 1–10 ms; measure yours once and keep at least 5× margin. At 1 m/s, even 10 ms is 10 mm of travel: fire while the part sits 150 mm upstream and it arrives 140 mm short of the field. A millisecond or two of jitter disappears inside that margin.
Two camera settings decide whether the software path works. Acquisition mode must accept repeated starts, or the camera takes one frame and quits — the failure in hardware trigger stops after one frame. Every triggered scan still obeys the exposure-plus-readout ceiling in maximum frame rate on a hardware trigger, whatever fires it, and irregular event spacing can make one scan window run into the next, the overlap case in line scan image overlap across frame boundaries.
If you keep the hardware path instead, the sensor side is a wiring choice: PNP or NPN from a photoelectric sensor.
What a networked controller can and cannot stand in for
A vision controller managed from the platform can open a physical output on command. Into the frame trigger, that output is a legitimate stand-in for the photoelectric sensor: part detection becomes a commanded pulse instead of a wired one, at software-grade timing. The travel budget above applies unchanged.
The same output cannot stand in for the encoder. It would still be a pulse train timed by a PC clock, carrying no motion phase, and the image would tear exactly as shown above. The architecture rule survives every variant: encoder wire to the line trigger; product detection by sensor, controller output or network event, whichever passes the travel budget. When the PLC owns detection anyway, its high-speed counter can generate a high-speed camera trigger from encoder position — the signal still reaches the camera as hardware; only its source moved into the PLC.
Worked example: 4K camera on a 1 m/s web
Set-up: a paper web at 1 m/s (1000 mm/s), a 63.7 mm measuring roller (200 mm circumference), a 2048 PPR encoder, and a 4096-pixel camera whose lens covers a 100 mm field. The chain, with the arithmetic:
- Encoder scaling: 2048 × 4 ÷ 200 = 40.96 ticks per millimetre.
- Line rate: 1000 mm/s × 40.96 ticks/mm = 40,960 Hz ≈ 41 kHz.
- Pixel pitch: 100 mm ÷ 4096 px = 0.0244 mm across the web, so 40.96 px/mm matches 40.96 ticks/mm and the pixels are square.
- Exposure limit: 0.0244 mm ÷ 1000 mm/s = 0.0000244 s = 24.4 µs per line; run 20 µs and blur is 1000 × 0.000020 = 0.020 mm, about 0.82 px.
- Frame path: detection sits 150 mm upstream; a 5 ms event travels 1000 × 0.005 = 5 mm, leaving a 145 mm margin. The software frame trigger passes; the encoder stays wired.
The exposure-versus-blur trade on moving webs is carried further in camera fps and shutter speed for moving web inspection.
Size the camera against that 41 kHz target. The LS-LCM-0016 is a 2K GigE line scan camera with 7 µm TDI pixels, a 58 kHz line rate and an M42 mount. The 41 kHz requirement leaves headroom on that listing; a 4K or 8K sensor at the same web speed moves to Camera Link, 10GigE or XoFLink bandwidth.
- Lens mount
- M42
- Interface
- GigE
- Line length
- 2K
- Pixel size
- 7 μm
For the 4096-pixel row in the example, the card below is the camera class to compare.
- Lens mount
- M42
- Interface
- GigE
- Line length
- 4K
- Pixel size
- 7 μm
The MV-CL042-91GC-V2 is a 4K GigE line scan camera with 7 µm pixels, a 29 mm image circle and an M42 mount. At the example's 100 mm field, a 4096-pixel sensor samples 40.96 pixels per millimetre, the square-pixel condition from the arithmetic above; a colour sensor at this line length suits print and packaging webs where RGB separation helps.
The decision, signal by signal
| Signal at the camera | What it carries | Software event can replace it? | Decision |
|---|---|---|---|
| Encoder A/B into the line trigger | travel phase, at tick rate | No — the phase exists only at the encoder | Wire it |
| Photoelectric sensor into the frame trigger | part incoming | Yes, if the travel margin passes | Event or wire, both valid |
| Controller output into the frame trigger | commanded part detection | Already software-timed | Fine for spaced, slower parts |
| PC-generated pulse during tests | nothing | Not a production trigger | Bench only |
Carry the table to the bench: for each wire into the camera, ask what the signal knows. If the answer is where the material is, it stays a wire. If the answer is that a part exists, software may send it.
The same split on a 3D laser profiler
A laser profiler captures one profile per line trigger of a moving part, exactly the line scan pattern, so the split carries over unchanged: the encoder feeds the profiler's encoder input hard-wired, and the scan window can start from a global trigger event. A profiler such as the MIS-DP3850-01P keeps that division of labour. The distortion tell in 3D is direct: edges straight on the part but warped along the travel direction mean the profile timing lost its phase. When a software-triggered profiler underdelivers, the causes sit in trigger mode and stream configuration, as in 3D camera frame rate low on software trigger.
- Type
- Laser profiler
When the usual answer is wrong
Free fall and fast transport. Above roughly 2 m/s the software budget collapses: at 3 m/s a 5 ms event is 15 mm of travel and the part can outrun the scan window. There the frame trigger goes hardware too; free-fall optical sorting walks the timing chain end to end.
TDI sensors. Time-delay-integration stacks signal across stages that must each see the same part position, so encoder timing is mandatory and its quality shows up directly in contrast.
Servo-owned motion. If a drive generates the transport, its own pulse output can drive the line trigger without a separate encoder. Still a hardware wire, phased to real motion, so the rule holds.
And the flip: parts arriving in long, irregular gaps on an idle conveyor are simpler on a software frame trigger per part than on encoder-gated capture; sensor-triggered line scan with encoder-driven capture covers that hybrid.
Checks before you commit
- Signal type: match the encoder's electrical standard (differential pair or single-ended 5–24 V) to the camera input; when the source is not detected, start at GenICam line settings.
- Scaling: ticks per millimetre equals pixels per millimetre after the divider; the full scaling arithmetic is in encoder ticks per pixel.
- Exposure: at or below pixel pitch ÷ speed, so blur stays inside one pixel.
- Line rate: top-speed rate below the camera's rating, with 20–30% headroom.
- Acquisition mode: set for repeated software starts before testing the event path.
- Latency: measured once on your own network, not assumed; design with 5× margin.
- Safety: light curtains untouched by any change above.
- Image test: capture a bar pattern perpendicular to travel; straight bars in the image prove the line timing holds phase.
Where to go next
Shortlist cameras by line length, line rate and trigger I/O in the camera finder, or step through the camera configurator. The line scan cameras category lists the series by mount and interface, and 3D sensors covers the profiler side. More trigger and timing material sits on the cameras topic page. If your transport speed, encoder specification and part rate leave the trigger architecture unclear, describe the line on the contact page and we will size the chain with you.
Questions
Can a line scan camera run on software triggers alone?
Only where image geometry does not matter. The frame trigger can always be a software event, but without encoder-driven line triggering the pitch between lines varies with speed: accelerate 10% and the image stretches 10% along the travel direction. For measurement, barcode grading or defect geometry on moving material, keep the encoder wired to the line trigger input and let only the scan-window start move to software.
What does a line scan camera's encoder input expect?
Usually two quadrature channels, A and B, plus an index (Z), as differential RS-422 pairs or single-ended signals in the 5–24 V range. A line-delay setting on the camera compensates the offset between where the encoder measures and where the sensor looks. Match electrical types before wiring: a differential output into a single-ended input is the most common cause of a trigger that never arrives.
How much latency can a software frame trigger tolerate?
Use travel = speed × latency. At 300 mm/s a 5 ms event costs 1.5 mm, trivial when the part is 150 mm upstream. At 2 m/s the same event costs 10 mm, so detection must sit further upstream or move back to a wired sensor. Measure the latency on your own network once and keep at least 5× margin.
Can a PLC output replace the photoelectric sensor at the camera?
Yes, for a frame trigger. A PLC digital output, or the physical output of a network-managed vision controller, lands in the camera's trigger input exactly like a sensor would. Budget the scan cycle: PLC outputs can lag their logic by milliseconds, so fire earlier or move detection upstream. The encoder input is the exception; it needs the motion signal itself, not a commanded copy.
Does this change for a 3D laser profiler?
The split is the same. The encoder drives when each profile is captured, so it stays hard-wired; the scan window can start from a global trigger event. Software-substituted encoder timing shows up in the point cloud as heights warped along the travel direction on edges that are straight on the real part.