Machine Vision Triggering and Encoder Synchronization
Design a deterministic acquisition-to-reject timing chain that remains correct when conveyor speed changes.
A vision system classifies every captured image correctly, but the reject cylinder removes the next part. The software team checks the model; the controls team checks the valve. The real problem is that image acquisition, part identity, conveyor motion, processing, PLC communication, and actuator timing were never designed as one sequence.
Reliable high-speed inspection needs more than a trigger wire. It needs a timing budget and a part-tracking method.
What you will learn
Separate trigger, exposure, transfer, processing, communication, and actuation delays.
Use encoder position instead of fixed time when speed varies.
Design ready/busy/result acknowledgements.
Calculate a reject timing budget.
Detect missed triggers, duplicate results, and part-tracking errors.
Technical foundation
Triggering starts an event chain
A hardware trigger may initiate frame acquisition, but several intervals follow:
Sensor/input response and configured trigger delay
Exposure
Sensor readout and image transfer
Image processing
Result communication
PLC logic and output update
Actuator electrical and mechanical delay
Each interval has a typical value and a worst-case value. Deterministic design uses the worst credible chain plus margin.
Time tracking versus position tracking
If a reject station is 500 mm downstream and conveyor speed is constant at 800 mm/s, nominal travel time is:
Travel time = 500 mm / 800 mm/s = 0.625 s
A fixed timer fails when the belt accelerates, slips, or pauses. Encoder tracking instead associates the inspected part with conveyor position. The reject command is issued when the stored part record reaches the target encoder count.
Trigger readiness and overtriggering
Cameras have a maximum frame rate or line rate for the selected resolution, pixel format, exposure, and acquisition mode. A trigger received while the camera is not ready may be ignored. Basler’s documentation recommends monitoring trigger-wait/acquisition status where available and checking host transfer capacity.
Identity and sequence
Every acquisition should receive a part or trigger sequence ID. The vision result should return that ID, recipe ID, result code, completion state, and optionally measurements or quality scores. The PLC must not assume that results arrive in exactly the same timing under every load condition.
[Suggested visual: end-to-end timing diagram from sensor trigger to reject actuator]
Purpose: Expose every latency and show where encoder position replaces a fixed delay.
Required elements: Part sensor, camera trigger, exposure, image processing, result handshake, encoder counts, PLC decision, valve delay, and reject window.
Suggested caption: “Correct inspection requires both a latency budget and a persistent part identity.”
Accessible alt text: “Timeline follows a part from photoelectric trigger through camera exposure and processing to an encoder-positioned reject action.”
Engineering workflow
1. Map physical positions
Measure the distance from detection sensor to image centre, image centre to reject actuator, and actuator zone length. Record part pitch and the minimum gap.
Why it matters: a few millimetres of undocumented reference difference becomes timing error at speed.
2. Define the trigger source
Choose a part sensor, PLC output, encoder compare, robot signal, or camera internal source. Specify electrical levels, edge, pulse width, debounce, input delay, and isolation.
Common failure: using a slow software command for a timing-critical exposure without measuring latency and jitter.
3. Build the worst-case latency budget
Measure or obtain specifications for every stage. Include maximum processing time, not only average. Add network and PLC-cycle variation.
Trade-off: buffering can absorb bursts but increases result latency and makes part association more important.
4. Choose part tracking
Use fixed time only when speed and motion are proven constant. Use encoder counts when belt speed varies. For indexed machines, use station state or nest ID. For robots, use a cycle/pose ID and confirm the coordinate timestamp.
5. Define a handshake
A robust minimal interface can include:
Vision ready
Trigger request or trigger accepted
Busy/acquiring
Result valid
Part sequence ID
Pass/fail/unknown code
Result acknowledgement
Fault and fault acknowledgement
Do not clear ResultValid until the PLC acknowledges the matching sequence ID.
6. Handle abnormal conditions explicitly
Define actions for missed trigger, trigger while busy, incomplete image, timeout, duplicate ID, stale result, network loss, queue overflow, recipe mismatch, encoder reversal, and actuator fault.
7. Instrument the system
Log timestamps and encoder counts at trigger, exposure start where available, image arrival, processing complete, result transmission, PLC receipt, and reject output. Counters should make lost frames and mismatches visible.
Worked example: encoder-based reject tracking
Hypothetical application: conveyor speed varies around 800 mm/s. The reject station is 500 mm after the image centre. The encoder produces 1,000 pulses per revolution on a 250 mm circumference measuring wheel.
Encoder scale:
1,000 pulses / 250 mm = 4 pulses/mm
Image-to-reject distance:
500 mm × 4 pulses/mm = 2,000 pulses
The PLC stores each inspected part’s trigger count and sequence ID. A failed part is scheduled for rejection near trigger_count + 2,000, adjusted for the actuator’s mechanical lead.
At 800 mm/s, nominal travel time is 625 ms. Assume worst-case acquisition and processing is 35 ms, PLC/network allowance is 10 ms, and the valve plus cylinder needs 20 ms. The result is available well before the part arrives:
625 - 35 - 10 - 20 = 560 ms nominal timing margin
The system should still issue the command by encoder position, not by waiting 560 ms. If speed drops by 20%, travel time becomes 781 ms, while the encoder target remains 2,000 pulses.
If the actuator must begin 16 mm before the part centre reaches the nozzle:
Lead counts = 16 mm × 4 pulses/mm = 64 pulses
Command target = trigger_count + 2,000 - 64
The lead distance must be verified experimentally across pressure, load, and valve-temperature variation.
[Suggested visual: FIFO part-tracking queue with encoder counts]
Purpose: Explain how multiple parts remain associated with delayed vision results.
Required elements: Sequence IDs, trigger counts, results, reject targets, current encoder count, and a completed-entry removal step.
Suggested caption: “Track each part by identity and position so result latency cannot shift the reject action to its neighbour.”
Accessible alt text: “A queue lists several part identifiers with their encoder trigger counts, pass or fail results, and future reject counts.”
Practical interface checklist
| Layer | Question | Required safeguard |
|---|---|---|
| Sensor | Can the trigger bounce or double? | Debounce and edge specification |
| Camera | Can it accept the next trigger? | Ready/status monitoring and overtrigger counter |
| Transfer | Can the host sustain bursts? | Buffer monitoring and dropped-frame counter |
| Processing | What is worst-case latency? | Timeout and queue limit |
| Result | Which part does it belong to? | Sequence ID and recipe ID |
| PLC | Was the result consumed? | Valid/ack handshake |
| Motion | Does speed vary or reverse? | Encoder position and direction handling |
| Actuator | What is the real response window? | Tested lead distance and feedback |
Common mistakes
Using a fixed timer on a variable-speed conveyor. The reject position drifts with speed.
Tracking only pass/fail bits. A late result can be applied to the wrong part.
Ignoring camera readiness. Overtriggers may be silently dropped.
Using average processing time. Rare latency spikes cause intermittent misses.
Clearing result-valid too early. The PLC may never consume the decision.
Failing to define unknown/error behaviour. A missing image becomes an accidental pass.
Ignoring encoder slip or reversal. Position tracking is only as trustworthy as the motion reference.
Testing one part at a time. Queue and identity faults appear at minimum pitch and burst rate.
Validate under production conditions
Run minimum and maximum spacing at speed extremes, acceleration, deceleration, planned stops, and restarts. Inject known failed parts at documented positions and verify the correct physical part is rejected.
Exercise faults deliberately: disconnect the camera network, overtrigger the camera, delay processing, corrupt or duplicate a sequence ID in a test environment, stop the conveyor between inspection and reject, reverse the encoder where relevant, and remove air pressure.
Acceptance evidence should include zero part-identity mismatches in the planned challenge, bounded worst-case latency, no unreported dropped frames, correct unknown handling, and verified actuator windows. Preserve traces of timestamps and encoder counts.
Key takeaways
Treat trigger-to-reject as one end-to-end timing system.
Use encoder or station position when speed is not perfectly constant.
Attach a sequence ID to every acquisition and result.
Monitor readiness, timeouts, buffer limits, and dropped-frame counters.
Validate queues, faults, and minimum pitch—not just nominal single-part operation.
Follow this Hashnode blog for more machine-vision integration guidance, and connect with Kivanc Ekici on LinkedIn. For related engineering information, visit the ITAGE Türkiye website.
Frequently asked questions
Should a PLC or camera generate the trigger?
Either can be correct. Choose the source that provides the required timing determinism and process context, then verify the electrical and timing chain.
Why use an encoder for reject tracking?
Encoder counts represent travelled distance, so the target remains correct when conveyor speed changes. A fixed time delay does not.
What happens if the camera is triggered while busy?
Behaviour depends on the camera and mode; the trigger may be ignored. Monitor trigger readiness or acquisition status and count overruns.
What should a vision result contain?
At minimum: sequence or part ID, recipe/configuration ID, completion state, pass/fail/unknown reason, and a result-valid handshake.
How do I validate reject timing?
Challenge the full system at spacing and speed extremes with known failed parts, then verify physical identity, encoder trace, output timing, and actuator response.