AI Visual Inspection and Computer Vision for Quality Control

Modern few-shot models often start with a few hundred images; the system keeps learning in production.

Industrial cameras and lighting are selected per application, and we deliver the complete engineered station.

New variants are trained quickly from existing models, which suits high-mix production.

On a correctly sized server inference runs in milliseconds and is rarely the constraint, though latency has to be budgeted per station when several cameras share one GPU. What decides the answer is the rest of the loop: the part has to be still and lit the same way at the trigger, and the reject decision has to arrive before the part reaches the divert point. If your index time leaves no room for that, the fix is mechanical; a faster model will not solve it.

Yes, retrofits are normal, but the work is mostly mechanical and electrical rather than software. You need a trigger signal from the PLC or a sensor, an actuator that can act on a reject, and a cabling run back to the inference server. Training the model is usually the shortest part of the project; making the part present itself to the camera the same way every cycle is what sets the schedule.

Anything the camera cannot see. Internal cracks, porosity below the surface, weld penetration, torque and material properties need a different modality. A better model will not see them. Vision also struggles where a defect has no consistent visual signature, where the acceptable range is a matter of human taste rather than a describable boundary, and where parts present themselves at unpredictable angles. Decide which failure modes you are actually chasing before specifying a station.

Once it is running, someone has to confirm or correct the classifications the system flags as unsure, and that feedback is what keeps the models current. It is a recurring load, though not a full role. Most of the effort lands earlier, in the first weeks, collecting representative images of good parts and of every defect class you care about. Nobody should own this on top of a full shift with no time allocated.

It gets it wrong in two directions, and you trade one against the other with the decision threshold. Tighten it and good parts are scrapped or re-inspected; loosen it and defects escape. Both need to be visible, so every decision is stored with its image, and the rejects should be audited against human judgement at a set interval. A station whose false rejects are never reviewed is one that operators will eventually learn to override.

Inference runs on the on-premise GPU vision server, so the real-time decision loop never leaves the plant. That is what keeps latency low enough for an inline reject. The stored images and operator corrections used to retrain are a separate question: if models are tuned by MSF on your data, settle in the contract whether those images stay on site. The rest of the platform can be deployed as SaaS, private cloud or on-premise.

It is diverted off the line and then dispositioned by whoever owns that decision: scrap, rework or concession. The result itself goes to MSF Quality, where it lands on the SPC charts and can raise a non-conformance record automatically. What is not automatic is the escalation when a defect class starts trending, so agree the disposition and escalation path before the camera is mounted.