PLC Simulator Online: Test Ladder Logic Without a PLC

The first time your logic runs should not be on the machine. Everyone agrees, almost nobody has a spare controller on the bench, and so a lot of ladder logic gets its first real test with a motor attached. A PLC simulator online removes the excuse: the scan loop runs in the browser, you force the inputs, and you watch the coils. This post covers what a simulator has to get right to be worth trusting, what is worth testing before you go anywhere near hardware, a worked example with a nuance that catches people, and, at the end, the list of things simulation does not prove.

What a scan cycle is

A PLC does not react to inputs as they happen. It runs a loop, the scan, and every pass has three phases.

Read. The controller samples every physical input and copies the values into memory. From this point until the next read, the logic sees a frozen snapshot of the inputs.

Solve. The program runs once, top to bottom, in source order. Each rung reads memory and writes memory. A rung that reads a coil written above it sees this scan's value; a rung that reads a coil written below it sees last scan's value.

Write. The output memory is copied to the physical outputs, all at once.

Then it repeats, typically every few milliseconds. Two consequences follow. A button pressed and released between two reads is never seen. And rung order is part of the logic: the same rungs in a different order can differ by exactly one scan.

What a PLC simulator online has to get right

A ladder diagram simulator that lights up coils when contacts are true, in any order, is a drawing with animation. To be useful for testing it has to replicate the scan: read the forced inputs, solve every network in source order exactly once, publish the outputs, repeat. Ours does that, and the specifics matter, because they define what a test means.

Networks evaluate in strict source order, one pass per scan, with boolean rungs and numeric blocks interleaved exactly as written. The on-delay timer measures real elapsed time in the scan loop, so a TON with a 5 s preset is done on the first scan at or after five seconds of continuous input. A set/reset pair on the same variable is set-dominant: if both fire on the same scan the output ends the scan true. Rising-edge detection seeds its memory on the first scan, so an input that is already on when the simulation starts does not produce a phantom pulse. These are choices, and they are written down, because a plc ladder logic simulator whose rules you do not know cannot tell you anything about your program.

What to test before you touch hardware

Three behaviours account for most of the surprises we see, and all three can be tested in a minute of forcing inputs.

Seal-in behaviour. Force the start input on, then off. Does the output stay on? Force stop. Does it drop? Then the case people forget: force start and stop together. In a seal-in written as (Start OR Motor) AND NOT Stop the stop wins, because it is in series. In a SET/RESET pair the answer depends on the rules above. Decide which you want, then check the simulator agrees.

Timer delays. Start the timer, watch the Q pin, and interrupt the input before the preset. A TON restarts from zero when its input drops, which is right for a start delay and wrong for a "run for at least N seconds" requirement. The simulator makes that difference visible in a way the source text does not.

Interlock precedence. An emergency stop must cut the output in the output's own rung, not only upstream of a timer. Force the E-stop while the machine is running and count scans until the output drops. If the answer is more than one, the interlock is somewhere it should not be.

Worked example: the conveyor with an E-stop

Here is the request the workbench at PLC-Ladder uses as its placeholder, because it packs all three tests into one program: start the conveyor five seconds after the start button is pressed, stop it instantly on the emergency stop, and raise an alarm if pressure goes above 80.

PROGRAM Main
VAR
    StartButton : BOOL;
    StopButton  : BOOL;
    EStop       : BOOL;
    Pressure    : INT;
    RunRequest  : BOOL;
    StartDelay  : TON;
    Conveyor    : BOOL;
    Alarm       : BOOL;
END_VAR
// Assuming EStop is TRUE while the emergency stop is pressed.
// Assuming the 5 s delay restarts whenever the run request drops.
RunRequest := (StartButton OR RunRequest) AND NOT StopButton AND NOT EStop;
StartDelay(IN := RunRequest, PT := T#5s);
Conveyor := StartDelay.Q AND NOT EStop;
Alarm := Pressure > 80;
END_PROGRAM

Four networks: the seal-in on the run request, the timer, the conveyor output with the E-stop in its own rung, and the alarm as a comparator block. Press Run, force StartButton, and release it. The run request holds. Nothing else happens for five seconds, then the timer's Q pin goes true and the conveyor coil energises on the same scan, because the conveyor rung is below the timer rung and reads this scan's value.

[SCREENSHOT: Ladder tab mid-delay, RunRequest sealed in, the TON block energised with Q still false, Conveyor coil off]

Now force EStop. The conveyor drops on that scan, and so does the run request, so the timer resets and a restart needs the full five seconds again. Set Pressure to 81 in the rail and the alarm coil lights on its own; it has no interlock, which is what was asked for and is worth a second look.

[SCREENSHOT: EStop forced on, Conveyor and RunRequest both de-energised, the NC EStop contacts open in both rungs]

The one-scan lag. Suppose you add a run lamp and, being tidy, put it at the top of the program:

RunLamp  := Conveyor;
Conveyor := (StartButton OR Conveyor) AND NOT StopButton;

Force the start button. On the first scan the lamp rung runs before the conveyor rung, reads the old value, and stays off; the conveyor comes on. On the second scan the lamp follows. The lamp is always one scan behind the conveyor. For a lamp that is invisible; for a rung that feeds a safety interlock, or an edge detector, one scan is a real difference. The simulator's Step button, which runs exactly one scan, is the way to see it, and the AI drafted, compiler-verified, human-approved loop we build around exists precisely so a person looks at rung order before the hardware does.

What simulation does not validate

A simulator validates logic. It does not validate the machine, and the honest list is short and important.

Wiring. The example assumes EStop is TRUE when pressed. On a real panel a safety-rated stop is normally-closed and its input goes FALSE when pressed, and the rung must be written for that. The simulator will happily run either version; it cannot see the panel.

I/O mapping. StartButton is a name. Which terminal, which card, which address it maps to lives in the vendor tool, and a large share of commissioning faults are exactly there.

Timing on real hardware. The simulator scans on its own clock, not your controller's. A five-second TON is five seconds on both, but scan-dependent behaviour, input filtering and output response are properties of the hardware.

Vendor instructions and safety functions. The subset we simulate is small and published. Safety-rated logic, motion, and vendor-specific instructions are outside it, by design, and are rejected rather than approximated.

Use the simulator for what it is good at: proving the seal-in holds, the delay is the one you meant, the interlock is in the right rung, and the network order does what you think. Then take the logic to the tool that talks to the controller. If you want to see the diagram side of the same workflow, start with creating ladder diagrams online; for a systematic version of the forcing above, CSV injection testing runs a table of cases against the same scan engine.