You can test PLC logic without a PLC by running the program on a scan-accurate simulator, forcing inputs the way a technician would, watching every output and tag change, and saving a timestamped log of the run. That bench test finds the logic errors that usually surface at FAT, before anybody books time in the panel shop. LADX Monitor does exactly this. It will not find a wiring fault or a wrong device, and it is evidence for a FAT, not a replacement for one.
The gap between writing logic and standing at the panel
On many projects there is nothing between the last edit in the editor and the first power-up of the panel. The program compiles, the engineer reads it twice, and the first time it actually runs is on the real controller, often with the customer watching the FAT. Every logic bug found there costs more than it would have at a desk, because now it competes with wiring checks, I/O ring-out and a room full of people.
LADX built Monitor for that gap: take any saved program, run it at scan speed, force the inputs and watch the tags change, as a bench test you can do before anybody books the panel shop (LADX Monitor).
Why the simulator must be scan-accurate
A PLC repeats four steps: copy the inputs into memory, solve the program top to bottom, write the output image, do housekeeping. On a modern controller that loop takes one to twenty milliseconds (LADX, PLC scan cycle explained). Three bugs come straight out of that loop, and a simulator that solves rungs like equations will hide all three:
- A pulse shorter than one scan is invisible. If a sensor flicks on and off mid-scan, the program never sees it.
- Outputs do not change mid-scan. The physical terminal updates when the whole output image is written.
- Rung order decides what sees what. A coil on rung 12 is visible to rung 13 in the same scan, but rung 4 sees it only on the next scan.
LADX Monitor runs the same engine as the LADX Ladder editor: the same output image, the same edge memory per instruction, the same timers on elapsed milliseconds. That matters because a test passed on a different model of the logic proves less. The underlying languages are defined by IEC 61131-3, revised as edition 4.0 in 2025 (IEC 61131-3:2025).
How to run a bench test, step by step
- Write the test cases from the functional spec before you open the simulator. Each one is a starting state, an action and an expected result.
- Load the saved program. Check the outputs list first, because outputs are what the test is judged on.
- Run the normal sequence: start, run, stop. Use momentary inputs as momentary. A start button that is held down is a different test.
- Run the abnormal cases: stop during start, guard opened mid-cycle, a sensor that drops out, an analog value parked on a limit.
- Read back the timestamped log rather than relying on what you saw. Sequences are easy to misremember.
- Save the run against the project, so it can be attached to the FAT pack instead of being described in a meeting.
| Test case | Force | Expected result |
|---|---|---|
| Conveyor start | Start pressed, guard closed | Motor latches, run lamp on |
| Stop always wins | Start held, stop pressed | Motor off, does not restart |
| Guard interlock | Guard opened while running | Motor off, fault latched |
| Reset after fault | Guard closed, reset pressed | Fault clears, motor stays off |
| Jam timer | Photo-eye blocked for 5 s | Jam alarm after preset |
What a bench test finds, and what it never will
LADX is direct about this, and so are we. A bench test proves the logic does what the logic says. It finds missing seal-in stop conditions, timers that never reset, outputs written twice, interlocks that release too early and sequences that hang. Those are most of what gets found at a FAT.
It cannot know the encoder is wired backwards, the proximity switch is PNP when the card expects NPN, or the panel misses a requirement of NFPA 79, the U.S. electrical standard for industrial machinery (NFPA 79). It also never connects to a controller. For machine timing and motion, the next step up is virtual commissioning against a model of the machine.
Factory Acceptance Test Explained - Part 1 | Power the Control Panel
RealPars
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeWhere it fits on a U.S. project
Picture an OEM in North Carolina building a carton sealer. Logic is written in week three, the panel shop slot is week six, FAT is week eight. A two-hour bench test in week four, with fifteen written test cases, finds a stop button that does not break a latched branch and a jam timer that never resets. Both fixes take ten minutes at a desk. Found at FAT, each would have cost the slot and a second customer visit.
Next step
Try the simulator at ladx.ai/ladder, or read our checklist for validating AI-generated ladder logic and our NFPA 79 requirements guide. For teams that want LADX set up across their projects, see our industrial AI service. If you want your program tested before your panel ships, contact us.
