Murray State University · Part four · Example projects

PLC Ladder Logic Trainer

Murray State University
Demo 9 of 17 · Part four · Stage 1

Watch one scan run.

In what order does the PLC actually do its work, and when does a button press take effect?

Before you start. A PLC is not event-driven: forever, it repeats one scan — read every input into a snapshot, solve the ladder rung by rung from that snapshot, then write every output at once. Nothing you press changes anything until the next input read.

Predict

Pause the PLC, then press START. Will the ladder show it as ON before or after you press Step Scan?

Try

Press ⏸ Pause, then Step Scan with the watch window open, and press START in between steps.

Takeaway

A PLC scan reads all inputs, solves the ladder from that one snapshot, then writes all outputs — a button press does nothing until the next input read.

Check yourself

You press START while the PLC is paused, between two scans. When does the ladder first show it as true?

Demo 9 of 17 · Part four · Stage 2

Same two rungs. Different order. Different answer.

Does it matter whether a rung comes before or after the one it depends on?

Before you start. Rungs solve top to bottom, once per scan. A rung that writes a bit hands it to later rungs in the same scan, but to earlier rungs only on the next one. Stage 1's scan order is the mechanism; this stage is what it costs you if you get the order wrong.

Predict

Load Program 6A (echo lags one scan) and 6B (echo follows the same scan) in turn. Which variant makes B_ECHO react one scan later?

Try

Place instructions from the palette to build a rung, then press ▶ Run My Program to send it to the live intersection.

Takeaway

A rung sees what an earlier rung wrote this same scan, but only sees a later rung's write on the following scan — rung order is part of a ladder program's meaning, not just its layout.

Check yourself

Program 6B has the same two rungs as 6A, just in the opposite order. Does swapping the order change what the program does?

Demo 9 of 17 · Part four · Stage 3

Build it from a spec.

Can you turn a plain-English requirement into a program that survives a real test, not just one that looks right?

Before you start. Each challenge gives a spec (what the program must do) and a fixed tag list to build it with. Stage 2 built rungs one at a time; here the grader runs your finished program against a scripted sequence of inputs and checks the outputs at every step.

Predict

Before you press Check on the seal-in challenge: will your program survive a momentary loss of the START signal, or drop out?

Try

Build your rungs, then press Check my program. Use Reveal hint if you get stuck.

Takeaway

A program is "correct" when it produces the right outputs at every step of a real test sequence — not when it merely resembles the spec.

Check yourself

The grader marks your seal-in attempt PASSED. What has it actually verified?

Demo 9 of 17 · Part four · Stage 4

Diagnose it before you look.

Can you find an injected fault from how the intersection misbehaves, before you look at the ladder?

Before you start. A fault here is one changed instruction, tag or timer preset — the rest of the program is untouched, and it still passes validation with zero errors. Until you reveal it, the intersection's behavior is your only evidence.

Predict

Hide the ladder pane below, inject a fault, and guess which instruction changed from the intersection's behavior alone — then reveal it to check.

Try

Press Inject random fault, watch the intersection, then press I’ve diagnosed it — reveal.

Takeaway

The intersection's misbehavior is evidence about which instruction changed — the ladder confirms a diagnosis, it does not have to be where you start.

Check yourself

A fault gives NS_GRN two OTE coils. The light stays on when it should not. Which coil is "winning"?

Live the scan count, image tables, ladder power-flow and intersection state, computed here every scan

The engine

Program
Timing & speed
scan 000000 · t=0.00 s
WATCH WINDOW · IMAGE TABLES Rows flash when a bit changes. Use Step Scan to watch exactly when.

PLC Ladder Logic Trainer · Bryant Harrison · Murray State University
One HTML file · runs offline · a genuine scan-cycle engine, not an animation
Printable guide

Guidehow to use this demo

How does a real industrial controller actually think? This is a genuine scan-cycle PLC engine on the classic four-way stoplight — not an animation.

