Machine vision inspection software: rules, AI, and validation

If you are buying robot handling around an inspection process, evaluate the vision software against the quality decisions your team must make. The useful question is not whether rules or AI are more modern. It is whether the proposed method separates acceptable production variation from defects, at the required rate, with evidence you can review.

Define defects before choosing tools

Build a defect dictionary with quality and production staff. Give each condition a name, examples, a decision rule, and its operational consequence. Include legitimate variation that must pass. Resolve ambiguous samples before asking a supplier to train or tune a system.

Some decisions are naturally expressed as explicit measurements or counts; others involve appearance that is harder to describe with fixed limits. SICK Nova tool documentation provides separate code-reading and object-detection tools. Treat these as examples of distinct functions rather than expecting one generic “AI inspection” feature to answer every quality question.

The recognition-task guide helps separate identification from defect detection. A system that recognizes the correct product family has not necessarily established that the individual product is acceptable.

Protect an independent test set

Cognex guidance on training and testing image sets distinguishes training from testing image sets. Establish that separation in your purchasing plan. Keep a held-back set representing products, lots, and operating conditions the tuning team has not used to adjust the recipe. Record where every image came from.

Avoid filling the test set with nearly identical pictures of the same physical sample. A model may appear strong because the test resembles its tuning examples too closely. Instead, ask the supplier to explain how the sample selection reflects the variation your line is expected to encounter.

MVTec industrial anomaly detection benchmark includes test images under lighting conditions absent from training. That is a useful reminder to challenge the inspection beyond familiar images. For your factory, select relevant variations deliberately: permissible finish changes, different shifts, replaced light sources, or supplier changes. The actual test envelope should match the application rather than copy a public benchmark.

Report errors separately

Hypothetical example: a test contains many good parts and few defects. A high overall accuracy can conceal an unacceptable number of missed defects. Request counts by defect type and condition, with the sample totals visible, instead of accepting a single headline percentage.

Agree acceptance limits with the people responsible for product quality and business risk. Do not change a decision threshold simply to make the demonstration pass. Any threshold adjustment should be followed by the relevant regression tests and recorded as a recipe change.

Evaluate the inspection workflow

Have an intended user inspect uncertain results, compare images, and identify why a part was rejected. Ask whether the software exports images, measurement values, recipe versions, and decision records. Include storage capacity, retention rules, and access permissions in the quote.

For dimensional inspection, involve a measurement specialist and use our measurement-system selection guide. Classification confidence is not a substitute for a defensible dimensional result. The distinction should remain clear in reports sent to customers or quality staff.

Control changes and physical rejection

Specify who can edit thresholds, retrain models, or approve new product recipes. Maintain an approved version and a rollback method. Test computer replacement and restore from backup before the handover is complete, while supplier support is still available.

Finally, verify that the physical reject mechanism or robot disposition agrees with the inspection result. Include missing triggers, network delays, stopped conveyors, and restart behavior in a controlled test. A correct algorithm cannot compensate for a rejected product that is placed back into accepted output.

Attach these requirements to the integration and acceptance plan. Buy a quality decision process your team can operate and audit, with clear limits, rather than a software label.

If a FAIRINO robot will feed or sort for the inspection, define the handshake between the quality decision and the physical part. The pick-and-place application guide helps frame the transfer task; software acceptance must also verify that the correct item reaches the correct destination. Decide who owns tracking when several parts are in process.

Request a FAIRINO inspection-cell quote with your product families, decision categories, and destination layout. Include the inspection supplier’s requirements so robot handling and quality control are scoped together.