Testing & FAT

The principle: test before you commit

At some point you are going to stop the existing process and install this cell in its place. From that moment, every untested item is a delay with production standing still and everyone watching. The whole purpose of this stage is to shrink that list to as near zero as possible: test every individual element, then the system as a whole, while the old process is still running and nothing is at stake. Ensure every individual part works before making the decision to take the machine down. Keep the risk to a minimum.

In integrator language this is the FAT — the Factory Acceptance Test — performed at the builder's works before shipping. Building in-house doesn't excuse you from it; it just moves it to your own floor. Do it with the same formality an integrator would be held to: a written checklist, results recorded, faults logged and cleared, and a decision at the end that the cell has earned its installation date.

Test in layers, smallest first

Testing the whole cell at once tells you something is wrong but not what. Testing in layers means each test stands on proven foundations, and a failure points at the one thing that changed.

The safety validation comes first — and gets written down

Before anything else runs, validate the safety system you designed in Part 3 and calculated in Part 4. Every e-stop, pressed, one at a time, and confirmed to remove power the way the design says. Every gate interlock opened during motion. Every light curtain broken. Channel faults simulated — pull one channel of a dual-channel device and confirm the system detects it and prevents reset. Reset behaviour confirmed: nothing restarts on its own; restart requires the deliberate, supervised action your risk assessment demanded.

Record every one of these tests — device, test performed, expected result, actual result, pass, initials, date. This is not bureaucracy; ISO 13849-2 expects validation of the safety functions, and the record goes in the Technical File in Part 10. A safety circuit that has never been formally proven is a safety circuit that exists on faith.

Point-to-point I/O checkout

With the safety circuit proven, work through the I/O schedule from Part 5 and the mapping table from Part 6, line by line. Operate each real sensor and watch the signal arrive in the PLC and — where mapped — in the robot. Force each output and watch the real device respond. Tick each row. This is dull, methodical work that takes an afternoon, and it is the single highest-value afternoon of the project: nearly every "the program doesn't work" fault you would otherwise chase during commissioning is actually a transposed wire or a mis-mapped bit that this test catches for free.

Dry-run the robot and step the sequence

Run the robot program without product: reduced speed first, full cycle, watching approach clearances and confirming every handshake exchanges when it should. Provoke the exceptions deliberately — block the vacuum switch signal and confirm the program faults rather than waits forever; interrupt a search and confirm the failure path from Part 7 does what it should. On the PLC side, step the automatic sequence with forced inputs before the mechanics are connected, then again with them. The sequence you proved in pieces will still surprise you assembled — better here than installed.

No room to build the full cell? Test what matters

An integrator has a build hall; you may have a corner of a workshop. If you cannot assemble the full cell in its real geometry before installation, do not abandon the FAT — narrow it to the three things that kill commissioning weeks, all of which can be proven in a small space:

• Prove the communications end to end. Robot to PLC, however they talk — hardwired, fieldbus, or both. The full point-to-point checkout from the section above needs bench space, not floor space: panel, robot controller and a network cable will do. A proven, mapped, documented comms link is the foundation everything else stands on
• Prove the robot program with workshop-scaled positions. The program's logic — sequence, handshakes, searches, fault paths — does not care whether the pick position is where production says or two metres away on a bench. Teach temporary positions that fit the space you have and run the full cycle until the logic is proven. Because the program is built on base-frame offsets (Part 7), converting to real positions on site is re-teaching a handful of reference points, not re-proving the program
• Simulate the inputs you cannot generate. The conveyor that isn't connected, the upstream machine that's still in production — force or simulate their signals from the PLC and run the robot through every branch of the sequence: normal cycle, separator sheet call, pallet change, each fault path. The robot should have executed every routine it owns before it ever sees the real cell

Do those three properly and what remains for site is geometry and real product — the things that genuinely cannot be tested anywhere else — rather than logic, mapping and wiring faults that could have been caught on a bench. This is also where the plug-and-play architecture from Part 5 earns its keep: if the panels, looms and device groups were built and proven as units in the workshop, the move to site disturbs almost none of what you tested, and commissioning starts from a known-good electrical state instead of a re-terminated mystery.

The full-cell rehearsal

Now real product, full cycles, and deliberately hostile behaviour: e-stop mid-cycle and recover. Open a gate mid-cycle and recover. Jam the infeed and watch the fault handling. Run out of pallets, run out of separator sheets, kill the power mid-cycle and bring it back. Every recovery an operator will one day perform at 3am should be performed now, by you, with the answer written into the operating procedure. And put the operators on the controls before installation day — their first hour with the cell should not be its first hour in production, and they will find awkward things you have stopped being able to see. That is a gift, not a criticism.

The gate: does it install or not?

End the FAT with an honest decision against written criteria set in advance: safety validation complete and recorded, all I/O proven, target cycle achieved with real product, faults recovered cleanly, operators trained on basic recovery, snag list cleared. If the answer is yes, book the installation. If it is no, you have just saved yourself from discovering that in front of a stopped production line — which is the entire point of this part.

Common mistakes

• Testing only the happy path. Production is 95% happy path and 5% exceptions, and the exceptions are where cells die
• Safety validation done casually, or not recorded. Unrecorded validation does not exist as far as your Technical File is concerned
• Skipping point-to-point I/O checkout because "the electrician was careful". Everyone is careful; the test exists because careful people transpose wires too
• First operator contact with the cell happening in production week
• Installing with an open snag list on the promise of fixing it later. Later is now during production

Next in the series

Commissioning →

→