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.

Additional Considerations for This Build

Practical attention to AOI programming pays for itself here, because it decides whether the finished board behaves as the drawing intended. Where the requirement is not stated on the fabrication drawing or in the assembly notes, the shop has to assume a default, and that default is rarely the value the design was simulated with. Stating AOI programming explicitly, together with the tolerance that applies, removes the assumption and keeps the result predictable from batch to batch.

Checks Before Release

On a design of this kind, AOI programming is the item that decides how the rest of the board is arranged. 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. Sampling is a compromise between cost and confidence, and the sample size should follow from the failure rate that has to be detected.

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

On a design of this kind, AOI programming is the item that decides how the rest of the board is arranged. A change that is not recorded is a change that cannot be explained when the result moves, which is why the record is part of the process. Where the process window is narrow, the measurement resolution has to be better than the window, or the data cannot distinguish a good part from a marginal one.

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.

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.