What is ladder logic?
Ladder logic is a graphical PLC programming language. Each rung evaluates conditions on the left and drives instructions or outputs toward the right during the controller scan.
140 source-catalogued practice records
Ladder Logic Examples — 8 Canonical Patterns, All Runnable
Learn eight recurring ladder patterns with circuit diagrams, physical-machine context and links into 140 source-catalogued practice records. Then build a first contact-and-coil program in your browser without an account.
Join 9900+ learners practicing PLC programming
The guided first rung needs no account. Create a free account to save progress to start.
Real ladder logic examples footage
See this exact skill in the working simulator.
Watch the real browser product respond to the task on this page, then try the same practical workflow yourself. No slides, concept mockups, install, or credit card.
Try this in the browserConnect each rung to the machine
Six ladder patterns in real control context
A rung is useful only when you can explain the equipment state it creates. These examples connect the abstract contact-and-coil shapes to motors, sensors, sequence timing, permissives and process stages.
Why patterns matter
Every PLC program is assembled from patterns
A motor start/stop circuit is not invented from scratch each time: the seal-in rung is a recognisable control pattern. An interlock blocking two contactors from energising simultaneously is another. A timer cascade advancing a timed sequence step by step is another. Pattern recognition helps you form a hypothesis about unfamiliar code, but you still verify tag meaning, scan order, hardware state and the machine specification.
These patterns cover common building blocks in discrete machine control. Learning them is not about memorising rungs: it is about understanding what problem each pattern solves, what assumptions it makes and how you would prove the resulting behavior.
Each pattern on this page includes a structural diagram (pattern shape only — no complete program, no tag addresses), a plain-English explanation of what it does and when it is used, and links to the live scenarios on this platform that exercise that exact pattern. The scenarios are the place to build the pattern yourself. This page is the conceptual foundation.
Direct answers
What ladder logic is—and what it is not
What is a ladder diagram?
A ladder diagram uses two vertical rails with horizontal rungs. Electrical relay diagrams describe wired control; PLC ladder diagrams use similar notation to express software instructions evaluated by a controller.
Relay logic vs PLC ladder logic
Relay logic changes behavior by rewiring components. PLC ladder logic changes software while field devices remain mapped to I/O. PLCs add timers, counters, data and diagnostics, but the electrical safety circuit still has its own requirements.
FoundationalPattern 1 of 8
Seal-In (Motor Latch)
The most common ladder circuit in industry
The pattern
A momentary Start pushbutton energises an output coil. A parallel contact — fed by the same output bit — holds the coil energised after the Start button is released. A normally-closed Stop contact in series with the parallel branch breaks the circuit on demand. The output coil "seals itself in" through its own contact.
When it is used
Virtually every motor circuit. Conveyor drives. Pump contactors. Any load that must stay on after a momentary start command and turn off on a momentary stop command. The pattern also appears in alarm latches, fault holds, and mode-enable circuits where any version of seal-in logic is required.
Practice it in these scenarios
Pattern structure (concept only)
SafetyPattern 2 of 8
Interlock (Mutual Exclusion)
Preventing two outputs from being simultaneously true
The pattern
Two outputs (A and B) must never both be energised at the same time. A normally-closed contact of output A is placed in series with the rung driving output B, and vice versa. If A is true, its NC contact in the B rung opens, blocking B. This is a software interlock; in real panels it is always paired with a hardwired electrical interlock (wired NC contacts across the physical contactors).
When it is used
Forward/reverse motor drives where reversing a spinning motor is mechanically destructive. Star and delta contactors in a star-delta starter — energising both simultaneously would short two motor terminals. Dual-coil solenoid valves where both coils energised is a fault state. Any dual-output exclusion requirement.
Practice it in these scenarios
Pattern structure (concept only)
Timing & SequencePattern 3 of 8
One-Shot / Edge Detection
Triggering logic on the rising or falling edge of a signal
The pattern
A one-shot (OSR/R_TRIG) instruction produces a single-scan true output on the rising edge of its input signal — regardless of how long the input stays true. A standard normally-open contact stays true for as long as the input is true; the one-shot is true for exactly one scan. The equivalent falling-edge instruction (OSF/F_TRIG) triggers on the 0→1→0 transition.
When it is used
Counting items on a conveyor — a photoelectric sensor sees each item for multiple scans; the one-shot ensures each item counts as exactly one pulse. Incrementing a counter only once per button press even if the button is held. Triggering a timed delay on the first scan that a condition becomes true. Detecting the leading edge of a process alarm before it is acknowledged.
Practice it in these scenarios
Pattern structure (concept only)
Timing & SequencePattern 4 of 8
Timer Cascade (Timed Sequence)
Chaining TON timers to step through a timed sequence
The pattern
Multiple TON (on-delay) timers are chained so that the done bit of timer N enables the coil of timer N+1 and simultaneously de-energises the output for step N. Each step occupies a time window defined by its TON preset. When the final timer's done bit fires, it resets the chain and the sequence repeats from step 1. The done bit of each timer in the chain also drives its corresponding output.
When it is used
Traffic light sequencing — the canonical example. Machine warm-up sequences with timed dwell phases. Wash cycle timers in a CIP or dishwash sequence. Alarm acknowledgement timeout windows. Any application where a series of outputs must each be active for a fixed duration in a repeating cycle.
Practice it in these scenarios
Pattern structure (concept only)
CountingPattern 5 of 8
Counter Latch (CTU/CTD)
Counting events and triggering logic at a threshold
The pattern
A CTU (count-up) instruction increments its accumulator by one on each rising edge of its count input. When the accumulator reaches the preset value, the done bit goes true. A CTD (count-down) decrements from the preset to zero. The accumulator can be read at any time for display or comparison logic. A reset coil sets the accumulator back to zero.
When it is used
Counting boxes on a conveyor and triggering a diverter or stop signal at the batch size. Counting pump starts for maintenance hour scheduling. Counting parts through a machine cycle to verify correct operation. Tracking occupancy (entry CTU − exit CTU = current count). Any scenario where cumulative events drive a threshold action.
Practice it in these scenarios
Pattern structure (concept only)
FoundationalPattern 6 of 8
SET/RESET Latch
Latching and unlatching a bit with separate coil instructions
The pattern
A SET (latch) coil instruction sets its bit true when its rung goes true and holds it true even when the rung goes false — the bit remains latched until a RESET (unlatch) instruction on a separate rung sets it false. Unlike a seal-in circuit, the SET/RESET latch is controlled by two completely independent rungs. In IEC syntax this is the S and R coil pair; in Allen-Bradley it is OTL (Output Latch) and OTU (Output Unlatch).
When it is used
Fault latch circuits where an alarm state must persist until an operator resets it — even across a power cycle if stored in retentive memory. Mode-select logic where pressing a mode button sets a mode bit and pressing another mode button resets it. Any scenario where set and reset conditions are physically or logically separate enough that combining them in a seal-in rung would be confusing.
Practice it in these scenarios
Pattern structure (concept only)
SafetyPattern 7 of 8
Safety Permissive Chain
Requiring all safety conditions to be clear before allowing a start
The pattern
A permissive is a condition that must be satisfied before a machine action is allowed. Multiple permissives are wired in series in the logic — each as a normally-closed contact for a fault bit, or a normally-open contact for a ready bit. Every permissive in the chain must be true simultaneously for the permissive rung output to be true. The permissive rung output then gates the start command. A single failed permissive blocks the entire chain.
When it is used
Boiler startup: purge complete AND gas pressure OK AND no flame present must all be true before pilot ignition is permitted. Conveyor start: guard door closed AND e-stop reset AND upstream conveyor running must all be true before the drive can start. Any machine with multiple independent safety or readiness conditions that must all be verified before motion is permitted.
Practice it in these scenarios
Pattern structure (concept only)
Timing & SequencePattern 8 of 8
State Machine (Step Sequencer)
Organising complex machine behaviour into named states with defined transitions
The pattern
A state machine assigns an integer step counter (or a set of mutually exclusive state bits) to represent which phase of the machine cycle is currently active. Each rung in the program is conditioned on the current step value. Transition logic advances the step counter when the exit conditions for the current step are met. Only one step is active at a time, and only the rungs for that step execute.
When it is used
Garage door controllers where the door can be Opening, Open, Closing, Closed, or Faulted. Batch mixer sequences where the machine moves through Fill, Mix, Heat, Hold, Drain, and Clean phases. Elevator controllers where the cab can be Idle, Moving Up, Moving Down, Door Opening, Door Open, or Door Closing. Any machine with a defined sequence of named operating modes where the active mode determines what the PLC should be doing.
Practice it in these scenarios
Pattern structure (concept only)
Why runnable wins
Runnable behavior teaches what a static screenshot cannot
A screenshot of a ladder diagram explains the structure but not the behaviour. When you run the same circuit in a live simulation and watch the seal-in contact hold the motor on after you release the Start button — or watch the interlock block the reverse contactor when the forward contactor is energised — the pattern shifts from something you recognise to something you understand. That difference is what the grader measures.
Every pattern is immediately runnable
Each pattern on this page links directly to a scenario in the catalogue. Open it in a new tab, write the rung, run it. The grader tests that your circuit behaves correctly under the test inputs — not just that it compiles.
Graded on behaviour, not structure
You can implement a seal-in as a parallel contact or as a SET coil. The grader does not care about the method — it tests whether the output stays true after the start input goes false and goes false when the stop input fires. Correct behaviour is the standard.
Pattern combinations in advanced scenarios
The advanced scenarios combine multiple patterns from this page. The elevator uses seal-in, interlock, state machine, and safety permissive chains together. Recognising the individual patterns inside the larger program is the skill industrial employers test in interviews.
Quick reference
All 8 patterns at a glance
Timing & Sequence
One-Shot / Edge Detection
Triggering logic on the rising or falling edge of a signal
Timing & Sequence
State Machine (Step Sequencer)
Organising complex machine behaviour into named states with defined transitions
Keep learning
Related resources
- PLC programming examples (blog post) — written explanations with circuit diagrams for selected programs from the catalogue.
- PLC projects — 20 curated browser-runnable projects for students, home practice, and portfolios.
- Ladder logic symbols — reference guide for every standard IEC and Allen-Bradley ladder symbol.
- PLC timers — deep dive into TON, TOF, and TP timers across IEC, Allen-Bradley, and Siemens syntax.
- PLC counters — CTU, CTD, and CTUD counter instructions with runnable exercises.
- Full scenario catalogue — 140 source-catalogued practice records with tier badges and pattern tags.
- Ladder logic vs structured text — when ladder patterns give way to structured text for complex control logic.
Stop reading examples. Start running them.
Run the first guided rung without an account, then use a free account to save progress and continue into the catalog.
Questions
Ladder logic examples FAQ
A ladder logic example demonstrates one pattern in isolation — seal-in, one-shot, timer cascade. A full ladder program combines multiple patterns to control a real machine. Learning the patterns individually before combining them is the standard industrial training approach: master the seal-in rung first, then apply it inside a larger conveyor drive program.
140 source-catalogued practice records. Built for browser practice.
No install or vendor license is needed to start. Build the first rung without an account.
Technical reference and worked-example guide
Ladder logic examples: implementation, evidence and troubleshooting
Direct answer
Ladder logic examples becomes useful when it connects process requirement, input states, output owner, memory, scan order, priority, timing, count, permissive, feedback, alarm, reset and restart policy with operator or field condition through rung continuity and stored state to command, independent feedback, alarm and acceptance evidence, then proves one start-stop, timer, counter and sequence example executed from a known initial state and explained scan by scan under normal, boundary, fault and recovery conditions. The objective is a repeatable engineering or learning result, not merely activity inside a page or tool.
This guide is written for pLC beginners and technicians studying start-stop, seal-in, interlock, timer, counter, sequence and alarm patterns before adapting them to a machine. The intended result is specific: the reader can explain each example as an input-state-output contract, identify its owned memory and test it at normal, boundary and fault conditions.
System map / 02
Six concepts that control the result
Treat these as connected checkpoints. Each checkpoint has an expected state, an observable state and a boundary to the next part of the system. That structure prevents a software indication from being mistaken for physical proof.
NODE 01observable
Define the operating contract
process requirement, input states, output owner, memory, scan order, priority, timing, count, permissive, feedback, alarm, reset and restart policy. For runnable ladder logic patterns with scan-by-scan acceptance tests, record the initial condition, actor, requested change, observable result and stopping condition before selecting a tool or implementation.
NODE 02observable
Map the evidence path
operator or field condition through rung continuity and stored state to command, independent feedback, alarm and acceptance evidence. Separate request, internal state, output or service, physical or user-visible result and independent feedback so each boundary can be inspected.
NODE 03observable
Prove normal operation
one start-stop, timer, counter and sequence example executed from a known initial state and explained scan by scan. Run more than one cycle from a known state and retain the values, timings or artifacts that demonstrate repeatability.
NODE 04observable
Exercise a boundary case
simultaneous start and stop, held input, exact preset, repeated edge, feedback failure, reset, mode change, power return and stale state. Choose minimum, maximum, simultaneous, delayed or restart conditions that reveal assumptions hidden by the happy path.
NODE 05observable
Diagnose a controlled fault
a requirement, contact-truth, state, scan-order, timing, count, output-owner, feedback or reset defect. Preserve the first symptom, divide the system at a measurable boundary and change one condition only after predicting the result.
NODE 06observable
Transfer and hand over
the selected pattern rewritten for the exact target and regression-tested against machine-specific requirements. Restore normal state, remove temporary changes, repeat affected checks and document which claims remain limited to the learning environment.
Procedure / 03
A six-step practice and commissioning workflow
Run the steps in order the first time. Later, the same structure becomes a diagnostic loop: define the expected condition, observe the boundary, interpret the difference and choose one proving action.
- 01
Write the acceptance case
Convert process requirement, input states, output owner, memory, scan order, priority, timing, count, permissive, feedback, alarm, reset and restart policy into initial conditions, one stimulus and observable pass criteria.
Evidence: Another person can repeat the case without guessing the intended result.
Avoid: Using page completion or an animation as the acceptance criterion.
- 02
Build the map
Document operator or field condition through rung continuity and stored state to command, independent feedback, alarm and acceptance evidence and name who owns each state or decision.
Evidence: Every request and result has a source, destination and useful inspection point.
Avoid: Using the same value as command, status and independent feedback.
- 03
Run the baseline
Apply one start-stop, timer, counter and sequence example executed from a known initial state and explained scan by scan from a clean start and record the expected evidence.
Evidence: Repeated runs produce the same bounded result.
Avoid: Changing several parameters before a baseline exists.
- 04
Challenge assumptions
Test simultaneous start and stop, held input, exact preset, repeated edge, feedback failure, reset, mode change, power return and stale state without changing the acceptance contract.
Evidence: Limits, timing and restart behavior reach defined states.
Avoid: Testing only one ideal sequence.
- 05
Isolate one failure
Introduce or analyse a requirement, contact-truth, state, scan-order, timing, count, output-owner, feedback or reset defect and locate the first disagreement.
Evidence: The proving action distinguishes the leading hypotheses.
Avoid: Resetting, forcing or replacing before evidence is retained.
- 06
Close the evidence loop
Complete the selected pattern rewritten for the exact target and regression-tested against machine-specific requirements and repeat the affected regression cases.
Evidence: Reference use is complete when inputs, assumptions, units or initial conditions are recorded and the result is independently checked at a useful boundary.
Avoid: Treating an acknowledged message or one successful rerun as handover.
Diagnostic matrix / 04
Symptoms, proving points and next actions
The table is a reasoning aid, not a parts-replacement chart. Preserve the initial symptom, inspect the named boundary and use the interpretation to choose the next controlled test. Site safety procedures and equipment manuals remain authoritative.
| Observed symptom | Inspect | Interpretation | Next proving action |
|---|---|---|---|
| The expected result is unclear | Requirement, initial state, actor, stimulus, units and pass condition | The technician, programmer and reviewer may be solving different versions of the task. | Rewrite one observable acceptance case before continuing. |
| Internal state changes but the outcome does not | Request, final owner, output or service boundary and independent feedback | A software or interface indication proves intent at one layer, not the complete outcome. | Trace the first boundary after the changing state. |
| Normal case passes but an edge case fails | Limits, timing, simultaneous events, reset and restart assumptions | The implementation contains a hidden assumption exposed by the changed condition. | Add the failed boundary as a permanent regression case. |
| The failure disappears after reset | Original symptom, histories, diagnostics, timestamps and active cause | Reset changed evidence or state without proving the initiating cause. | Reproduce under a controlled condition and preserve pre/post-event data. |
| Simulator and target disagree | Model boundary, software version, task timing, I/O behavior, data types and configuration | A learning model and the intended target do not share one of the recorded assumptions. | Reduce the case and verify against current target documentation. |
| The result cannot be explained | Prediction, observation, proving action, alternative hypotheses and limitations | Activity occurred but the evidence is not yet transferable or reviewable. | Have the learner defend the signal path and repeat a changed case. |
Product evidence / 05
What the browser practice can actually demonstrate
The page connects definitions and worked examples to runnable tools, explicit assumptions and repeatable checks so a formula or pattern can be challenged.
Where simulation stops
An example is not production-ready logic; real machines require target-platform semantics, risk controls, I/O design, diagnostics and witnessed commissioning.
Commissioning notebook / 06
Six cases that turn the concepts into evidence
Use these as written briefs rather than click-through instructions. For every case, state the expected condition before acting, retain the first useful observation and explain why the final result proves the requirement. A different program or component choice can still be correct when it produces the same bounded behavior and evidence.
Case 01
predict → observe → prove
Prove define the operating contract
Engineering context. process requirement, input states, output owner, memory, scan order, priority, timing, count, permissive, feedback, alarm, reset and restart policy. For runnable ladder logic patterns with scan-by-scan acceptance tests, record the initial condition, actor, requested change, observable result and stopping condition before selecting a tool or implementation. Begin with a written normal condition and identify which request, state, physical result or communication value will provide independent confirmation. Do not begin by changing the configuration; the initial state is part of the evidence and should remain reproducible.
Controlled setup. Use the “Write the acceptance case” stage of the workflow: convert process requirement, input states, output owner, memory, scan order, priority, timing, count, permissive, feedback, alarm, reset and restart policy into initial conditions, one stimulus and observable pass criteria. The acceptance record should show this result: another person can repeat the case without guessing the intended result. Record initial conditions, the exact stimulus and the observation point so another learner can repeat the case without relying on your memory.
Fault challenge. Introduce or analyse “The expected result is unclear” as one bounded deviation. Inspect requirement, initial state, actor, stimulus, units and pass condition The working interpretation is that the technician, programmer and reviewer may be solving different versions of the task. The next proving action is to rewrite one observable acceptance case before continuing. Change only one condition before observing the result, and preserve timestamps or measurements where timing matters.
Review and recovery. The most common trap here is using page completion or an animation as the acceptance criterion. After restoring the cause, repeat the normal case and at least one stop, timeout, disconnect or restart boundary relevant to this topic. Remove temporary forces and bypasses, return the model to a known state and retain the evidence that both operation and recovery are deliberate.
Explain it aloud: What ladder logic examples should beginners learn first? A defensible short answer is: Learn input-to-output truth, stop-priority start-stop, seal-in state, interlocks, TON timing, CTU counting, step sequences, alarms and feedback mismatch in that order.
Case 02
predict → observe → prove
Prove map the evidence path
Engineering context. operator or field condition through rung continuity and stored state to command, independent feedback, alarm and acceptance evidence. Separate request, internal state, output or service, physical or user-visible result and independent feedback so each boundary can be inspected. Begin with a written normal condition and identify which request, state, physical result or communication value will provide independent confirmation. Do not begin by changing the configuration; the initial state is part of the evidence and should remain reproducible.
Controlled setup. Use the “Build the map” stage of the workflow: document operator or field condition through rung continuity and stored state to command, independent feedback, alarm and acceptance evidence and name who owns each state or decision. The acceptance record should show this result: every request and result has a source, destination and useful inspection point. Record initial conditions, the exact stimulus and the observation point so another learner can repeat the case without relying on your memory.
Fault challenge. Introduce or analyse “Internal state changes but the outcome does not” as one bounded deviation. Inspect request, final owner, output or service boundary and independent feedback The working interpretation is that a software or interface indication proves intent at one layer, not the complete outcome. The next proving action is to trace the first boundary after the changing state. Change only one condition before observing the result, and preserve timestamps or measurements where timing matters.
Review and recovery. The most common trap here is using the same value as command, status and independent feedback. After restoring the cause, repeat the normal case and at least one stop, timeout, disconnect or restart boundary relevant to this topic. Remove temporary forces and bypasses, return the model to a known state and retain the evidence that both operation and recovery are deliberate.
Explain it aloud: How do I test a ladder logic example? A defensible short answer is: Declare the initial state and expected outputs, then exercise normal operation, simultaneous inputs, exact time or count boundaries, reset, restart and at least one failed-feedback case.
Case 03
predict → observe → prove
Prove prove normal operation
Engineering context. one start-stop, timer, counter and sequence example executed from a known initial state and explained scan by scan. Run more than one cycle from a known state and retain the values, timings or artifacts that demonstrate repeatability. Begin with a written normal condition and identify which request, state, physical result or communication value will provide independent confirmation. Do not begin by changing the configuration; the initial state is part of the evidence and should remain reproducible.
Controlled setup. Use the “Run the baseline” stage of the workflow: apply one start-stop, timer, counter and sequence example executed from a known initial state and explained scan by scan from a clean start and record the expected evidence. The acceptance record should show this result: repeated runs produce the same bounded result. Record initial conditions, the exact stimulus and the observation point so another learner can repeat the case without relying on your memory.
Fault challenge. Introduce or analyse “Normal case passes but an edge case fails” as one bounded deviation. Inspect limits, timing, simultaneous events, reset and restart assumptions The working interpretation is that the implementation contains a hidden assumption exposed by the changed condition. The next proving action is to add the failed boundary as a permanent regression case. Change only one condition before observing the result, and preserve timestamps or measurements where timing matters.
Review and recovery. The most common trap here is changing several parameters before a baseline exists. After restoring the cause, repeat the normal case and at least one stop, timeout, disconnect or restart boundary relevant to this topic. Remove temporary forces and bypasses, return the model to a known state and retain the evidence that both operation and recovery are deliberate.
Explain it aloud: What should I learn first about runnable ladder logic patterns with scan-by-scan acceptance tests? A defensible short answer is: Start with the operating contract and evidence path: process requirement, input states, output owner, memory, scan order, priority, timing, count, permissive, feedback, alarm, reset and restart policy, followed by operator or field condition through rung continuity and stored state to command, independent feedback, alarm and acceptance evidence. Add advanced features only after the baseline is predictable.
Case 04
predict → observe → prove
Prove exercise a boundary case
Engineering context. simultaneous start and stop, held input, exact preset, repeated edge, feedback failure, reset, mode change, power return and stale state. Choose minimum, maximum, simultaneous, delayed or restart conditions that reveal assumptions hidden by the happy path. Begin with a written normal condition and identify which request, state, physical result or communication value will provide independent confirmation. Do not begin by changing the configuration; the initial state is part of the evidence and should remain reproducible.
Controlled setup. Use the “Challenge assumptions” stage of the workflow: test simultaneous start and stop, held input, exact preset, repeated edge, feedback failure, reset, mode change, power return and stale state without changing the acceptance contract. The acceptance record should show this result: limits, timing and restart behavior reach defined states. Record initial conditions, the exact stimulus and the observation point so another learner can repeat the case without relying on your memory.
Fault challenge. Introduce or analyse “The failure disappears after reset” as one bounded deviation. Inspect original symptom, histories, diagnostics, timestamps and active cause The working interpretation is that reset changed evidence or state without proving the initiating cause. The next proving action is to reproduce under a controlled condition and preserve pre/post-event data. Change only one condition before observing the result, and preserve timestamps or measurements where timing matters.
Review and recovery. The most common trap here is testing only one ideal sequence. After restoring the cause, repeat the normal case and at least one stop, timeout, disconnect or restart boundary relevant to this topic. Remove temporary forces and bypasses, return the model to a known state and retain the evidence that both operation and recovery are deliberate.
Explain it aloud: How do I practise runnable ladder logic patterns with scan-by-scan acceptance tests effectively? A defensible short answer is: Use short cases with known initial conditions, a written prediction, one action and an observable result. Then alter a boundary or fault and explain why the evidence changed.
Case 05
predict → observe → prove
Prove diagnose a controlled fault
Engineering context. a requirement, contact-truth, state, scan-order, timing, count, output-owner, feedback or reset defect. Preserve the first symptom, divide the system at a measurable boundary and change one condition only after predicting the result. Begin with a written normal condition and identify which request, state, physical result or communication value will provide independent confirmation. Do not begin by changing the configuration; the initial state is part of the evidence and should remain reproducible.
Controlled setup. Use the “Isolate one failure” stage of the workflow: introduce or analyse a requirement, contact-truth, state, scan-order, timing, count, output-owner, feedback or reset defect and locate the first disagreement. The acceptance record should show this result: the proving action distinguishes the leading hypotheses. Record initial conditions, the exact stimulus and the observation point so another learner can repeat the case without relying on your memory.
Fault challenge. Introduce or analyse “Simulator and target disagree” as one bounded deviation. Inspect model boundary, software version, task timing, I/O behavior, data types and configuration The working interpretation is that a learning model and the intended target do not share one of the recorded assumptions. The next proving action is to reduce the case and verify against current target documentation. Change only one condition before observing the result, and preserve timestamps or measurements where timing matters.
Review and recovery. The most common trap here is resetting, forcing or replacing before evidence is retained. After restoring the cause, repeat the normal case and at least one stop, timeout, disconnect or restart boundary relevant to this topic. Remove temporary forces and bypasses, return the model to a known state and retain the evidence that both operation and recovery are deliberate.
Explain it aloud: What counts as proof of competence? A defensible short answer is: A repeatable artifact or system result plus an explanation of the signal path is stronger than time spent, screenshots or a copied answer. Physical competence requires separate supervised evidence.
Case 06
predict → observe → prove
Prove transfer and hand over
Engineering context. the selected pattern rewritten for the exact target and regression-tested against machine-specific requirements. Restore normal state, remove temporary changes, repeat affected checks and document which claims remain limited to the learning environment. Begin with a written normal condition and identify which request, state, physical result or communication value will provide independent confirmation. Do not begin by changing the configuration; the initial state is part of the evidence and should remain reproducible.
Controlled setup. Use the “Close the evidence loop” stage of the workflow: complete the selected pattern rewritten for the exact target and regression-tested against machine-specific requirements and repeat the affected regression cases. The acceptance record should show this result: reference use is complete when inputs, assumptions, units or initial conditions are recorded and the result is independently checked at a useful boundary. Record initial conditions, the exact stimulus and the observation point so another learner can repeat the case without relying on your memory.
Fault challenge. Introduce or analyse “The result cannot be explained” as one bounded deviation. Inspect prediction, observation, proving action, alternative hypotheses and limitations The working interpretation is that activity occurred but the evidence is not yet transferable or reviewable. The next proving action is to have the learner defend the signal path and repeat a changed case. Change only one condition before observing the result, and preserve timestamps or measurements where timing matters.
Review and recovery. The most common trap here is treating an acknowledged message or one successful rerun as handover. After restoring the cause, repeat the normal case and at least one stop, timeout, disconnect or restart boundary relevant to this topic. Remove temporary forces and bypasses, return the model to a known state and retain the evidence that both operation and recovery are deliberate.
Explain it aloud: Why test faults and restart behavior? A defensible short answer is: Because a requirement, contact-truth, state, scan-order, timing, count, output-owner, feedback or reset defect or simultaneous start and stop, held input, exact preset, repeated edge, feedback failure, reset, mode change, power return and stale state can expose assumptions that never appear during ideal startup and steady operation.
Answer surface / 07
Questions people ask about Ladder logic examples
These concise answers define the operating, training and product boundaries most often missed in broad summaries. The full workflow and diagnostic table above provide the evidence behind them.
What ladder logic examples should beginners learn first?
Learn input-to-output truth, stop-priority start-stop, seal-in state, interlocks, TON timing, CTU counting, step sequences, alarms and feedback mismatch in that order.
How do I test a ladder logic example?
Declare the initial state and expected outputs, then exercise normal operation, simultaneous inputs, exact time or count boundaries, reset, restart and at least one failed-feedback case.
What should I learn first about runnable ladder logic patterns with scan-by-scan acceptance tests?
Start with the operating contract and evidence path: process requirement, input states, output owner, memory, scan order, priority, timing, count, permissive, feedback, alarm, reset and restart policy, followed by operator or field condition through rung continuity and stored state to command, independent feedback, alarm and acceptance evidence. Add advanced features only after the baseline is predictable.
How do I practise runnable ladder logic patterns with scan-by-scan acceptance tests effectively?
Use short cases with known initial conditions, a written prediction, one action and an observable result. Then alter a boundary or fault and explain why the evidence changed.
What counts as proof of competence?
A repeatable artifact or system result plus an explanation of the signal path is stronger than time spent, screenshots or a copied answer. Physical competence requires separate supervised evidence.
Why test faults and restart behavior?
Because a requirement, contact-truth, state, scan-order, timing, count, output-owner, feedback or reset defect or simultaneous start and stop, held input, exact preset, repeated edge, feedback failure, reset, mode change, power return and stale state can expose assumptions that never appear during ideal startup and steady operation.
Can browser practice replace official software or hardware?
No. It can build concepts and diagnostic reasoning. Exact firmware, I/O electrical behavior, networking, safety and commissioning require current official tools, documentation and target equipment.
How should progress be documented?
Keep the requirement, initial state, program or configuration, observed values, fault hypothesis, proving action, recovery result and a concise limitations statement.
Continue the signal path / 08
Related practice and reference pages
PLC practice problemsContinue from process requirement, input states, output owner, memory, scan order, priority, timing, count, permissive, feedback, alarm, reset and restart policy.Ladder logic simulatorContinue from operator or field condition through rung continuity and stored state to command, independent feedback, alarm and acceptance evidence.PLC program testingContinue from one start-stop, timer, counter and sequence example executed from a known initial state and explained scan by scan.PLC instruction referenceContinue from simultaneous start and stop, held input, exact preset, repeated edge, feedback failure, reset, mode change, power return and stale state.Explore plc projectsContinue from a requirement, contact-truth, state, scan-order, timing, count, output-owner, feedback or reset defect.Thermocouple sensor guide field guideContinue from the selected pattern rewritten for the exact target and regression-tested against machine-specific requirements.
Primary and first-party references
PLC code and example path
Move from one instruction to a tested control pattern
Read the instruction behavior, inspect a complete pattern, run its edge cases and then adapt it as a project.