AOI Programming: Design Rules and Process Limits
Automated optical inspection only earns its place if it finds the defects that matter without flooding the line with calls that are not defects. The difference between a useful program and an expensive one is almost entirely in the programming, and the work is done before the first production board is inspected.
What AOI Can and Cannot See
An optical system sees the surface. It sees the presence, position, rotation and appearance of a part, the shape of a fillet and the colour of a joint, and it can measure those features against a library.
It cannot see inside a package or under a ball. That is the boundary that decides which defects the program should be written to catch, and which belong to X ray or to electrical test. Our article on X ray versus AOI for area arrays sets out where the line falls.
Library Quality
Every part in the program needs a library entry with a good image, a defined search area and tolerance limits. A library built from a stock image for a similar part produces calls that no amount of tuning will remove.
The images should be taken from the actual part, and they should be taken from boards that have been produced on the line. A library built from a golden sample is a library that reflects one build rather than the process.
Setting Tolerance Windows
Each measurement has an upper and a lower limit, and the limits should come from the process capability rather than from the drawing alone. A limit set tighter than the machine can hold creates false calls at the rate the process varies.
The typical example is a chip component offset. The drawing may allow a shift that the machine holds easily, so the program should be set with a margin inside that, not at the edge. Our article on placement accuracy capability explains how the real variation is measured.
Reducing False Calls
False calls come from three sources: a library that does not match the part, a tolerance that is tighter than the process, or an imaging condition that varies across the board. All three are found by reviewing the calls rather than by raising the thresholds.
Sorting the calls by type and by location is the fastest way to find the cause. A single part that generates most of the calls is a library problem; a region that generates them is a lighting problem. Our article on PCB AOI guide covers the review workflow.
Coverage and Escapes
A program with no false calls and no findings is not a good program; it is an unverified one. Coverage has to be demonstrated with known defective samples, which is the reason the defect library and the challenge kit exist.
The challenge should be repeated after any change to the program, the machine or the product, because a small edit can silently disable a window without producing any error. Our article on first pass yield analysis describes how the results feed back into the line.
Programming for New Products
A new product should have the program built from the CAD data, the bill of materials and the actual samples, and the first article should be inspected with the program before it is released. Programming from the assembly drawing alone misses the parts that the drawing shows but the machine cannot see.
The first article review should record which defects were deliberately excluded and why. That record is what allows a later escape to be assessed as a programming decision or as a process failure.
Maintenance of the Program
Programs drift as libraries are edited and tolerances are tuned, and the record of those edits is the only way to understand a change in call rate. The revision should be controlled in the same way as any other process document.
A periodic review of the call rate and the defect found rate by type keeps the program honest and shows where the next improvement is worth making.
Checks Before Release
Where a decision is made by judgement, a boundary sample makes the judgement repeatable between operators and between shifts. Where a process is at the edge of its capability, the margin should be bought deliberately rather than discovered during production.
A record that identifies the operator, the date and the settings is worth more than a record that identifies only the result. A measurement taken at the wrong point of the process describes the wrong thing, however carefully it is made.
Where the supplier and the user both measure the same property, they should agree on the method before the first delivery. A parameter that is set once and never re verified drifts, and the drift is usually discovered by a defect rather than by the record.
The first article confirms that the setup matches the intent, and it is the cheapest point at which a wrong setup can still be corrected.
Points to Confirm at First Article
The cost of verification is small compared with the cost of a field failure, and it is paid at a point where the product can still be corrected. The tooling, the material and the profile form one system, and a change to any of them should be assessed against the other two before it is released.
Verification and Records
The checks that matter are the ones performed on the product rather than on a sample kept for the purpose, because a coupon that travels with the panel is the only evidence about that panel. Where a requirement can be measured, it should be measured at the point of manufacture and recorded against the board or the lot it applies to.
FAQ
How many false calls are acceptable? The level depends on the line, but the target should be low enough that operators still investigate every call. A program with a high false call rate is one that is being ignored.
Can AOI replace visual inspection? For the features it can see, yes, and more consistently. The operator is still needed for the joints and packages that the camera cannot reach.
Should the program be tuned at the machine? Minor tuning is normal, but the change should be recorded and the revision updated. Tuning without a record is how a working program slowly stops working.
