Premium apps Part of Twinworks
Twinworks PLC Scan Simulator
Structured Text, ladder or state machine + input timeline → scan-by-scan outputs, timers and trace.
Try an example: TON, TOF, TP and CTU on one push button · Start/stop with interlock (seal-in rung) · Buffer-level control with hysteresis · Two-station handshake (state machine)
How it works
Run a small PLC program in a simulated scan cycle: an IEC 61131-3 style Structured Text subset, a ladder diagram in text form or a state machine. Inputs change on a timeline; every scan reads inputs, executes the program and writes outputs. You get the output and state timeline, TON/TOF/TP timers and CTU/CTD counters per standard behaviour, the generated Structured Text and a timing diagram. Simulation only, no real PLC I/O.
- Own parser for a Structured Text subset (no eval): declarations, expressions with IEC precedence, IF/ELSIF/ELSE, CASE with ranges, FOR/WHILE/REPEAT with EXIT, function block calls with := inputs and => outputs. Types are checked before running; only widening conversions are implicit (INT → DINT → REAL), INT/DINT wrap at 16/32 bits like a PLC.
- Ladder rungs and state machines compile to the same program representation and run in the same interpreter; the generated Structured Text is shown so you can see exactly what runs. Each rung is evaluated once per scan, top to bottom, so a coil written in a later rung is seen by earlier rungs only in the next scan.
- Scan cycle: at k × cycle time the input image is taken from the timeline, the program executes once, and the output image is recorded. Timers use the scan start time: TON switches on at the first scan where IN has been TRUE for at least PT; TOF holds Q for PT after IN falls; TP gives a non-retriggerable pulse of length PT. CTU/CTD count rising edges of CU/CD between scans (pulses shorter than a scan are missed, as on a real PLC).
- State machines become a CASE over State: at most one transition per scan, checked in the listed order; exit action, transition action, then entry action of the new state. StateTime is the time since the state was entered.
- Sandbox: a watchdog stops a scan after 200,000 instructions, loops after 100,000 iterations, a run after 500,000 scans.
Teaching and design aid only: a subset of IEC 61131-3 implemented from public descriptions, simulated in virtual time. It is not a certified runtime and never connects to real inputs or outputs; never use it to validate safety functions.
Sources
- IEC 61131-3:2013 Programmable controllers — Part 3: Programming languages (behaviour of the standard function blocks) (IEC)
- PLCopen: IEC 61131-3 introduction and standard function blocks (PLCopen)
- K.-H. John, M. Tiegelkamp: IEC 61131-3: Programming Industrial Automation Systems, 2nd ed. (Springer, 2010)
Part of Twinworks
-
Twinworks Factory digital twin & production simulation
Model a production line, simulate it and find the bottleneck — free, in your browser.
Related tools
- Twinworks Factory Simulation – Simulate a production line: throughput, lead time, WIP, OEE and the bottleneck, with CIs.
- Ohmforge Logic Simulator (VCD) – Gate-level netlist + stimuli → event-driven waveforms, timing diagram, VCD and truth table.
How to use the Twinworks PLC Scan Simulator
Run Structured Text, ladder rungs or a state machine through a simulated PLC scan cycle and read timers, counters and outputs scan by scan.
What it is for
PLC programs run in a loop called the scan cycle. The PLC reads all inputs, runs the program once from top to bottom, then writes all outputs. This tool simulates that loop. You write a small program, describe how the inputs change over time, choose a cycle time and get the state of every input, output, timer and counter scan by scan.
You can write in three ways: a Structured Text subset modelled on IEC 61131-3, ladder rungs as text such as (Start | Motor) & !Stop -> Motor, or a state machine with states, entry and exit actions and guarded transitions. Ladder and state machines are translated to Structured Text, and the tool shows that code.
It is a teaching and design aid. It never talks to real hardware, and it is not a certified runtime, so it cannot validate safety functions.
Worked example
Open the example TON, TOF, TP and CTU on one push button. One input, Button, drives an on-delay timer (TON), an off-delay timer (TOF) and a pulse timer (TP), all with PT := T#300ms, plus a counter. The cycle time is 10 ms. The button is pressed from 100 to 200 ms, from 400 to 1000 ms and from 1100 to 1150 ms.
The run has 151 scans and 10 change points:
- OnDelay (TON) stays off during the first, 100 ms press. It switches on at 700 ms, 300 ms into the long press, and goes off at 1000 ms when the button is released.
- OffDelay (TOF) comes on at 100 ms and stays on through every gap shorter than 300 ms. It only goes off at 1450 ms, 300 ms after the last release.
- Pulse (TP) gives exactly 300 ms from 100 to 400 ms. The press at 400 ms starts no new pulse, because the running pulse ends in that same scan. The press at 1100 ms gives a second pulse that ends at 1400 ms, even though the button was released at 1150 ms.
- Presses (CTU) ends at 3, one count per rising edge.
How to read the result
- Timing diagram: BOOL signals as levels, numbers and state names as value boxes. Time is in milliseconds.
- State timeline: one row per scan in which something changed.
- Final values: the state after the last scan.
- Generated Structured Text: what actually runs. For ladder, every rung becomes one assignment, IF block or function block call, in rung order.
- Ladder diagram: shown for ladder programs, with power rails, contacts and coils.
Tips and common mistakes
- Inputs are read only at the start of a scan. A pulse shorter than the cycle time can be missed completely, just as on a real PLC.
- Order matters. A variable written in a later rung or line is seen by earlier lines only in the next scan.
- Timers can only switch at scan times. With a 30 ms cycle, a 100 ms TON switches at 120 ms.
- INT wraps at 32767. Assigning a REAL to an INT needs
REAL_TO_INT(...), and the type check says so. - Put
T1.ETor another variable in Extra variables to trace to see it change over time.
FAQ
Which parts of IEC 61131-3 are supported?
BOOL, INT, DINT, REAL and TIME; IF, CASE, FOR, WHILE and REPEAT; and the function blocks TON, TOF, TP, CTU, CTD, CTUD, R_TRIG, F_TRIG, SR and RS. Arrays, strings, structures, user-defined function blocks and other POUs are not supported.
Why does my endless loop stop with an error?
A watchdog stops a scan after 200,000 instructions or 100,000 loop iterations.
How do state machines decide between two true transitions?
Transitions are checked in the order you wrote them. The first true one fires, and at most one fires per scan.
Can I connect the program to a factory model?
Yes. In Twinworks, Analyze → Control (PLC)… binds the program's inputs and outputs to stations and buffers, and the program runs inside the simulation.
Guide last updated:
For scripts and AI agents
- JSON API:
POST https://twinworksplcsimulator.usefulweb.site/api/v1/calculate(same calculation as this page) - Interface description: OpenAPI 3.1 · AI guide: llms.txt
- MCP server (Streamable HTTP):
https://twinworksplcsimulator.usefulweb.site/mcp· tool nametwinworks_plc_simulator
Example request
curl -s -X POST https://twinworksplcsimulator.usefulweb.site/api/v1/calculate \
-H 'content-type: application/json' \
-d '{"language":"st","program":"PROGRAM Timers\nVAR_INPUT\n Button : BOOL;\nEND_VAR\nVAR_OUTPUT\n OnDelay, OffDelay, Pulse : BOOL;\n Presses : INT;\nEND_VAR\nVAR\n T1 : TON; T2 : TOF; T3 : TP; C1 : CTU;\nEND_VAR\nT1(IN := Button, PT := T#300ms);\nT2(IN := Button, PT := T#300ms);\nT3(IN := Button, PT := T#300ms);\nC1(CU := Button, R := FALSE, PV := 3);\nOnDelay := T1.Q;\nOffDelay := T2.Q;\nPulse := T3.Q;\nPresses := C1.CV;\nEND_PROGRAM","timeline":"0 Button=0\n100ms Button=1\n200ms Button=0\n400ms Button=1\n1000ms Button=0\n1100ms Button=1\n1150ms Button=0","cycleMs":10,"durationMs":1500}'