We changed how we run factory acceptance testing. On a recent conveyor and robotic pick cell, FAT stopped being a sign-off step and became the place where we proved the whole system worked before it left our shop.
On a lot of automation projects, FAT is a milestone. Wiring is verified. IO is checked. Paperwork is signed. Equipment ships. That can satisfy the contract, but it pushes real system validation to the plant floor, where time is short and every surprise costs more.
On this project, we built a dedicated soft PLC environment for debugging and validation instead of relying on manual wire tracing or waiting until installation for real integration testing. The goal was to prove the system as a system before it shipped.
What does a traditional FAT miss?
A traditional FAT checks components one at a time. Does the motor turn? Does the sensor change state? Does the valve actuate? Those checks are necessary, but they’re usually done in isolation.
Common methods include:
- Manual wire tracing from field devices to terminal blocks
- LED-based IO checks at drives and modules
- Limited functional testing without full system context
- Little or no exercise of real operating sequences
That leaves gaps. Integration problems are harder to spot. Labeling or routing errors can slip through. Network configuration problems tend to show up late. When those issues turn up during installation, they mean extended debugging and rework under schedule pressure.
We wanted to know two things: that every component worked, and that the whole system behaved the way it was supposed to.
What were we testing?
The system under test was a robotic pick cell handling totes with multiple layers of small parts. The process included accumulation conveyors, right-angle transfers, motor-driven rollers, pneumatic stops, and precise tote positioning so the robot could pick consistently.
Everything in the cell depended on everything else. Zone timing, stop sequencing, and how a tote physically settled against a hard stop all affected whether the robot could do its job.
So instead of asking only “Are the wires correct?”, we asked “Does the cell run correctly as a whole?” That question drove every technical decision that followed.
How did we build the soft PLC for FAT?
We didn’t wait for a full production controls build, and we didn’t rig temporary test wiring. We set up a soft PLC environment specifically for FAT debugging and validation.
The foundation was an industrial PC running a soft PLC. That gave us flexibility right away:
- No dependency on a fixed hardware PLC platform
- License-based fieldbus support instead of hardware-based limits
- The ability to scale Ethernet/IP, EtherCAT, and IO as needed
- Built-in visualization without additional HMI hardware
Motor controllers and valve manifolds communicated over Ethernet/IP. Internal cabinet IO ran over EtherCAT. Every signal came into one control environment that closely reflected how the real system would behave, so issues showed up early and in context.
This environment was intentionally not production code. Its job was to validate hardware, wiring, sequencing, and integration logic. Alarms, long-term operation, and data reporting were out of scope.
Why use web-based visualization instead of a full HMI?
The soft PLC environment had web-based visualization built in, and that saved us from building a full HMI project just for testing.
With lightweight screens, we could:
- Run IO checks quickly and clearly
- Toggle inputs and watch outputs in real time
- Run simple functional sequences
- Confirm pneumatic and mechanical responses
Engineers and technicians could see what the system was doing immediately, without working through complex screens or waiting on more development. For FAT, that was the right level of visibility.
What did testing the whole cell catch?
With the soft PLC in place, we brought the entire cell to life.
Motor-driven rollers advanced totes through accumulation zones. Right-angle transfers engaged and retracted. Pneumatic bin stops protected the pick position from unintended operator interaction. Crowding logic drove totes into hard stops to set a consistent zero-zero reference for robotic picking.
Because every device was connected and active, we could check behavior that a traditional FAT usually misses:
- Timing between conveyor zones
- How the mechanical hard stops and the drive logic worked together
- Pneumatic sequencing under realistic control conditions
- Network communication across multiple device types
Testing at that level caught integration issues before shipment, when fixing them was fast and low-risk.
How did 24V controls help?
The system was designed around 24V controls, both in the field and inside the panels. That made hands-on testing during FAT practical, without the extra precautions that come with higher-voltage motor systems.
Engineers and technicians could trigger sequences, watch the response, and try again quickly. When testing is that easy to repeat, people test more.
Where did AI tools fit in?
After the recorded FAT interview, we used AI-assisted development tools, including Claude Code, to speed up writing the temporary soft PLC logic. The tools handled repetitive work like IO mapping scaffolding, basic test routines, and standard logic structures. Engineers reviewed and refined everything the tools produced against the system requirements and our internal engineering practices.
We used AI selectively. Engineering judgment stayed with the engineers. The tools cut the time spent on boilerplate, which left more time for system behavior, edge cases, and integration details.
The result was a purpose-built debug environment that came together faster than it would have the traditional way.
Is this a replacement for production controls?
No. This approach had one job: FAT debugging and validation. It doesn’t replace production PLC platforms, validated safety logic, or established commissioning practices. Production systems still need careful design, review, and testing.
Controls engineering is cautious for good reason, and this approach respects that. We used newer tools in a low-risk, non-production setting to validate earlier, without giving up engineering oversight.
What it gives you is a bridge between component-level checks and full commissioning. Integration risks show up earlier, when changes are cheaper and faster to make.
What changed after FAT?
The results on this project:
- Manual wire tracing and LED-based IO checks were mostly avoided
- Integration issues were found earlier in the project
- FAT time went to real system behavior instead of point-to-point checks
- Installation and commissioning went more smoothly and predictably
The customer received equipment that behaved consistently from day one, and the move from FAT to installation was more efficient and far less disruptive.
What we hold ourselves to now
A FAT run as a checkbox only tells you the checkboxes are filled in. A FAT run as a proving ground tells you whether the system works.
Every Direct Conveyors standard unit is pre-assembled and tested before it ships. This project pushed the same idea to the system level: the entire cell runs, as a cell, in our building. When that happens, equipment shows up at the customer’s site doing what it’s supposed to do, and rework stays in our shop where it belongs.
Have an integration project coming up?
If you have a conveyor or automation cell where robots, stops, transfers, and controls all have to work together, tell us about the application. We want to understand the process before we recommend anything.
If you’re looking at standard conveyors for part of the line, you can build one in the Configurador de transportadores directos and request a quote.
