How to Cut AOI Changeover Time on High Mix SMT Lines

The next job is loaded, but the line is still waiting. Someone needs to confirm the board revision. The first panel produces calls that need review. The person allowed to release the job is finishing another task.

A short programming time can coexist with a long production changeover. To reduce the gap, measure the work between the last accepted board of the outgoing job and release of the incoming job. Then separate what needed the machine from what could have been ready before it stopped.

This guide focuses on the AOI portion of that handoff. It offers a practical worksheet, not a universal acceptance standard. Your quality plan still determines inspection coverage, required samples and release authority.

What should AOI changeover time include?

AOI changeover time should have an explicit start and finish, with preparation, machine setup, first board inspection and release recorded separately. Track AOI readiness alongside the wider production gap. That separation shows whether AOI is delaying the new job or waiting for something upstream, and prevents a programming demonstration from being mistaken for a complete line changeover.

Use three views of the same event:

1. Engineering effort. Record the hands on work needed to create, adapt or retrieve the inspection program. Work completed before the line stops belongs here too.
2. AOI readiness. Record when the outgoing job clears the station and when the correct incoming configuration is ready for its first board. Keep first board inspection and review as separate events.
3. Production release. Record when all required checks for the incoming job are complete and an authorized person permits the planned production run. Also record when production actually resumes.

These times answer different questions. Engineering effort matters for staffing. AOI readiness identifies local delays. Release and restart show whether the change helped production.

For a post reflow station, the first incoming board may not be available when the AOI program is ready. Record that arrival separately. Otherwise, waiting for upstream equipment can appear to be AOI setup work.

Agree on the start and finish events before comparing shifts or machines. Keep the same definitions when reporting improvements.

Which kind of job are you changing to?

Separate an unchanged repeat job, an engineering revision and a first build before deciding what must be done at AOI. They require different preparation and verification. Reusing a released program may be appropriate for a repeat job, while a changed assembly needs an impact review and a new design needs program creation plus the required qualification work.

A familiar product name is not enough to choose a program. An assembly revision, populated side or approved component alternative can change what the camera sees or what the inspection must decide.

Put those differences into the job record. If a repeat job requires programming from scratch, record why. The cause may be a missing released file, an uncontrolled revision or a genuine change in the product. Each calls for a different correction.

Do not multiply a new program creation saving by every product change. Repeat jobs may already use an existing program. That distinction matters both for staffing estimates and for any business case built from this worksheet.

What can be prepared before the current job ends?

Prepare the incoming job record, released files, reference material and review arrangements before the current run ends. Leave physical adjustments and machine access to the approved stopping procedure. The objective is to remove avoidable searching and decision making from the stopped period, while keeping the active job protected from edits intended for the next one.

Create a short job packet with:

• Assembly identifier, revision, populated side and panel arrangement.
• Released AOI program identifier and the location of its controlled copy.
• Approved changes since the previous run, including relevant component alternatives.
• A known conforming reference where required, with its identity and condition checked.
• Handling and support instructions appropriate to that assembly and machine.
• First board review requirements, reviewer, release owner and escalation contact.

Check that the operator can actually access the files and that the reviewer will be available. A folder path in an instruction does not help if the file is missing or access is restricted.

Keep draft and released programs separate. Preparing the next job should not alter the inspection configuration running the current one.

How should the first board be checked?

Check the incoming board against the approved assembly information and inspection requirements before releasing the job. Verify identity, handling, alignment, coverage and the disposition of reported calls. Record any program changes and repeat the affected checks. A clean screen alone is insufficient evidence, and this startup check does not replace qualification of a new or materially changed inspection configuration.

Use the following as a starting checklist for your own release procedure:

1. Match the job. Confirm the actual assembly revision, side and panel against the loaded program. Resolve discrepancies before continuing.
2. Check handling. Follow the equipment instructions for support, clearance and board transport. Do not make mechanical adjustments on running equipment to save time.
3. Check the image and alignment. Confirm that the expected board areas are captured and inspection locations align with the intended features.
4. Check coverage. Confirm that required locations and inspection types are enabled. An uninspected location cannot be treated as a pass.
5. Resolve the calls. Compare reported findings with the applicable acceptance requirements. Separate confirmed defects, acceptable variation and uncertain results.
6. Control changes. Document edits, preserve the prior released configuration and rerun affected checks. Use the qualification and regression checks required for the scope of the change.
7. Record the decision. Save the program version, board identity, review evidence and authorized release decision. Keep unresolved items visible.

The number and type of boards required depend on the product, change and quality plan. One first board cannot establish long term repeatability or demonstrate coverage of defects that are not present on that board.

If review identifies a genuine assembly defect, keep it in the quality process. Do not count accepting a defect or disabling a required check as a changeover improvement.

What if the first board produces too many calls?