Where this sits: an Applied Engineering example project in Part four. No earlier demo is required, but if you have used Demo 2 (How a Language Model Works), the idea of a fixed, repeating computation loop should feel familiar — a PLC scan is that same idea in a control system instead of a model.

  1. Trainer. Pick a program, then press ⏸ Pause and Step Scan to watch the scan cycle one step at a time.
  2. Editor. Place instructions from the palette to build or edit a rung, then Run My Program to send it to the live intersection.
  3. Challenges. Build a program that satisfies a written spec, then press Check my program to grade it against a scripted test.
  4. Troubleshoot. Press Inject random fault, diagnose it from the intersection, then reveal to check yourself.

Getting around

The stage tabs switch stages; the live engine below them keeps running no matter which stage you are on. Details opens the mechanism, assumptions and sources for the current stage. Guide reopens this card; Settings holds Open Presenter Notes, Presentation mode, Reset, and this demo's own engine self-test.

Time

10–15 minutes to try all four stages; a full class period to work through the challenges and several troubleshoot rounds. Keyboard: Space run/pause, . step one scan.

Settings

Presenter notes

The printable teacher guide, on screen: the scan cycle in plain terms, why rung order matters, latch vs. seal-in, a 45-minute lesson plan, common misconceptions and discussion questions. This is the printable guide itself, not a summary of it.

Presentation mode

Scales the whole page up one notch for projecting to a room (including the ladder, editor and challenge panels, at their own larger scale), and puts a Notes button in the header.

Reset

Back to the just-opened state: the PLC and intersection restart on the first program, the editor's undo history and any unsaved student program are cleared, the active challenge and its hints reset, any injected fault is abandoned, and the engine strip returns to 1× speed and a 20 ms scan. The page does not reload. Presentation mode stays as you set it.

Engine self-test

Runs 21 assertions about scan-cycle semantics live, in front of the class — input-scan ordering, timer/counter accumulation in simulated time, and the double-coil "last write wins" behavior Stage 4 asks you to diagnose. Results appear in a card below.

Printable teacher guide

Engine self-test

DetailsTrainer

What is live

Every number on screen is computed by the same engine, this instant

Live scan count, elapsed simulated time, image tables, ladder power-flow, intersection state

Nothing here is pre-recorded. Pressing Step Scan advances the same engine that drives free running, one scan at a time, and every readout updates from its current state.

How it works

input scan → solve rungs 0..N−1 (branches top–to–bottom) → output scan

Every input is latched into an input image table once per scan; the ladder is solved strictly top-to-bottom, left-to-right, from that one snapshot; every output is then written from the output image table, all at once. Timers and counters accumulate in simulated scan time (never the wall clock), which is what makes a run bit-for-bit reproducible at any speed.

Assumptions and simplifications

  • Scan time is fixed per your Timing setting (10–200 ms); a real controller's scan time varies with program size and load.
  • One task, no interrupts, no I/O forcing or network scan — the parts of a real controller's cycle that this teaching engine deliberately leaves out to keep one mechanism visible.

Sources

  • No external source is needed for this stage's claims — they describe this engine's own mechanism, verified by reading src/engine.js and by Settings → Run engine self-test live in the browser.
Boundary: this is a teaching engine, not a certified PLC and not an IEC 61131-3 conformance-tested runtime. It models one deterministic reading of Allen-Bradley-style ladder execution for the classroom, not any vendor's certified product.

Presenter Notesthe printable guide, on screen

Teacher and presenter guide · PLC scan-cycle trainer on the classic four-way stoplight

PLC Ladder Logic Trainer

Demo 9 of 17 · Part four, Example projects · 15 minutes for a first pass across all four stages; a full 45-minute period using the lesson plan below

You need: index.html open in any modern browser, on a projector or on each student's device. No network, no install, no accounts. Nothing is fetched at runtime, so it works with the wi-fi off.

Learning goals

One per stage, in the learner's own words — these are the four Takeaway cards on screen, verbatim. If a student can say these four things and point at the evidence for each, the demo has done its job.

  1. A PLC scan reads all inputs, solves the ladder from that one snapshot, then writes all outputs — a button press does nothing until the next input read.
  2. A rung sees what an earlier rung wrote this same scan, but only sees a later rung's write on the following scan — rung order is part of a ladder program's meaning, not just its layout.
  3. A program is "correct" when it produces the right outputs at every step of a real test sequence — not when it merely resembles the spec.
  4. The intersection's misbehavior is evidence about which instruction changed — the ladder confirms a diagnosis, it does not have to be where you start.

