A Practical AOI Programming Strategy for SMT Inspection

An AOI machine does not find defects by itself; it finds what its program tells it to look for. That makes programming the single most important engineering task on an automated inspection line. A well built program catches real defects at a reasonable false call rate, while a poorly built one either misses defects or buries the operators in noise. This guide describes the programming approach used at gopcb and the decisions that make it work in volume production.

What an AOI Program Actually Does

The program defines where the machine looks, what it compares against, and which differences count as defects. For each component it stores a position, a polarity, a set of inspection windows and a lighting recipe. At run time the machine captures an image, applies the recipe and reports any deviation that exceeds the limits the programmer set.

Everything the machine does is therefore a consequence of earlier decisions. If the inspection window is too tight, good boards are rejected; if it is too loose, defects pass. Programming is not a data entry task, it is an engineering judgement about which variations matter and which are simply normal process spread.

<img src="https://www.gopcba.com/wp-content/uploads/2024/10/vektornyj_smart-obekt1.webp" alt="AOI programming station reviewing inspection images on an SMT line” />

Starting from CAD and Library Models

Programming begins with the CAD data and the bill of materials, which give the machine a map of every component, its location and its orientation. From that data the software generates an initial program using a library model for each package type. The library holds the expected shape, the pin pattern, the polarity marking and the default lighting.

A good library is the foundation of a good program. When a package is modelled correctly once, every board that uses it inherits that knowledge. When it is modelled badly, the error is copied to every product. Building and reviewing the library before writing product programs is the highest return investment in the whole process.

Setting Inspection Windows and Tolerances

Each inspection item needs a window. Solder fillet checks need a band around the toe and heel, polarity checks need a region where the marking should appear, and presence checks need an area that should contain the body of the part. The size of those windows is a trade-off between sensitivity and stability.

Tolerances then decide how much variation is acceptable inside the window. Displacement of a chip component by a tenth of a millimetre may be perfectly normal, while rotation of a polarised part is not. Tolerances should be derived from the process capability of the placement machine, not from the tightest value the software will accept.

Lighting and Camera Setup Per Package Type

Lighting decides whether a feature is visible at all. A solder fillet that looks solid under one combination of angles may look broken under another, and a dark package on a dark board may have no contrast with a bright background. Most machines offer several colours and angles, and the right recipe is package specific.

Camera resolution and field of view follow the same logic. Fine pitch parts need enough pixels per pin to detect a bridge, which usually means a smaller field of view and more images per board. The trade-off is cycle time, and it should be resolved in favour of the parts where a missed defect would be expensive.

Teaching Good Boards and Golden Samples

After the initial program is generated, the machine is taught with real boards. A golden sample shows the correct appearance of every joint, and the program is tuned until that sample passes cleanly. Several samples from different production times should be used, because a program tuned to one perfect board will reject normal variation.

Teaching should also include known bad boards wherever they exist. A sample with a lifted lead, a tombstoned part or a missing component proves that the program can detect the defects it claims to detect. Without that proof, a low defect count may simply mean the program is blind.

Reducing False Calls Without Losing Defects

False calls are the tax on inspection sensitivity. Every call costs operator time, and a high rate eventually persuades the team to relax the program until real defects escape. The right target is a program that catches the defects that matter at a rate the line can handle, and that target is a business decision as much as a technical one. A sound inspection strategy starts by listing the defects that must never escape, then tunes sensitivity to catch those first.

Reducing false calls starts with root cause. Many calls come from a few specific items, such as a shiny connector body or a dark marking on a dark package. Adjusting the lighting, resizing the window or changing the reference image for those items often removes most of the noise. The wider topic is covered in our AOI process guide.

Debugging and Optimising the Program

Debugging is an iterative loop: run a batch, review the calls, decide whether each call is real, and correct the program where it is not. The review must be done by someone who understands both the process and the product, because the decision to accept a call as normal variation is a technical judgement with real consequences.

Optimisation continues after the program is stable. Rearranging inspection sequence, reducing redundant checks and consolidating lighting recipes can shorten cycle time without weakening coverage. Where an optical method cannot see the joint at all, the answer is a different technology, as explained in our comparison of X-ray and AOI.

Change Control When the Product Changes

A program is valid only for the revision it was built for. When a component changes supplier, when a pad is redesigned or when a second source part appears with a different marking, the program must be reviewed and re-released. Allowing production to run with an unreviewed change is the most common way a good program becomes unreliable.

Change control should be formal. The program version, the product revision and the approval should be recorded, and any engineering change should trigger a re-teach of the affected items. This discipline matches the traceability expected across the rest of the production process flow.

Measuring Program Performance Over Time

Two numbers describe a program: the escape rate and the false call rate. The first is measured by how many defects reach the next process step, usually found by functional test or by customer returns. The second is measured directly by the number of calls the operator rejects as good product.

Both numbers should be tracked per product and per shift. A rising escape rate suggests the program has been relaxed too far, while a rising false call rate suggests a process shift, a lighting drift or a software change. Tracking them together keeps the inspection step honest and makes it a genuine control rather than a formality.

FAQ

How long does it take to write an AOI program? A straightforward single sided assembly can be programmed and debugged in a few hours if the library is already built. A dense double sided board with many package types and tight inspection windows can take several days of tuning before the false call rate settles.

Should the AOI programmer follow the process engineer or the test engineer? In practice the programmer needs input from both. Placement data and process capability come from the process team, while the defect priorities come from test and field data. The program is a compromise between what the machine can see and what the product actually needs.

Can AOI replace functional testing? No. AOI verifies appearance, not electrical behaviour, so it cannot prove that a joint conducts or that a component is within tolerance. It reduces the load on later test steps, but the electrical proof still has to come from inspection of the assembled board and from functional test.