When calls rise after a product change, establish whether they come from actual assembly defects, image or alignment problems, or acceptable appearance differences before changing inspection criteria. Confirm the loaded revision first. Correct the identified cause, then verify the affected inspection behavior. Reducing the displayed call count is not sufficient evidence that the new job is ready.

Start with the job identity and a sample of the reported locations. Are multiple calls displaced in the same direction? Does the actual fitted component match an approved alternative? Is the reference itself suitable for this revision? These questions help choose the next investigation without assuming every call is false.

Keep the initial call record and the final disposition. If several issues coexist, record them separately. A wrong program and a real solder defect can occur on the same board.

Avoid a broad threshold change as the default response to an unfamiliar board. A criterion that suppresses an acceptable appearance difference may also affect the response to a real defect. The extent of the change should determine the required verification.

For detailed troubleshooting, use our guide to AOI false call root causes and fixes. Here, the important handoff is clear ownership: who investigates, who approves a program change and who decides the job can resume.

Where does AI programming help?

AI programming can shorten creation of an inspection program for an incoming assembly. Its effect on a particular changeover depends on whether program creation is actually delaying that job. Repeat work with an existing released program, physical setup, first board review and production authorization remain separate activities. Measure the complete handoff before turning a programming result into a line productivity claim.

DaoAI-reported programming time is about five minutes from one reference board to running inspection. This describes a programming workflow, not the elapsed time from the last outgoing board to release of the next production job. The automatic processing step is also not the same measurement as the whole workflow.

For the mechanism, see AOI programming without CAD files. The DaoAI auto programming feature describes the product capability. Confirm its fit with your assemblies and required inspection coverage during an evaluation.

Ask for a demonstration that includes the handoff around the software. Bring the incoming assembly information and applicable acceptance requirements. Observe program creation, the first inspection, treatment of uncertain calls and the evidence needed for release. Record any work completed before the demonstration begins.

There can still be a useful engineering labor saving when total line restart time stays unchanged. Report the labor result as labor. Claim recovered production time only when the measured production gap becomes shorter under comparable conditions.

How do you find the delay worth fixing first?

Log event times and waiting reasons across several real changeovers, then compare jobs of the same type. Look for the activity that repeatedly prevents the next required step from starting. Prioritize that delay before optimizing work already completed in parallel. Keep engineering labor, AOI readiness and production restart results separate so overlapping improvements are not counted twice.

Copy this worksheet into a shift record. Fill it with observed times, not estimates taken from a brochure.

Record hands on minutes for each role alongside these events. Wall clock timestamps show elapsed time; several people working at once create overlapping labor intervals. Adding those intervals does not tell you how long the line was stopped.

Consider a changeover where AOI is ready before the first board arrives from reflow. Finishing that preparation earlier will not, by itself, make the board arrive sooner. If review is then delayed because the release owner is unavailable, arranging review coverage may matter more to restart time than further program acceleration.

Use the same reasoning when reporting improvements. A shorter program creation task and a shorter first board review may overlap other work. Check the final release and restart timestamps instead of adding every local saving together.

Review the log by repeat jobs, revisions and first builds. Choose one recurring cause, assign an owner and compare the next comparable jobs using the same start and finish definitions. Keep the required inspection and release criteria unchanged, or explicitly document why they changed.

Frequently asked questions

The right changeover target depends on the assembly, the incoming job type and the required release process. The questions below clarify the scope of the measurements in this guide. They do not set universal acceptance limits or authorize skipping qualification, inspection coverage or review steps in a plant's quality plan.

What is a good AOI changeover time?

There is no single duration that fits every assembly or factory. Establish a baseline for comparable repeat jobs, revisions and first builds, using consistent start and finish events. Set improvement targets against that baseline while preserving the required inspection and release criteria.

Does every product change require a new AOI program?

No. An unchanged repeat assembly may use an existing released program after the applicable identity and setup checks. A revision, approved component change or new assembly requires an impact review to determine the necessary program changes and verification.

Is offline programming the same as an offline AOI machine?

No. Offline programming means preparing an inspection program away from the production inspection task, where the system supports it. An offline AOI machine describes a station outside the conveyor line. One term describes a programming workflow; the other describes the equipment arrangement.

Does a five minute programming workflow mean a five minute line changeover?

No. DaoAI-reported programming time covers the path from a reference board to running inspection. It does not establish the duration of physical setup, upstream preparation, first board review, qualification or production authorization. Measure those activities separately.

Can a first board check replace AOI qualification?

No. A startup check confirms the incoming job against its release requirements. Qualification establishes evidence that the inspection configuration is suitable for its intended use. A first board check alone cannot demonstrate detection of defects absent from that board or establish long term repeatability.

For a DaoAI evaluation, bring representative assemblies, their revisions and the inspection requirements you need to meet. Use the worksheet to agree on what will be measured. Product information is available in the DaoAI brochure and specification downloads.