Where this sits on the path

An AI-built classroom tool from Part four (Applied Engineering · PLC control). Its goal is to make a real industrial control loop watchable one scan at a time, its engine is a live, genuine scan-cycle simulator (not an animation), and its assumptions — what is a deliberate teaching simplification and what would carry over to a real controller — are one tap away in Details. It does not depend on any earlier demo; the habit it shares with the rest of Part four is exposing exactly which numbers are computed live, which are this build's own reading of a documented standard, and which are a hand-authored fixture.

One question for the session

How does a controller that never stops looping actually think — and what does that loop cost you if you get its order wrong?

"This is not a wiring diagram and not an animation. It is a real, deterministic scan-cycle engine: read every input, solve every rung in order, write every output, forever. Everything we do for the next fifteen minutes is about what that one loop implies — for timing, for the order you write rungs in, for what 'correct' means, and for how you'd diagnose it when something breaks."

Stage 1 · Trainer — how does one scan run?

Question: In what order does the PLC actually do its work, and when does a button press take effect?

Predict prompt: Pause the PLC, then press START. Will the ladder show it as ON before or after you press Step Scan? Take a show of hands before anyone steps.

Activity (5 minutes): 0:00 load Program 1 (Basic Timed Stoplight), running · 1:00 press ⏸ Pause, open the watch window · 1:30 press START, then Step Scan once and read both image tables · 3:00 step a few more scans and narrate what changed and when · 4:00 open Details for the formal scan order.

Expected observation: The input image table shows START as unchanged until the next Step Scan, at which point it flips — the ladder's power flow and the watch window's flashed row both update on that same step, not before.

Check-yourself answer key: "Not until the next Step Scan (or the next running scan)." The tempting wrong answer treats the PLC as event-driven ("immediately, the instant you press it") — the paused state is exactly what refutes it: nothing moves until you advance the scan yourself.

Teaching limit: Do not let "the PLC reads inputs" become "the PLC reacts instantly." Stage 2 depends on the class already treating "scan" as a discrete, ordered event, not a continuous flow.

Misconception: outputs change mid-rung. Real outputs update only at the end of the scan, all together, from the output image table built while solving. Watch the output image table while stepping: it holds its old values until the whole rung list has been solved once.
Misconception: pressing a button acts instantly. It acts at the next input scan. In step mode a press does nothing until you step — this is the whole point of the Predict prompt above.
Misconception: a timer counts wall-clock time. A TON accumulates only while its rung is true, in simulated scan-time increments, and resets the moment its rung goes false — it is not reading a real clock, which is also what makes every run bit-for-bit reproducible regardless of speed.

Stage 2 · Editor — why does rung order matter?

Question: Does it matter whether a rung comes before or after the one it depends on?

Predict prompt: Load Program 6A, then 6B (same two rungs, opposite order). Which variant makes B_ECHO react one scan later than B_SRC?

Activity (8 minutes): 0:00 load 6A, hold START, single-step and watch B_SRC then B_ECHO · 2:00 load 6B, repeat · 4:00 in the Editor, place a rung from the palette and press Run My Program · 6:00 discuss why the same two instructions in opposite order are two different programs.

Expected observation: In 6A, B_SRC turns on the scan you press START, but B_ECHO lags exactly one scan behind it. In 6B, both update the same scan.

Check-yourself answer key: "Yes — the same logic, one scan later, is a different program." The wrong option treats ladder like relay wiring, where physical order genuinely would not matter; a PLC scan is not continuous current flow, it is a fixed, repeated solve order.

Teaching limit: This is about scan-order semantics, not style. The editor's constrained palette (nine instructions, no nested branches) is a teaching simplification — see Model and boundaries.

Misconception: ladder is a schematic. It looks like relay wiring but is a program: solved in order, one rung at a time, over and over. Electricity flows everywhere at once in a real relay panel; a PLC scan does not.

Stage 3 · Challenges — can you build it?

Question: Can you turn a plain-English requirement into a program that survives a real test, not just one that looks right?

Predict prompt: Before pressing Check on the seal-in challenge — will a seal-in built with a single OTE survive a momentary loss of the START signal, or drop out?

