Publish Time: 2026-10-29 Origin: Site
Most disputes about inspection equipment happen after installation, and almost all of them could have been settled before shipment. Factory acceptance testing and site acceptance testing exist to move the argument earlier, when there is still room to fix something. The distinction is simple: FAT proves the machine does what the supplier said it does, on your boards, in the supplier's facility; SAT proves it does the same thing once it is installed in your line, wired to your equipment, running your product. This article gives you a working checklist for both, written for SMT inspection equipment specifically, and explains what to bring, what to measure, how to decide whether the result is acceptable, and how to close issues so they do not follow you into production.
Acceptance is not a formality and it is not a demonstration. It is a test against criteria agreed before anyone starts measuring.
FAT answers: does this machine, in the configuration we bought, meet the agreed capability on our own boards? SAT answers: does it meet the same criteria here, connected to our line, operators, network, and utilities, at our takt? The first is about the machine; the second is about the installation. Conflating them produces a FAT that skips hard cases and an SAT that discovers problems nobody can fix quickly.
If the acceptance criteria are not written down before the test, each side will supply its own afterwards. A criterion stated as "detects the defects we care about" is not testable; a criterion stated as "detects this defined defect library on these boards, with false calls below an agreed limit, repeatably across repeated runs" is. Spend the effort early, because this document decides every later conversation.
A usable acceptance document lists the machine configuration, the board set including which defects each board carries, the defect library and its expected detection outcome, the measurement plan including repeat runs, the false call allowance, the data export requirements, the integration checks, and the sign-off conditions. Everything in this article maps onto one of those elements.
FAT should include the process engineer who owns the defect classes, the quality engineer who owns the acceptance standard, and whoever will program and maintain the machine later. SAT should add maintenance, IT or network ownership, and the line supervisor. Acceptance done without the people who will live with the machine tends to miss exactly what they would have caught.
FAT typically happens before shipment and after the machine is substantially complete and programmed; SAT happens after installation and before the line returns to production billing. Both need time in the schedule, including time to re-test after issue closure. Projects that treat acceptance as a single afternoon usually convert it into several weeks of ad hoc visits.
Acceptance is the last step of equipment selection, not an isolated exercise. The selection framework and evaluation criteria are covered in our guide on how to choose SMT inspection equipment, and the checklist below assumes you already know which defects each candidate machine must find, as set out in our article on matching SMT inspection methods to defect risks.
Preparation determines whether the FAT produces evidence or opinions. Most weak acceptance tests fail here, before a single board is inspected.
Bring boards that represent your actual product mix rather than convenient demo boards: fine-pitch devices, area array packages if you have them, your most difficult board rather than your easiest, and ideally a board that has historically given you trouble. Include both sides if you run double-sided product. A machine validated only on easy boards has not been validated. If you are accepting more than one machine family, plan a separate board set and defect library for each, because a 3D SPI such as the S400, an inline AOI such as the AI-5146, and a first article inspection machine such as the FAI1095 have almost nothing in common beyond board handling, and one library cannot serve all three.
Collect or build samples carrying the defects you actually need detected: insufficient and excessive solder deposit, misregistration, missing components, wrong orientation, wrong value or wrong part, bridging, insufficient fillet, voids under array packages, and any product-specific defect you have struggled with. Label them, photograph them, and record what each one is, because during the test nobody will remember which board was which.
For every sample, agree in advance whether detection means flagged at all, flagged in the right location, flagged with the right defect class, or measured within defined limits. A machine that raises an alarm somewhere on the board is not the same as one that says which joint is bad and why. Write the required level per defect.
Every detection capability trades against false calls. Agree an allowance that reflects what your operators can absorb, expressed against your known-good boards, and test it on those boards under realistic conditions including boards that have already been through handling, printing variance, and reflow. False calls discovered in production are far more expensive than limits negotiated before shipment.
State how many boards, how many repeats, and under what conditions. Repeat runs over several cycles, separated by warm-up and re-loads, reveal instability that a single pass hides. Include a run after the machine has been powered down and restarted, because that is what happens every weekend in your factory.
Agree before arrival which programs, fixtures, samples, reference boards, calibration artefacts, power, network access, and consumables each side provides. The most common cause of a wasted FAT day is discovering at the door that neither party brought the boards.
Agree an agenda before travelling: which checks happen on which day, in what order, and how long the whole exercise takes. Sequence matters, because configuration verification and board handling must pass before detection results mean anything, and because re-running a test is expensive once the room has been released. Build slack into the schedule for tuning and for the disagreements that surface when real numbers appear, and agree in advance what happens to the schedule if an item fails.
This is the core of factory acceptance: can the machine see what you need it to see, consistently, on your boards.
Confirm that the machine in front of you is the machine you bought: model and configuration, camera or sensor specification, lighting configuration, conveyor width and board size capability, software version and modules licensed, and any options specified in the order. Check it against the purchase document, not against memory.
Run boards through repeatedly, including your largest, smallest, thinnest, and heaviest formats. Check loading, clamping, transport smoothness, board stop accuracy, and that no board is skewed, scratched, or jammed. Accept that this sounds mundane; handling faults produce more downtime later than detection disputes do.
Run the full library and record results sample by sample, defect by defect, against the criteria agreed in advance. Where a defect is missed, capture the image immediately with the defect still identifiable. Aggregate results hide individual failures, and you want the record per defect rather than a headline percentage.
Run a batch of known-good boards, including some with legitimate process variation, and record every call. Sort calls into real defects, borderline cases, and false calls, and check the totals against the agreed allowance. This is also the best time to tune tolerances with the supplier's application engineer present, which is much easier than doing it remotely later.
Repeat the same boards several times over multiple cycles and across a restart. Record whether results are stable. Instability here predicts drift in production, where nobody has time to investigate it. Because AOI and X-ray judgement is statistical rather than binary, repeatability matters more than any single pass result.
Time real cycles with your boards and your programs, including load, transport, inspection, and unload, repeated enough times to be meaningful. Compare the result against your takt rather than against a brochure. If the machine cannot hold your takt, that is discovered now or during your first production week, and the first option is far cheaper.
Deliberately trigger the conditions you will actually meet: a mis-loaded board, a board that fails, a network interruption mid-run, an emergency stop, a power cut. Observe how the machine recovers, whether queues are preserved, whether data written so far survives, and whether restart is clean. A machine that loses its record of inspected boards on a network hiccup will lose trust fast.
Confirm guarding, interlocks, emergency stop circuits, labelling, and any laser or radiation classification relevant to the machine type, and check the documentation that supports them. Ask specifically about interlocks that are temporarily bypassed during demonstration, and verify the machine is presented in the state it will be delivered in. A safety finding raised after handover is both expensive and, in many jurisdictions, a question nobody wants asked.
Capability is half the story. The other half is whether your team can run it, program it for new products, and trust the result on a Monday morning.
Have the supplier build a program for one of your real products with your team watching and doing as much of the work as possible. Time how long it takes and note which steps require specialist knowledge. Program creation time is a recurring cost for every new product, and it is invisible until you have to do it yourself.
Check how program revisions are stored, identified, and recalled, and whether an old revision can be loaded by mistake. Confirm that results can be traced to the program version that produced them. This matters most during audits and escape investigations, which is exactly when nobody wants ambiguity.
Walk through what an operator actually does: start of shift checks, loading and re-authentication, reviewing results, handling a fail, clearing an alarm, and end of shift. Watch whether any of these steps require undocumented knowledge. Then have somebody who has never seen the machine try it with only the documentation, because that is what will happen on your night shift.
Confirm how tolerances are set, how they are documented, and whether a library can be reused across similar products. Ask difficult questions about how much of the tuning is art and how much is procedure. A machine whose performance depends on one person's intuition is a risk you should identify now.
Ask how program limits relate to the acceptance criteria your product is judged against, and ask the supplier to show where that mapping lives in the software. Industry references such as IPC-A-610 for assembled board acceptability and J-STD-001 for soldering requirements, published by IPC, are commonly used as the reference frame for those limits, without inventing values of your own. What matters at acceptance is that every limit in the program can be traced to something written down, because the first serious customer question about a rejected joint will ask exactly that.
Have the supplier generate the reports you intend to use daily, weekly, and monthly, with your defect taxonomy, and confirm they are readable and exportable. Reporting configured during acceptance works; reporting configured six months later usually does not happen at all.
Inspection equipment is a data source as much as a machine. Confirming that before shipment avoids discovering later that it cannot talk to anything you own.
Check exactly what each result record contains: board or panel identifier, job, program version, machine, time, defect class, location, and severity. Confirm the identifier format matches what your systems expect. A record without a usable identifier cannot support traceability no matter how good the detection is.
Verify the export mechanisms actually available on the machine you are buying, the formats produced, and whether export is automatic or manual. Test an export during FAT and open the file in your environment. Promised interfaces and working interfaces are not the same thing, and the difference usually appears during integration rather than acceptance.
For inline configurations, confirm the handshake behaviour, how a fail is signalled downstream, and how the machine behaves when a neighbour blocks. If your layout uses buffers or routing decisions, verify those during SAT at the latest, and during FAT if the supplier can simulate them. Compatibility with your existing line is covered further in our article on inline versus offline SMT inspection equipment.
Check user roles, password policies, and whether actions such as tolerance changes, program edits, and result deletions are recorded. In regulated or customer-audited environments, an untraceable tolerance change during a production crisis is a serious finding. Confirm the audit trail exists before the machine is on your floor.
Confirm what is backed up, how often, where it is stored, and how a restore is performed. Test a restore. Then confirm the machine continues to operate if your network or server is unavailable, and what it does with results generated during the outage. This is the scenario you will eventually meet, usually at the worst moment.
Confirm interface language options, units, date and time formats, and time zone handling. These are small items that produce confusing records when wrong, and they are much cheaper to settle during acceptance than to explain later to an auditor.
Confirm who else will consume the results. Quality reporting, traceability systems, and any higher level analytics you run all depend on the machine producing records in a form they accept. Bring the real consumer specification to the acceptance rather than assuming a generic export will satisfy it, and test one downstream system end to end while both engineering teams are in the same room.
A FAT that ends with a verbal "looks good" is a FAT that did not close anything. The output should be a written record.
Produce a table listing each acceptance item, the criterion, the measured or observed outcome, and pass or fail. Include the defect-by-defect detection table and the false call counts. Both parties sign it. This document is what governs everything that follows, including what happens if the machine does not meet the criteria after installation.
Not every finding has the same weight. Sort exceptions into three classes: blocking, meaning shipment or payment should not proceed; rectifiable before shipment; and accepted with a documented workaround and a fix deadline. Writing the class next to each item prevents the later argument about whether a known issue was agreed or ignored.
Every open item needs a named owner on the supplier side and on your side, a date, and a verification method. Open items without dates become permanent. Put them in the same document as the acceptance record so they cannot be separated.
For items fixed before shipment, agree whether they are re-tested at FAT or deferred to SAT, and what evidence closes them. Deferring everything to SAT is convenient for everyone except you, because problems discovered at your site are always slower to fix than problems discovered at the supplier's.
Agree what must be true before the machine ships: open item status, packing method, documentation included, spare parts included, and who is responsible for transport insurance. Also agree when commissioning starts and what access the technician will need at your site.
Take your boards and samples back, and keep them. They become the reference standard for SAT, for future program changes, and for diagnosing disputes later. Consider keeping image captures too, so you can compare future performance against the acceptance baseline.
Site acceptance begins before anyone turns the machine on. Most installation failures are facility failures, not machine failures.
Walk the site against the supplier's site preparation requirements: floor loading and levelness, clearances for doors and corridors along the delivery route, power rating and connector type, compressed air where required, network drops, extraction or cooling requirements, and lighting. Confirm any X-ray licensing, safety interlock, or shielding obligations applicable to your location are understood and arranged. Give the X-ray systems such as the X-7100 particular attention here, because the facility requirements of a radiation source are site items rather than machine options, and they cannot be improvised after delivery.
During installation, verify mechanical levelling, anchoring, conveyor interface heights and alignment, cable routing that cannot be damaged, emergency stop circuits functioning, guarding in place, and safety interlocks tested. Do not accept shortcuts on guarding: an installation that passes commissioning with interlocks bypassed will run that way.
Verify voltage stability, air supply, and network behaviour over a sustained run rather than a short test. Check ambient conditions against machine requirements. Many intermittent faults trace back to a supply that is marginal only when everything else in the factory is running.
Run boards through from upstream to downstream equipment and confirm the handshakes, routing, and queue behaviour work together rather than individually. Test failure routing end to end, including what happens when the next station is busy or stopped. Integration problems appear at the interfaces, which is why each one should be exercised on the real line.
Verify that the machine delivered matches what was accepted: model, configuration, options, software version, and calibration state. It is unusual for this to be wrong, but it is cheap to check and expensive to discover after acceptance has been signed.
Agree how software versions, program changes, and configuration settings are controlled after handover, and who approves each type of change. Include the supplier's remote access: who has it, how it is enabled, and how it is logged. Uncontrolled changes made during a production problem are the most common reason that a machine which passed acceptance drifts away from its validated performance.
The final stage proves the machine works in your process, with your people, at your pace, and leaves you able to run it without assistance.
Re-run the core acceptance measurements here: the defect library, the known-good boards for false calls, and repeatability. Results should match FAT within agreed limits. Differences indicate installation or environment effects, and this is the right moment to find them rather than after sign-off.
Run at the takt the line actually needs, with real product, for a sustained period. Watch for queueing upstream, operators waiting, and any station becoming the bottleneck. Throughput problems only appear under sustained load, which is why a short demonstration run is not evidence.
Train everyone who will touch the machine, across all shifts, not just the day shift team present during commissioning. Cover routine operation, program recall, result review, alarm handling, and what to do when results look wrong. Have each person run a set of boards unaided and record that they did. Competence should be demonstrated, not assumed.
Train maintenance on consumables, cleaning, calibration routines, and diagnostics. Confirm the spare parts list, what is included, delivery lead times for what is not, and which failures require supplier intervention. Agree the escalation path and expected response in writing while everyone is still on site.
Collect everything at handover: manuals, electrical and pneumatic drawings, spare parts catalogue, calibration procedures and certificates where applicable, safety documentation, software licences, administrator credentials, warranty terms, and the signed acceptance records. Confirm that credentials are handed over in usable form, because locked-out administrators discovered months later are a common and avoidable problem.
Define what will be monitored after handover: false call rates, detection of known defect classes, throughput, availability, and how often results are reviewed against the acceptance baseline. Agree a review point some weeks after production start, when real conditions have settled and any drift becomes visible.
A strong acceptance package contains: written criteria agreed before testing, per-defect detection results, false call counts on known-good boards, repeatability data, measured cycle time, integration evidence, operator and maintenance competency records, dated action items with owners, and signed acceptance documents. Assemble it once and keep it with the machine file. If you are preparing acceptance for a new line, the range of vision inspection equipment and the AOI inspection solutions from I.C.T cover the machine families described here, and our article on planning inspection positions in the SMT line helps define where accepted equipment will sit once it arrives.
FAT verifies that the machine, in the configuration purchased, meets agreed criteria on your boards in the supplier's facility. SAT verifies the same criteria are met after installation in your line, connected to your equipment, utilities, network, and operators. One tests the machine, the other tests the installation.
Your own boards, representing your real product mix including difficult boards and real defects. Demonstration boards prove the demonstration works; your boards prove your product will be inspected correctly, which is the only thing that matters once production starts.
Agree an allowance before testing, expressed against your known-good boards, then run those boards and count. Sorting calls into real defects, borderline cases, and false calls during acceptance lets you tune tolerances with the supplier's application engineer present, which is far easier than doing it remotely later.
For FAT, the process engineer who owns the defect classes, the quality engineer who owns the acceptance standard, and whoever will program and maintain the machine. For SAT, add maintenance, network ownership, and the line supervisor who will run it daily.
Record it as an exception, classify it as blocking, rectifiable before shipment, or accepted with a documented workaround and a fix deadline, then assign an owner, a date, and a verification method. Open items without dates tend to become permanent.
Repeat the core measurements: the defect library detection results, false call counts on known-good boards, and repeatability. Differences between FAT and SAT results indicate installation or environment effects, and identifying them before sign-off is far easier than afterwards.
content is empty!