// Quality control

Machine-vision quality control, on a line that keeps running.

Any vision library can spot a scratch in a photo. The real problem is doing it a thousand times an hour, on the right part, deciding within cycle time and rejecting automatically — without stopping the line. Here is what separates a demo from a production system.

Why the demo works and the line does not

In the lab the image is still and clean; on the line the part moves, light changes, and time is the cycle time.
Recognising the defect is the easy part; the bulk is capturing the right image at the right moment and deciding in time.
A model trained on a lab dataset does not know the real defects of your production.
If the decision arrives after cycle time, the part is already gone: the reject is useless.

What it really takes

Synchronised acquisition: The shot on the machine trigger (GPIO), not «now and then»: the image must be of the right part, in the right position.
Decision within cycle time: Pass/reject before the next part arrives. It is the constraint that dictates the whole architecture.
Automatic reject: The decision drives the actuator: a system that flags but does not reject is a dashboard, not quality control.
Model on real defects: Trained on that production’s defects — the rare ones too, via anomaly detection — not on generic images.

Where images and decision live

Production images tell what you make and how: not data you want leaving the plant.

On-premise, inside the factory perimeter: images never leave the plant.
No cloud dependency to decide: the line cannot stop because the connection dropped.
Single cameras or groups (grid, multiple views) for parts that must be seen from several sides.

Have a line where quality control is still spot-check or by eye? Let us see whether your cycle time and defects fit automatic inspection.

Let’s talk

Page updated 23 August 2026.