Activity (10 minutes): 0:00 read the seal-in spec and required tags · 1:00 build in the palette · 3:00 press Check my program, read the first failing step if any · 5:00 fix and recheck; fast finishers move to Delayed Start, then the full stoplight-from-spec challenge.

Expected observation: A PASSED banner names all steps the scripted sequence checked; a NOT YET banner names the first step that failed and when, not merely "wrong."

Check-yourself answer key: "That your program's outputs matched the scripted test at every step it checked." A different, differently-wired program that behaves the same on that sequence passes equally well — there is no single intended wiring the grader is comparing against.

Teaching limit: The four challenges check one behavioral spec each; they are not a style or efficiency grade, and passing one is not a certificate for real PLC work.

Misconception: a PASSED badge means my program is the intended, correct solution. It means your program matched the scripted test's expected outputs at every step the grader checked. Two structurally different programs — different tags, different instruction choices, even a different number of rungs — that produce the same outputs on that sequence both pass. Ask a fast finisher to compare their wiring with a neighbor's passing solution to make this concrete.

Stage 4 · Troubleshoot — can you find the fault?

Question: Can you find an injected fault from how the intersection misbehaves, before you look at the ladder?

Predict prompt: Hide the ladder pane (the Predict card's own toggle), inject a fault, and guess which instruction changed from the intersection's behavior alone — then reveal to check.

Activity (12 minutes): 0:00 check "Hide ladder pane" · 1:00 press Inject random fault, watch the intersection for a full cycle or two · 3:00 write down a guess · 4:00 press I've diagnosed it — reveal and compare · repeat 2–3 times, using the teacher <details> to pick a specific fault for a targeted round (e.g. the double-coil fault for the Check-yourself item below).

Expected observation: The reveal card names the fault, the symptom, and the explanation, and highlights the exact patched rungs on the ladder.

Check-yourself answer key: "The one solved last, every single scan." The wrong option ("whichever turned on first") is the natural but incorrect guess — turning on first offers no protection, because every OTE on the rungs still executes in program order every scan.

Teaching limit: This engine's own last-write-wins behavior is verified by its self-test; it is a close, well-corroborated reading of how a single real controller resolves a duplicate coil in one scan, not a certified statement about every configuration — see Details.

Misconception: two coils with the same tag both work. The last one solved wins every scan (see the double-coil fault) — the earlier coil's write is simply overwritten before the scan ends. It does not error, and it does not average; it is silently overwritten, which is exactly why it is worth a dedicated fault.

Model and boundaries

input scan → solve rungs 0..N−1 (branches top–to–bottom) → output scan
  • Every input is latched into an input image table once per scan; the ladder is solved strictly top-to-bottom, left-to-right, from that one snapshot; every output is written from the output image table at once, at the end of the scan.
  • Timers and counters accumulate in simulated scan time (Timing & speed's Scan-time setting), never the wall clock — a run is bit-for-bit reproducible at any Speed multiplier.
  • Series instructions = AND, parallel branches = OR — this engine's own reading of Allen-Bradley/Logix-style rung-condition-in/rung-condition-out execution, Reasoned rather than Sourced because the primary Rockwell documentation could not be read directly in this research pass (see Sources). Corroborated by independent secondary references for a single controller, single scan, non-retentive OTE — exactly what this engine models.
  • This engine's duplicate-OTE "last write wins" behavior is Live — verified by reading src/engine.js and by one of the 21 assertions in Settings → Run engine self-test. Whether every real Allen-Bradley/Logix controller behaves identically in every configuration (retentive instructions, distributed I/O) is Reasoned, with that boundary stated on screen.
  • The editor's palette is a deliberately constrained subset (nine instruction types, no nested branches, a fixed tag list) — a teaching simplification, not a limit of real ladder logic.

This is a teaching engine, not a certified PLC and not IEC 61131-3 conformance-tested. It models one deterministic reading of Allen-Bradley-style ladder execution for the classroom, not any vendor's certified runtime or firmware version. Full per-stage assumption lists are in the app's Details drawer, which is the surface students should be sent to when they ask "but is that a real PLC?".

One deliberate simplification, worth a five-minute extension. These programs step straight from a yellow to the cross street's green. A real signal inserts an all-red clearance interval first (MUTCD §4D.26 governs the yellow-change and red-clearance intervals) so the intersection empties before conflicting movements get a green. It is left out to keep the sequence short enough to read on one screen — ask the class to add it in the Editor, and watch them discover it costs a timer and a step in every phase.

Discussion questions

  • Why can't both directions ever be green in Program 1, even if a timer misbehaves? (Two independent defenses: the step sequence and the XIO interlock contacts — Details names both.)
  • Why is the walk request latched (ONS + OTL) instead of wired straight to the walk sign? What would happen if it weren't?
  • In the Scan Order Demo, which variant (6A or 6B) would you choose for an emergency-stop rung, and why?
  • Seal-in vs. OTL for the motor: which restarts by itself after a power blip? Which is safer, and when?
  • Our simulated scan defaults to 20 ms. What real-world inputs could a PLC miss entirely between scans, and how would you catch them?
  • The page labels some claims Live, some Reasoned. Find one of each in Stage 4's Details and say what each label is promising you — and NOT promising you.

Presenter controls

The four stage tabs run across the top and are never gated — a class can jump straight to Troubleshoot. Details in each stage intro opens that stage's mechanism, assumptions and sources. ? reopens the Guide. ⚙ Settings offers Open Presenter Notes (this document), Presentation mode, Reset, and this demo's own engine self-test (21 live assertions about scan semantics).

Presentation mode scales the page up one notch and adds a Notes button to the header; it also scales the ladder/sim/editor/challenge panels at their own larger factor (this demo's own mechanism, unrelated to the page-text scaling). Reset returns the demo to its opening state without reloading the page — Program 1 fresh, the editor emptied, all challenge progress cleared, any fault abandoned, Timing back to 1×/20 ms — and leaves presentation mode as you set it. The engine-run controls (Program, Run/Pause, Step Scan, Reset PLC) are visible on Trainer and Troubleshoot, where operating the PLC's timing is the point; on Editor and Challenges they are one tab away, and the live intersection keeps running underneath regardless of which stage is showing.

Keep the live engine and the teaching frame distinct. The scan-cycle mechanics, the seven programs, the ladder editor, the four challenges and the eleven faults are all unchanged by this pass — every one is Live, computed by the same engine, verified by its own self-test and node test suites. Only the surrounding frame (stage navigation, Predict/Try/Takeaway, Details, Check yourself) is new.

Sources and attribution

  • Rung-Condition Behavior in Studio 5000 Ladder Logic (fetched 2026-09-16) — the rung-condition-in/rung-condition-out chain this build's series=AND, parallel=OR reading follows.
  • OTE (Output Energize) — Definition & Explanation (fetched 2026-09-16) — OTE re-solves its tag from the rung condition every scan.
  • Independent PLC-programming forum and reference discussions of "last rung wins" for a duplicate output coil (fetched 2026-09-16) — consistent for a single controller, single scan, non-retentive OTE (this engine's configuration); one discussion found also disputes the flat "last write always wins" framing for other hardware and configurations (retentive instructions, distributed I/O), which is why this demo's own claim is labeled Reasoned with a stated boundary rather than flatly Sourced. Rockwell's own primary instruction-set page and PDF programming manual were attempted first and could not be read directly in this research pass (a region/cookie interstitial with no instruction text, and a PDF whose text layer did not decode) — disclosed rather than silently worked around.
  • MUTCD §4D.26 (yellow-change and red-clearance intervals) — spot-checked via a California MUTCD companion document confirming the section number, not a full read of the standard's text.

These sources support the underlying PLC-programming and traffic-engineering background; they do not endorse this activity. A Murray State project record supports plausible course fit; it is not named here, and the demo is not presented as any instructor's instrument or assignment.

PLC Ladder Logic Trainer · Bryant Harrison · Murray State University · Offline teaching model. Open index.html to run the trainer. src/demo-guide.html is the canonical source of this document; the shipped teacher-guide.html, the PDF beside it, and the in-app presenter notes are all generated from it at build time.

Open the printable copy (teacher-guide.html) — the same document, laid out for print; the PDF beside it is a render of that file.
Bryant Harrison · Murray State University