Machine Vision

AOI Programming: Golden Board and Algorithm-Based Methods

Programming-focused guide for AOI inspection recipes.

AOI programming defines what the inspection machine should accept, reject, measure, ignore, and report. A camera image alone does not know whether a product is good. The AOI recipe gives the machine rules for location, feature type, tolerance, defect threshold, and result handling. Poor programming can turn a good machine into a source of false alarms or missed defects.

Two common programming approaches are golden board teaching and algorithm-based generation. Both methods still require validation. Manufacturing variation is real, so a recipe must be tested against good samples, known defective samples, supplier variation, and process conditions before it can be trusted in production.

Golden Board Programming

Golden board programming uses a known good sample as the reference. The AOI captures images of this board or product and learns expected component positions, solder shapes, markings, edges, or features. This method can be practical because it starts from real visual data rather than only drawing data.

The risk is that one golden sample may not represent the full range of acceptable variation. If the sample is unusually clean, centred, or bright, normal production parts may be rejected. Engineers should use multiple good samples where possible and review tolerance settings carefully.

Algorithm-Based Programming

Algorithm-based programming uses product data such as CAD, Gerber, pick-and-place data, component libraries, or measurement data to generate inspection locations and rules. This can reduce setup time, especially for complex PCB assemblies. It also supports consistency between product models when data quality is good.

However, algorithm-based setup still needs real boards or parts for tuning. Data may not include actual lighting response, solder appearance, silkscreen variation, or component supplier differences. The generated recipe should be treated as a starting point, not a finished production program.

Validation and False Reject Control

Validation is the stage where programming becomes production-ready. Engineers should test the recipe using good samples, bad samples, borderline samples, and normal production variation. The goal is to reduce false accepts without creating excessive false rejects. A high false reject rate may cause operators to bypass the system or lose confidence in the AOI result.

False reject review should identify whether the issue is software tolerance, lighting, product presentation, sample variation, or real process drift. The main automated optical inspection article explains how AOI decisions feed production control.

Recipe Maintenance

AOI programming is not a one-time job. Recipes may need updates when components change, suppliers change, board revisions are released, lighting ages, fixtures wear, or production speed changes. Good maintenance includes recipe version control, password access, change records, and backup copies.

For Malaysian plants producing multiple models, recipe management is essential. Operators need clear model selection, and engineering teams need a controlled process for edits. Without this discipline, inspection results may vary between shifts or product versions.

Production Trial Before Release

Before a recipe is released, it should be trialled under real production conditions. Trial samples should include normal good products, known defects, borderline cases, and expected supplier variation. The test should run long enough to expose handling variation, lighting stability, machine warm-up effects, and operator interaction. A recipe that passes only a short engineering test may still become unstable during full-shift production.

Release criteria should be clear. The team should know the acceptable false reject rate, required defect detection rate, review process, and who can approve recipe changes. This prevents uncontrolled adjustment when the line is under pressure.

Recipe documentation should record why each major tolerance was selected. Without notes, later engineers may loosen or tighten limits without understanding the original defect risk. A simple change log with sample images, product revision, date, and approver can prevent confusion when quality issues are reviewed months later.

Operator Review Rules

Many AOI systems allow operators to review failed images. The review process should be controlled so judgement does not vary between shifts. Clear defect examples, reject categories, escalation rules, and limits on manual override help maintain inspection discipline. If repeated overrides are needed, the recipe should be investigated by engineering instead of being informally bypassed. This keeps AOI programming connected to real process capability. Review outcomes should also be logged so recurring judgement cases can be converted into better image tools, tolerance rules, or operator training material.