Triggering and Synchronisation: When to Take the Picture

A correct algorithm running on a badly timed image still produces a wrong verdict. The part is not where the algorithm expects it, the region of interest clips the edge, the template match settles on the wrong feature. What makes this failure mode so persistent is that nothing looks broken: the image is sharp, the lighting is right, the model was validated on the bench. It is simply a picture of the wrong instant, and it happens only when the line runs at production speed.

Hardware trigger and software trigger

A software trigger means the host program decides the moment and sends a command over the network or the bus. The problem is that it is a command in a queue. The operating system may be scheduling something else, the network stack may be buffering, the application may be waiting on a database write. The result is a latency that is typically tens of milliseconds and, more importantly, one that varies from part to part. For a stationary part this is irrelevant. For a part on a conveyor it is the difference between imaging the part and imaging the gap behind it.

A hardware trigger feeds an electrical signal directly into the camera trigger input, and the camera responds in a time measured in microseconds, defined by the sensor rather than the host. That is the reason a photoelectric sensor wired to the camera input outperforms a much more expensive host computer issuing the same instruction in software. The rule is straightforward: whenever the part is moving, or whenever the station cycle time is under about a second, use a hardware trigger.

A sensor marks a place, an encoder marks a distance

A photoelectric sensor fires when the part interrupts the beam. It is simple and cheap, but it fires at a position that depends on the part itself: a light part, a shiny part, a part with a hole at that point, or a part arriving at a slight angle all trip the beam at slightly different moments. The consequence is a positional spread of a few millimetres, which for a task like reading a small mark or measuring a short gap is often too much.

An encoder solves this by generating a pulse every fixed increment of conveyor travel, so the trigger is tied to distance rather than to a beam interruption. Because the pulse is a property of the conveyor and not of the part, the image is taken at the same physical position for every part, and the variation introduced by part geometry disappears. For anything on a driven conveyor or a indexing table, the encoder pulse is the more stable choice. Note that this is the same division of labour that decides what the vision system should judge and what a simpler sensor should handle, which is set out in vision and sensors.

Latency can be compensated, jitter cannot

Two timing errors are routinely confused, and they need opposite responses. Latency is the fixed lag between the trigger event and the moment of capture — the camera wake-up time, the cable propagation, the deliberate delay a controller inserts. Latency is harmless in itself because it is predictable: if every image is taken 8 ms late, the trigger can simply be moved 8 ms earlier, and the images land where they should.

Jitter is the part that varies, and it cannot be compensated because there is nothing stable to subtract. Trigger-to-capture jitter from the camera, variation in the conveyor speed, mechanical play in a chain drive and vibration in the mounting bracket all contribute. Jitter sets the floor on positional repeatability, and that floor converts directly into measurement uncertainty through the arithmetic in accuracy conversion. Reducing the exposure time reduces the distance travelled during the exposure, but it does not reduce jitter in the trigger instant itself.