A vision system that classifies a part correctly and then rejects its neighbor is worse than no inspection at all. It scraps a good part, ships a bad one, and leaves an audit trail claiming the opposite. After 25 years of commissioning automation, I can say that most inspection problems I’m called to are not model problems. They are integration problems: the trigger jitters, the reject is timed in milliseconds instead of millimeters, a result arrives for the wrong part, or nobody decided what should happen when the camera goes dark. Get the trigger, the tracking, the handshake and the timing budget right, and the model’s verdict lands on the part it was meant for.
Start with a hardware trigger
The camera should be told to expose by a wire, not by a message. A photo-eye or a part-present sensor wired to the camera’s trigger input, with the strobe fired from the same signal, gives an exposure that lands in the same place on every part. Software triggering, where the PLC sends a command over the network or the vision application polls a sensor, adds variable delay. At 1 m/s, every millisecond of jitter is a millimeter of position error in the image.
Two related details matter:
- Global shutter. A rolling-shutter sensor exposes rows at slightly different times, which skews moving parts. Global-shutter cameras such as Lensnode V expose the whole frame at once.
- Strobe length. Motion blur is line speed multiplied by exposure time. At 1,000 mm/s, a 50 µs strobe limits blur to 0.05 mm.
Track the part by position, not by time
The simplest reject logic is a timer: the part was seen, so fire the gate 600 ms later. It works on the bench and fails in production. The moment the line slows, ramps up after a stop, or the conveyor slips under load, the timer fires on the wrong part.
An encoder on the conveyor, or on a measuring wheel riding the belt, turns movement into counts. The PLC’s high-speed counter latches the count at the instant of the trigger. The reject fires when the count reaches the trigger count plus the camera-to-gate offset. If the line slows, the reject slows with it. If the line stops, nothing in the tracking moves.
Sizing the encoder
Pick a resolution that makes position errors negligible compared with the part. Here is a hypothetical example: a 2,000-pulse-per-revolution encoder on a measuring wheel with a 200 mm circumference gives 10 counts per millimeter. A camera-to-gate distance of 600 mm becomes an offset of 6,000 counts. Mount the wheel on a belt section that moves with the parts. Encoder tracking assumes the part moves with the belt, so accumulation conveyors where parts slip need a second detection point near the gate.
Shift registers, FIFOs and part IDs
With several parts between camera and gate, results have to be matched to parts, not just to “the next one”. The usual pattern is a FIFO in the PLC:
- At the trigger, the PLC assigns a part ID (a sequence number), latches the encoder count, and pushes both into the FIFO with the result set to “pending”.
- The vision system receives the same ID with the trigger, or counts triggers itself, and returns the result tagged with that ID.
- The PLC writes the result into the matching FIFO entry. If the returned ID doesn’t match any pending entry, it raises a tracking fault.
- When the encoder count reaches an entry’s reject position, the PLC acts on the result. A result that is still pending at that point is treated as a reject.
Rule 4 is the important one. Silence must never mean “pass”.
A worked timing budget
Every number below is hypothetical, chosen to show the method. Measure your own.
- Line speed: 60 m/min, which is 1,000 mm/s.
- Part pitch: 150 mm, so 400 parts per minute and a new image every 150 ms.
- Camera to reject gate: 600 mm, so a part takes 600 ms to arrive and 4 parts are in flight at any moment.
| Stage (worst case) | Time |
|---|---|
| Trigger to end of exposure | 1 ms |
| Sensor readout and transfer to the edge gateway | 6 ms |
| Pre-processing and inference | 20 ms |
| Result to PLC over EtherNet/IP at a 10 ms RPI | 10 ms |
| PLC logic, two full scans at 10 ms | 20 ms |
| Decision path: trigger to result in the FIFO | 57 ms |
| Output module and solenoid valve response | 15 ms |
| Air jet reaching the part | 15 ms |
| Actuation lead time | 30 ms |
The actuator’s 30 ms is fixed in time, so the PLC must fire the output while the part is still 30 mm short of the gate at this speed. The result therefore has to be in the FIFO within 600 − 30 = 570 ms of the trigger. The decision path takes 57 ms, which leaves a margin of more than 500 ms. That is comfortable.
Now suppose the mechanical designer moves the gate to 150 mm from the camera to save floor space. The part arrives in 150 ms, the deadline becomes 120 ms, and the margin drops to 63 ms. That is still workable. If production then raises line speed to 120 m/min, the part arrives in 75 ms and the deadline is 45 ms. The 57 ms decision path is 12 ms too late, so every reject fires behind its part.
Three lessons come out of this exercise:
- Budget the worst case, not the average. Inference time has a tail, network updates arrive at any point in an RPI cycle, and PLC scan times vary. Measure the slowest result over a long run at full speed.
- Compensate for speed. Because actuator delay is fixed in time, the firing point in counts must move earlier as speed rises. Many PLC high-speed counter or cam functions support speed-compensated outputs.
- Keep the gateway’s share in proportion. Typical inspection models on a Gatepoint decide in under 40 ms frame-to-I/O. That covers only the first rows of the table. The rest belongs to the network, the PLC and the pneumatics.
Confirm the reject actually happened
Firing an output is not the same as removing a part. Air pressure drops, valves stick, diverter arms wear and reject bins fill. A confirmation sensor closes the loop. A photo-eye in the reject chute should see a part within a short window after each reject command, and a sensor after the gate can confirm that the part is no longer on the main conveyor. Add a bin-full sensor and a low-air pressure switch. A missed confirmation should raise an alarm, and on many lines it should stop the line. Food and pharmaceutical customers’ audits often expect reject verification as a matter of course.
Heartbeats and watchdogs
A vision application that has frozen still holds its last output state, which may well be “pass”. To catch that, the vision system toggles a heartbeat bit on a fixed period, for example every 500 ms, and a watchdog timer in the PLC faults if the bit hasn’t changed within, say, 1.5 s. Run the same check in the other direction, so the vision system knows the PLC is alive. Add explicit status bits as well: camera connected, model loaded, system ready. The PLC should refuse to treat any result as valid unless “ready” is true.
Decide the fail-safe state before commissioning
What happens when something fails is a production decision, not a programming detail. Write it into the inspection spec and test every row.
| Failure | Detected by | Typical response |
|---|---|---|
| Vision application or gateway down | Heartbeat watchdog | Mark all in-flight parts as rejects, raise a stack-light alarm |
| Camera disconnected or image dark | Ready bit drops; image brightness check | Same as above |
| Result missing for one part | Entry still pending at reject position | Reject that part |
| Part ID mismatch | ID comparison in the PLC | Reject, log a tracking fault; stop after several in a row |
| Reject not confirmed | Chute or post-gate sensor | Stop the line; operator retrieves the part |
| Reject bin full or air pressure low | Level sensor; pressure switch | Stop the line before rejects become impossible |
The default principle is fail to reject: when in doubt, the part goes to the bin, not to the customer. On high-volume lines, rejecting everything for long can create its own scrap problem, so some plants prefer to stop the line after a short delay. Either is defensible. Leaving the choice undecided is not. Pick actuators whose de-energized state matches the decision, such as a diverter that falls to the reject position on loss of power or air, if fail-to-reject is the rule.
Discrete I/O, EtherNet/IP or PROFINET
| Interface | Strengths | Watch for | Typical use |
|---|---|---|---|
| Discrete I/O (24 V DC) | Simple, deterministic, independent of the network | Few signals; PLC input filter delays | Trigger, reject, heartbeat, ready |
| EtherNet/IP | Cyclic implicit I/O at a configured RPI, plus explicit messages; EDS files | RPI adds up to one interval of delay | Part IDs, results, status words; common with Rockwell controllers |
| PROFINET | Cyclic real-time I/O with millisecond-range update times; GSDML files | Network configuration owned by the PLC project | The same roles on Siemens and other PROFINET controllers |
Discrete I/O for the time-critical bits, plus EtherNet/IP or PROFINET for IDs, results and diagnostics, is a sound default. OPC UA and MQTT belong to traceability and MES data, not to the reject path. Our integrations page lists what the Perflens stack supports.
Commissioning tests worth running
Before handing over a line, run these with marked known-bad parts:
- Full speed, minimum speed and every speed change in between.
- Stop and restart with parts between camera and gate, including an emergency stop.
- Parts removed and added by hand during a stop.
- Gateway power pulled mid-run, then camera cable pulled.
- Air supply valved off, and the reject bin filled to its sensor.
- Back-to-back defective parts at minimum pitch.
Every test should end with the right parts in the bin and a log entry explaining why. Whether you are building a new AI inspection cell or retrofitting cameras you already own, the model gets the attention. The tracking and the handshake decide whether it does any good.