PLC Simulator
PLC field notesbeginner

Basic PLC Programming: The 20 Rungs You Will Use for the Rest of Your Career

Basic PLC programming is a surprisingly small set of patterns — maybe twenty rungs — that appear in almost every real program. Learn them in the right order, in the browser, with automated tests, and you will never have to re-learn the fundamentals.

PLC Simulation Software11 min read

Basic PLC programming: the 20 rungs you will use forever

Basic PLC programming is a much smaller subject than the textbooks suggest. Strip out the vendor-specific bloat, the SCADA integration, the OOP-adjacent UDT discussions, and what's left is about twenty rungs — patterns you'll see in every real program, from a two-button motor starter to a pharmaceutical batch reactor. Learn them properly, in the right order, and you will never have to re-learn the fundamentals.

This post is the back-of-an-envelope course. If you follow it end to end, you'll be dangerous in three weeks.

Three things to learn before any rung

Before we write a single contact, three mental models that every sentence below assumes you have. Skip these and nothing else will make sense.

The scan cycle

A PLC repeats three steps sixty times a second:

  1. Read every input into the input image table.
  2. Solve the ladder, top to bottom.
  3. Write the output image table back to physical outputs.

This order matters. It's why your output is "one scan late" relative to its input. It's why a falling edge of Stop can't trigger Run on the same scan. If this confuses you, read our scan cycle explainer before continuing.

Normally open vs normally closed

An input [ ] (XIC in Rockwell) is TRUE when its signal is TRUE. An input [/] (XIO) is TRUE when its signal is FALSE. A Stop button on a real machine is always wired normally-closed and read with [ ] — because if the wire gets cut, your program sees a disconnected button as if Stop is pressed, which is the safe failure mode. Fail safe is not a suggestion.

Coils vs contacts

