PLC-LadderWhy control logic fails at FAT, and how to surface ambiguity and unsafe behaviour while it is still cheap — before the panel is powered.
Every controls engineer has a story like this. The requirement said "the conveyor stops when a part reaches station 1 and restarts after the dwell." The program did exactly that. At FAT the customer watched it and said: "and when the operator presses stop during the dwell?" Nobody had written that down. Two hours of discussion, a change, a retest, a signature. Multiply by every ambiguity in a 40-page spec.
The expensive part of PLC programming is rarely the typing. It is the gap between what was written and what was meant, discovered at the worst possible time — in front of the machine, with people waiting.
Where the gap hides
Requirements are written by people who know the process and read by people who know the controller. In between, a dozen decisions get made silently:
- Which edge? "When the sensor sees a part" — level or rising edge decides whether the dwell re-triggers on a held part.
- What wins? Start and stop pressed together; open and close commanded at once.
- What happens on reset? After an E-Stop is released, does the motor restart by itself? (It should not — but a seal-in with a held start button will.)
- What happens on power recovery? Which values are retained, which start at zero, which alarms latch?
- What is the number? "A few seconds" became five. Nobody agreed to five.
None of these are exotic. They are the same five categories, project after project. And they are cheap to answer on a Tuesday afternoon and expensive to answer during commissioning.
Make the assumptions visible
The fix is not better prose. It is a tool that refuses to make these decisions silently. When PLC-Ladder drafts logic from a description, it writes down every assumption it had to make — "added: EStop (safety input, not in your request)", "Assuming the dwell time is 3 s; change PT to suit the station", "Assuming the dwell is triggered by the rising edge of the sensor, so a part still covering the sensor after the dwell does not re-trigger it" — next to the diagram, before you approve anything. That list is a set of questions for the person who wrote the requirement. Send it back. Most ambiguity dies right there.
Make unsafe behaviour visible
Some mistakes are not ambiguity; they are habits. A timer fed from a momentary button. A latch that is set-dominant. A direction change without a stop in between. The drafter writes every run latch so stop wins, cuts each output with the E-Stop in its own rung, and says which stop-button wiring it assumed — but the real check is watching it run. Press stop and start together in the simulator. Release the E-Stop with the start button held. Force the stop input to what a cut wire would read. If the machine would do something you don't like, you find out in a browser, not on the floor.
Test it like commissioning, before commissioning
Write the scenarios you would run at FAT as a table: time, inputs, expected outputs. Normal cycle. Each fault path. Reset. Start-up. PLC-Ladder re-runs them with one click whenever the logic changes and tells you which row failed. We are validating an OPC UA connection so your actual HMI can drive the same verified logic from the screens the operator will use. When the hardware arrives, the surprises should already be gone.
What this does not replace
Safety functions belong on certified safety controllers; this is a design and simulation tool, never connected to a live PLC. It does not know your process better than you do — it makes its guesses visible so you can correct them. And it only exports what it has verified: exports open format by format, each only after round-trip validation in the vendor's own tool — the Export dialog shows what is open today.
Try it on your last rework
Take the requirement from the last change that caused rework at FAT. Paste it in. Read the assumptions list. If one of them is the thing you missed, you have just seen the product's whole point in thirty seconds.