Scan-cycle programming workbench
PLC programming simulator: write, scan, test and debug control logic
Direct answer
A PLC programming simulator lets you write ladder logic or Structured Text, run it on a repeating read-inputs, solve, write-outputs scan and watch simulated sensors and actuators respond, without a controller or vendor license. Its value is feedback: you predict what each scan should do, observe what it actually does and fix the first difference before the logic reaches real hardware.
This guide is written for students writing their first rungs, technicians who read programs but rarely write them, interview candidates rehearsing machine-control problems and engineers sketching a logic idea before opening the target IDE. The intended result is specific: you can explain why an output is on or off in terms of the input image, rung order and retained state, and you can show a passing behavioral test for start, run, stop and fault cases rather than a screenshot of a finished diagram.
Input image, not live wiring
At the start of each scan every input is copied into an image table, and the program reads that snapshot for the whole pass. A pushbutton that changes midway through the scan is not seen until the next one, which is why rung results are consistent within a scan and why a pulse shorter than one scan can be missed entirely.
Rung order is program logic
Rungs execute from top to bottom, so a bit written on rung 8 is not visible to rung 3 until the following scan. Moving a rung can therefore shift a result by exactly one scan. A program that only works because of its current rung order is fragile and should be restructured so each decision reads settled values.
Last write wins
If two rungs assign the same output coil, the one executed later overwrites the earlier result before outputs are updated. The field device follows the final value, so the first rung appears to do nothing. Give every output one owning rung and combine its conditions there, using set and reset forms only when a latch is intended.
Timers need continuous calls
A TON accumulates elapsed time only while its IN condition stays true on every scan and returns to zero as soon as IN goes false. TOF delays the falling edge and TP produces a fixed-length pulse. If the timer instruction is skipped or its enable drops for one scan, the elapsed value restarts and the done bit never arrives.
Levels versus edges
CTU, CTD and CTUD respond to a rising edge of the count input, so a sensor held true still adds one count per part. An ADD instruction on the same held condition adds one on every scan instead. Toggles, step advances and arithmetic triggered by a button therefore need R_TRIG or F_TRIG to turn a level into a single-scan event.
Behavior, not diagram shape
A scenario test drives the inputs through a scripted sequence and checks outputs and machine state at defined points. It does not compare your rungs with a model answer, so a different structure passes when it behaves correctly, while neat-looking logic fails when timing, interlocks or recovery after a fault are wrong.
- 01
Turn the brief into an I/O table
List every input and output the scenario provides, note whether each field device is normally open or normally closed, and write what the machine must do on start, stop and fault.
Evidence: Each output has one named owning condition and each normally closed device has a stated healthy value.
Avoid: Choosing contact instructions before knowing how the stop button or sensor is wired.
- 02
Predict one scan by hand
Pick one input combination and write the expected state of every rung and output before pressing Run.
Evidence: The live I/O table and rung highlighting match the written prediction on repeated scans.
Avoid: Running first and rationalizing whatever the outputs happen to do.
- 03
Build the smallest runnable increment
Write only the start/stop or first-step logic, run it, and add the next requirement once the first one behaves.
Evidence: A valid partial program runs and makes the still-missing requirement obvious.
Avoid: Writing the whole sequence in one pass and then debugging several faults at once.
- 04
Toggle inputs deliberately
Drive each input manually, including start and stop together, a held start button and a stop pressed while a timer is running.
Evidence: Outputs stay defined for simultaneous and out-of-order commands.
Avoid: Testing only the tidy start-then-stop order a demonstration would use.
- 05
Run the scenario tests
Execute the authored checks and read each failure reason against your I/O table and rung order.
Evidence: Per-check results name the requirement that failed and the step at which it failed.
Avoid: Adding timers or extra latches until a check turns green without knowing why it failed.
- 06
Rebuild on the target
Recreate the logic in the controller’s own IDE, apply its addressing and timer conventions, and repeat the same test cases.
Evidence: The same input sequences produce the same outputs on the vendor simulator or hardware.
Avoid: Assuming a browser pass proves scan time, firmware or I/O module behavior.
| Observed symptom | Inspect | Interpretation | Next proving action |
|---|---|---|---|
| Motor runs only while Start is held | Holding contact tag, its position in parallel with Start, and whether Stop is in series with both branches | Without a contact on the output tag in parallel with Start, or a latch, the rung is true only while the momentary input is true. | Add the holding branch and prove that Stop and the overload each break it. |
| Stop button starts nothing or never stops | Physical contact type of the stop device, its input value at rest and the contact instruction used | A normally closed stop button reads true when healthy; programming it with a normally closed instruction inverts the intended logic. | Use a normally open instruction on the NC field input so a pressed button or broken wire stops the machine. |
| Output stays off although its rung is true | Every rung that writes the same output coil and the order in which they execute | A later rung with a false result overwrote the earlier true one before the output update. | Merge the conditions into one owning rung and rerun the same input case. |
| Timer done bit is never seen | Timer IN on consecutive scans, the elapsed value, and whether the done bit opens its own enable | A timer that resets itself through its own done bit produces a pulse lasting one scan, which rungs above it may never observe. | Drive IN from a stable state bit, or place consumers of the done bit after the timer rung. |
| Count jumps by many per part | Whether the count comes from a counter instruction or ADD/MOV logic, and how long the sensor stays true | Arithmetic executed on a level condition runs on every scan while the sensor is true. | Insert R_TRIG before the increment, or use CTU, which counts rising edges. |
| Sequence skips a step | Rung order of the step bits, their transition conditions, and whether one input advances two steps in the same scan | If step 2 is evaluated after step 1 sets it and uses the same transition input, the sequence cascades through both steps in one scan. | Qualify transitions with an edge or require a different condition for each step. |
Product evidence / 05
What the browser practice can actually demonstrate
Programs are parsed into a common representation and executed on a deterministic cycle that reads inputs, executes the program, updates outputs and advances the machine model, with live I/O, timer and counter values visible. Scenario tests pass on observed machine behavior across authored input sequences, so an equivalent solution passes and a tidy but wrong one fails.
Can I learn PLC programming with only a simulator?
You can learn the language, scan behavior, sequencing and structured testing with a simulator, which covers much of what separates a working program from a broken one. Wiring, I/O module behavior, vendor IDE workflows, downloads and online edits still need a real or vendor-simulated controller, under supervision, before you rely on the skill at work.
Should I start with ladder logic or Structured Text?
Start with ladder if your work involves discrete machine control or reading existing plant programs, because rung highlighting makes scan behavior visible. Add Structured Text once you need calculations, comparisons, state machines or data handling. The simulator runs both against the same I/O, so you can write one requirement both ways and compare the results.
Why does my Structured Text output stay on after the condition goes false?
An assignment inside an IF block runs only while that branch executes. When the condition becomes false and there is no ELSE, the variable keeps its last value and behaves like a latch. Either assign the output directly from a Boolean expression, such as Lamp := Sensor AND NOT Fault, or write both branches explicitly.
How is a simulated scan different from a real PLC scan?
The order is the same: read inputs, execute the program, write outputs. Here time advances on a deterministic teaching clock, so results repeat exactly. A real controller adds variable scan time, communication and task overhead, input filtering, module update delays, interrupts and a watchdog, and those effects only appear on the target hardware.
What should I program first in a PLC simulator?
Begin with one input driving one output, then a normally closed input, then a three-wire start/stop with a holding contact. Add an on-delay timer, a counter with a reset, and finally a short sequence such as a traffic light. Each exercise introduces one scan-related idea that the next one depends on.
Can I copy my simulator program into a real PLC?
IEC-style Structured Text is the most portable, but it still needs the target’s declarations, addresses and library names. Ladder must be re-entered in the vendor editor. Native project-file export is not promised, so treat the browser program as a tested design to recreate, then run the same test cases again on the target.
How do I know my program is correct and not just lucky?
Write the test cases before you run: normal start and stop, simultaneous commands, a held input, a sensor that never arrives, and restart after a fault. A program that passes all of them from a reset state on repeated runs is correct for the modeled requirement; a single successful cycle only proves one path.
Is a PLC programming simulator useful for interview preparation?
Yes, because interview tasks are usually holding circuits, timers, counters, sequences and interlocks that you must explain aloud. Practice stating what each rung does on the current scan, why an output changes and how you would test the failure case. Tracing behavior clearly matters more to an interviewer than remembering one vendor’s mnemonics.