A coil writes a bit. A contact reads a bit. You can have many contacts reading a bit, but in a well-written program only one coil writes each bit. (There are exceptions — SET / RESET pairs, latches — but they're explicit, not accidental.)

With those three in your head, on to the twenty rungs.

Rung 1 — start / stop with seal-in

Rung 1 — start/stop with seal-in

The first rung is the only rung that absolutely must be burned into muscle memory. In IEC 61131-3:

| Start  Stop                         Run |
|---[ ]---[/]-----+-----------------( )---|
|                 |                        |
| Run             |                        |
|---[ ]-----------+                        |

The seal-in — Run's own contact, in parallel with Start — is what keeps the motor running after the operator releases the Start button. The [/] on Stop is there because Stop is wired NC in the field (see above). If you get nothing else from this post, get this rung.

Practice in our Motor Start/Stop scenario. Free tier. 20 minutes.

Rung 2 — forward / reverse with interlock

Rung 2 — forward/reverse with interlock

Now do it for a motor that runs in two directions. The trick is that Fwd and Rev contactors must never both be on — if they are, you get a line-to-line short. The interlock is two contacts:

| Fwd  Rev_Out                        Fwd_Out |
|--[ ]---[/]------------------------(     )---|
|                                              |
| Rev  Fwd_Out                        Rev_Out |
|--[ ]---[/]------------------------(     )---|

Each direction reads "the OTHER direction's output is NOT on" as a precondition. A normally-open aux contact on the physical contactor can add a hardware-level interlock — belt and braces.

Practice in Forward/Reverse Motor. Basic tier.

Rung 3 — jog / run

A real operator wants two modes:

  • Jog — motor runs only while the button is held.
  • Run — motor runs continuously, same start/stop pattern as Rung 1.

You need a selector switch (a two-position input in software) to decide which mode the Start button invokes. The rung:

| Mode_Run  Start  Stop                Run |
|---[ ]-------[ ]---[/]-+--------------( )--|
|  Mode_Run  Run        |                    |
|---[ ]-------[ ]-------+                    |
|                                            |
| Mode_Jog  Start  Stop                Jog  |
|---[/]-------[ ]---[/]----------------( )---|

Note Run has a seal-in, Jog does not. That's what makes it jog.

Practice in Jog / Run Motor Control.

Rungs 4–8 — timers

Five rungs, five timer patterns. Learn them all or you'll misuse TON for something that needs TP.

Reference tableSwipe
RungPatternPrimary use
4TON — delay ONWait X seconds after input before acting
5TOF — delay OFFKeep acting X seconds after input disappears
6TP — pulseEmit a fixed-length pulse on rising edge
7Self-resetting TONFree-running oscillator (blinker)
8Two TONs chainedSequence two delayed actions

Our timers in PLC programming deep-dive walks each of these rung-by-rung with waveforms. It's the single most important reference in basic PLC programming.

Rungs 9–10 — counters

Two rungs cover the useful counter patterns:

  • CTU counting rising edges of a sensor → output when preset reached
  • CTUD counting up on conveyor entry, down on conveyor exit → "how many parts on the belt right now"

Reset logic is the part people get wrong. CTU.Reset is latched as long as the reset input is TRUE, so if you tie it to a sensor that chatters, your counter never accumulates. Debounce it — with a short TON — or use a one-shot.

Practice in Conveyor Sort.

Rungs 11–15 — state machines with phase variables

The 20 basic rungs, in the order to learn them

A bottling line doesn't have one rung. It has six phases — idle, infeed, fill, cap, label, discharge — and transitions between them. The novice approach is nested IF-THEN-ELSE ladder, which works for three states and collapses at five. The professional approach is an explicit PHASE integer variable and one rung per transition:

| PHASE=0  Start_Cycle                PHASE:=1 |
|---[EQ]-----[ ]-----------------------(MOV)----|
|                                                |
| PHASE=1  Fill_Complete              PHASE:=2 |
|---[EQ]----[ ]------------------------(MOV)----|

Each phase is a number. Each transition is a one-rung rule. Adding a new phase is one rung, not a ladder rewrite.

Practice in CIP Sequence Controller.

Rungs 16–17 — set / reset (latch / unlatch)

Use with care. Set and reset coils let a bit stay on after the rung that set it goes false — useful for phase transitions, dangerous if overused.

| Phase_Complete                       Phase_Done |
|------[ ]------------------------------(S)--------|
|                                                   |
| Reset_Cycle                          Phase_Done  |
|------[ ]------------------------------(R)--------|

Rule of thumb: for every S coil in your program, you must be able to point at the corresponding R coil. If you can't, you will one day find a latched bit and spend an afternoon hunting its setter.

Rungs 18–19 — one-shots (rising/falling edge)

A one-shot is TRUE for exactly one scan when its input rises (or falls). Essential for:

  • Incrementing a counter exactly once per operator button press
  • Triggering a recipe step on operator acknowledgement
  • Resetting a latched bit without holding the reset TRUE

In Rockwell: ONS. In IEC: R_TRIG / F_TRIG function blocks.

| Button   ButtonLast                   PulseOne |
|---[ ]-----[/]-------------------------( )-------|
|                                                  |
| Button                               ButtonLast |
|---[ ]---------------------------------( )-------|

Rung 20 — fault handling and reset

The rung your program never has until the first incident:

| Any_Fault                             Fault_Latch |
|-----[ ]---------------------------------(S)-------|
|                                                    |
| Reset_PB   Fault_Latch                Fault_Latch |
|------[ ]-------[ ]-----------------------(R)------|

Fault conditions latch. Operator acknowledges with a physical reset button. Don't auto-reset faults — the whole point of a fault is to force a human to look at it.

What you can do when you're done

When you're done with basics, you can do this

Those twenty rungs cover roughly 80% of what you'll write in the first five years of a PLC career. The remaining 20% is dialect-specific (AOIs, FBs, SCL libraries), process-specific (PID, analog scaling), or infrastructure (SCADA integration, recipe management).

At this point:

  • You can debug a race condition by counting scan cycles, not guessing.
  • You can read an RSLogix, Studio 5000, or TIA Portal project and find the start-stop rung in the first minute.
  • You can walk into a maintenance-tech interview and answer "how does a seal-in work" without notes.
  • You can move to PID, sequencers, and multi-step batch processes with a solid foundation.

Where to learn this for real

  1. Sign up free. Two scenarios, three lessons, a quiz, no card.
  2. Open Motor Start/Stop. Write Rung 1 until the tests pass. This is 80% of basic PLC programming.
  3. Move to Forward/Reverse Motor. Rung 2.
  4. Work through the 12-week PLC course. Rungs 3–20 are covered in Weeks 3–6.

Three weeks, the first one free. That's the whole basic PLC programming curriculum.

FAQ

Is PLC programming hard to learn?

Basic PLC programming is one of the easiest professional skills to pick up — four contacts, one coil, a handful of timer/counter blocks, and scan-cycle discipline. Advanced topics (PID, safety, multi-vendor portability) take years. The basics take weeks.

Is there a free basic PLC programming course?

Yes — our free tier covers the foundational rungs (Motor Start/Stop, Ladder Logic Basics). Full 40-scenario access is USD 99/year on the Basic plan.

How long does basic PLC programming take to learn?

Three weeks at 8 hours a week is enough for the 20 rungs above. Real-world fluency — reading a complex project quickly, spotting bad patterns, debugging intuitively — takes 6–12 months of daily practice.

What is the best programming language to start with on a PLC?

Ladder. It's the most common in industry, the easiest to learn visually, and it introduces you to scan-cycle thinking without syntactic distractions. Learn structured text second, and only once you're fluent in ladder. Our ladder-vs-ST post has the full comparison.

Do I need a PLC to practise basic PLC programming?

No. Everything in this post can be practised in our browser simulator against the same IEC 61131-3 semantics your physical PLC will run. Skills transfer 1:1.

Next steps

ShareX / TwitterLinkedIn

From reading to running logic

Practice this yourself in the simulator

Start with guided PLC practice in your browser. No install and no credit card required.

Start practising free

Continue learning

Related field notes

All articles
beginner
fundamentals

PLC Programming for Absolute Beginners (2026 Roadmap)

A gentle, non-jargon guide to PLC programming for people with no electrical background. Covers the scan cycle, your first rung, the five things that will confuse you, and a four-week starter plan that you can follow in a browser without installing anything.

9 min read
simulator
online

PLC Programming Online Simulator: Browser-First, No Install, Real Code

An online PLC simulator is a browser-based environment where you write ladder logic or structured text, wire it to simulated I/O, and run it against machine physics without any install. Here's what to look for, who it's for, and what a good one feels like in 2026.

12 min read
training
career

The Complete PLC Programming Course for 2026 (Self-Paced, Browser-First)

A 12-week PLC programming course that takes you from zero electrical background to writing production-grade ladder logic for Allen-Bradley, Siemens, and IEC PLCs. Self-paced, browser-based, no install, no vendor lock-in.

14 min read

Competency and practice field guide

Basic PLC programming guide: implementation, evidence and troubleshooting

Direct answer

Basic PLC programming guide becomes useful when it connects machine requirement, initial state, inputs, outputs, independent feedback, scan cycle, boolean conditions, memory, timer, counter, state, stop priority and reset with field condition through input image, instruction evaluation, internal state, output command, interface device, actuator and physical feedback, then proves a start-stop or sequence program produces repeatable start, run, stop and reset behavior from a known state 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 complete beginners learning scan execution, Boolean logic, start-stop control, timers, counters, state and diagnostics. The intended result is specific: the learner can translate one machine requirement into tags and logic, predict a scan, run normal and changed cases and explain the physical result.

an adult PLC learner explaining a tested program, fault record and practical assessment evidence to an instructor while studying PLC programming fundamentals from I/O through tested machine behavior
The scene connects PLC programming fundamentals from I/O through tested machine behavior to declared conditions, safe boundaries, observable evidence and a repeatable result.

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

machine requirement, initial state, inputs, outputs, independent feedback, scan cycle, Boolean conditions, memory, timer, counter, state, stop priority and reset. For PLC programming fundamentals from I/O through tested machine behavior, record the initial condition, actor, requested change, observable result and stopping condition before selecting a tool or implementation.

NODE 02observable

Map the evidence path

field condition through input image, instruction evaluation, internal state, output command, interface device, actuator and physical feedback. 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

a start-stop or sequence program produces repeatable start, run, stop and reset behavior from a known state. 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 buttons, signal chatter, exact timer preset, counter rollover, lost feedback, program restart and power return. Choose minimum, maximum, simultaneous, delayed or restart conditions that reveal assumptions hidden by the happy path.

NODE 05observable

Diagnose a controlled fault

a requirement, input, mapping, logic, memory, timing, output, actuator or feedback mismatch. 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 behavior documented and recreated in the intended controller under supervised equipment tests. 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.

  1. 01

    Write the acceptance case

    Convert machine requirement, initial state, inputs, outputs, independent feedback, scan cycle, boolean conditions, memory, timer, counter, state, stop priority and reset 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.

  2. 02

    Build the map

    Document field condition through input image, instruction evaluation, internal state, output command, interface device, actuator and physical feedback 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.

  3. 03

    Run the baseline

    Apply a start-stop or sequence program produces repeatable start, run, stop and reset behavior from a known state 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.

  4. 04

    Challenge assumptions

    Test simultaneous buttons, signal chatter, exact timer preset, counter rollover, lost feedback, program restart and power return without changing the acceptance contract.

    Evidence: Limits, timing and restart behavior reach defined states.

    Avoid: Testing only one ideal sequence.

  5. 05

    Isolate one failure

    Introduce or analyse a requirement, input, mapping, logic, memory, timing, output, actuator or feedback mismatch and locate the first disagreement.

    Evidence: The proving action distinguishes the leading hypotheses.

    Avoid: Resetting, forcing or replacing before evidence is retained.

  6. 06

    Close the evidence loop

    Complete the behavior documented and recreated in the intended controller under supervised equipment tests and repeat the affected regression cases.

    Evidence: A learner completes the surface by explaining the result, passing a changed case and identifying what still requires supervised target-equipment practice.

    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.

Diagnostic symptoms, inspection points, interpretations and next actions for Basic PLC programming guide: implementation, evidence and troubleshooting
Observed symptomInspectInterpretationNext proving action
The expected result is unclearRequirement, initial state, actor, stimulus, units and pass conditionThe learner, instructor and assessor may be solving different versions of the task.Rewrite one observable acceptance case before continuing.
Internal state changes but the outcome does notRequest, final owner, output or service boundary and independent feedbackA 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 failsLimits, timing, simultaneous events, reset and restart assumptionsThe implementation contains a hidden assumption exposed by the changed condition.Add the failed boundary as a permanent regression case.
The failure disappears after resetOriginal symptom, histories, diagnostics, timestamps and active causeReset changed evidence or state without proving the initiating cause.Reproduce under a controlled condition and preserve pre/post-event data.
Simulator and target disagreeModel boundary, software version, task timing, I/O behavior, data types and configurationA 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 explainedPrediction, observation, proving action, alternative hypotheses and limitationsActivity 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 browser platform can retain programs, scenario results, attempts and observable machine state so practice is attached to evidence rather than seat time alone.

Where simulation stops

A beginner guide cannot teach electrical authorization, complete vendor syntax, safety validation or commissioning; exact target behavior needs official tools and hardware.

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. machine requirement, initial state, inputs, outputs, independent feedback, scan cycle, Boolean conditions, memory, timer, counter, state, stop priority and reset. For PLC programming fundamentals from I/O through tested machine behavior, 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 machine requirement, initial state, inputs, outputs, independent feedback, scan cycle, boolean conditions, memory, timer, counter, state, stop priority and reset 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 learner, instructor and assessor 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 should a PLC programming beginner learn first? A defensible short answer is: Start with electrical input states, scan behavior, normally open and closed logic, one output path and independent feedback before adding timers and sequences.

Case 02

predict → observe → prove

Prove map the evidence path

Engineering context. field condition through input image, instruction evaluation, internal state, output command, interface device, actuator and physical feedback. 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 field condition through input image, instruction evaluation, internal state, output command, interface device, actuator and physical feedback 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 know whether a PLC program works? A defensible short answer is: Write observable acceptance cases and test normal, stop, boundary, fault, reset and restart behavior—not only whether the code compiles.

Case 03

predict → observe → prove

Prove prove normal operation

Engineering context. a start-stop or sequence program produces repeatable start, run, stop and reset behavior from a known state. 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 a start-stop or sequence program produces repeatable start, run, stop and reset behavior from a known state 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 PLC programming fundamentals from I/O through tested machine behavior? A defensible short answer is: Start with the operating contract and evidence path: machine requirement, initial state, inputs, outputs, independent feedback, scan cycle, boolean conditions, memory, timer, counter, state, stop priority and reset, followed by field condition through input image, instruction evaluation, internal state, output command, interface device, actuator and physical feedback. Add advanced features only after the baseline is predictable.

Case 04

predict → observe → prove

Prove exercise a boundary case

Engineering context. simultaneous buttons, signal chatter, exact timer preset, counter rollover, lost feedback, program restart and power return. 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 buttons, signal chatter, exact timer preset, counter rollover, lost feedback, program restart and power return 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 PLC programming fundamentals from I/O through tested machine behavior 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, input, mapping, logic, memory, timing, output, actuator or feedback mismatch. 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, input, mapping, logic, memory, timing, output, actuator or feedback mismatch 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 behavior documented and recreated in the intended controller under supervised equipment tests. 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 behavior documented and recreated in the intended controller under supervised equipment tests and repeat the affected regression cases. The acceptance record should show this result: a learner completes the surface by explaining the result, passing a changed case and identifying what still requires supervised target-equipment practice. 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, input, mapping, logic, memory, timing, output, actuator or feedback mismatch or simultaneous buttons, signal chatter, exact timer preset, counter rollover, lost feedback, program restart and power return can expose assumptions that never appear during ideal startup and steady operation.

Answer surface / 07

Questions people ask about Basic PLC programming guide

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 should a PLC programming beginner learn first?

Start with electrical input states, scan behavior, normally open and closed logic, one output path and independent feedback before adding timers and sequences.

How do I know whether a PLC program works?

Write observable acceptance cases and test normal, stop, boundary, fault, reset and restart behavior—not only whether the code compiles.

What should I learn first about PLC programming fundamentals from I/O through tested machine behavior?

Start with the operating contract and evidence path: machine requirement, initial state, inputs, outputs, independent feedback, scan cycle, boolean conditions, memory, timer, counter, state, stop priority and reset, followed by field condition through input image, instruction evaluation, internal state, output command, interface device, actuator and physical feedback. Add advanced features only after the baseline is predictable.

How do I practise PLC programming fundamentals from I/O through tested machine behavior 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, input, mapping, logic, memory, timing, output, actuator or feedback mismatch or simultaneous buttons, signal chatter, exact timer preset, counter rollover, lost feedback, program restart and power return 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.