learn · South Africa
Ladder logic basics — read and write your first rung
A practical ladder logic basics tutorial. Contacts, coils, branches, the scan cycle, and a first start-stop rung — written for South African PLC learners.
Ladder logic basics begin with three questions: what condition is being tested, what value is being written, and when does the program evaluate it? Contacts test Boolean values, branches combine conditions, and coils or other instructions act on the result. The familiar ladder drawing is a programming notation; it is not a wiring diagram showing electrical power flowing through your computer.
This tutorial uses fictional Boolean variables and a virtual indicator so you can learn the reasoning without treating an introductory example as a machine-control or safety design. You will work through contact truth tables, AND and OR branches, a state-holding equation and changed-condition tests. Try related concepts in the browser PLC learning environment, checking the instructions supported by that environment before implementing an exercise.
Read a rung as a statement about data
A rung connects conditions to an operation. Instead of saying “electricity reaches the coil”, say “these conditions evaluate true, so this instruction writes the specified value”. That wording helps separate the program from the device it may eventually control.
For example, the requirement “show the virtual Ready indicator when MaterialAvailable and StationEnabled are both true” contains two Boolean conditions and one result. Each name needs a definition. MaterialAvailable is a value supplied by this learning model; it is not proof that a physical sensor is healthy or correctly connected.
Use descriptive names while learning. An address such as an input bit can identify storage, but it does not explain the meaning assigned to that bit. Keep a small table with the variable, its purpose, its source and the meaning of true. That table makes a rung easier to review than an unexplained collection of addresses.
The contacts and coils reference develops the instruction vocabulary. Read the documentation for the exact controller and instruction when moving beyond the declared learning model.
Contacts test values; they do not describe the physical switch
A positive contact passes a true logical condition when its referenced Boolean value is true. A negated contact passes a true logical condition when the referenced value is false. Rockwell uses XIC and XIO names for these familiar bit tests; its bit-instruction documentation is the primary reference for that product's instruction set.
| Referenced Boolean value | Positive contact result | Negated contact result |
|---|---|---|
| False | False | True |
| True | True | False |
The truth table is about program data. A physical device's normal state, its wiring, the input channel and the program's interpretation are related but distinct. You cannot select a contact instruction correctly merely because a button is described as normally open or normally closed. First establish what value the program receives for each relevant condition.
For this tutorial, define StopRequest as true when the fictional user requests the indicator to stop. A negated test of StopRequest is therefore true when no stop is requested. If another exercise instead uses ContinueAllowed, true might mean the process may continue, and a positive test could express that condition. Neither name establishes a physical circuit design.
Keep safety functions out of this beginner inference. An ordinary Boolean example does not establish the design, diagnostic coverage or validation of an emergency-stop system. The safety PLC introduction is a separate learning topic with different requirements.
Series conditions express AND
When two simple contact conditions are in series, both must be true for the path to be true. In the Ready-indicator example, the Boolean relationship is Ready = MaterialAvailable AND StationEnabled. The equals sign here describes the mathematical relationship, not a promise that every editor accepts this text as source code.
| MaterialAvailable | StationEnabled | Ready |
|---|---|---|
| False | False | False |
| False | True | False |
| True | False | False |
| True | True | True |
Test every row before adding complexity. A single successful example, with both inputs true, does not prove the intended AND relationship. An accidental OR would also pass that one case. The two mixed-input rows distinguish the designs and are therefore valuable tests.
Read a longer series path one condition at a time. If the result is false, identify the first condition you cannot currently establish as true, then inspect its meaning and source. Do not simply remove it to make the result change. A condition may be correctly preventing the requested behaviour.
Parallel paths express OR
For simple Boolean contact networks, alternative parallel paths represent OR. Define a virtual StudyLamp that may be requested by either ManualRequest or LessonRequest. Under that brief, either true request is sufficient, and both false requests produce a false result.
Now add a shared condition: the lamp may be enabled only while SessionActive is true. The intended relationship becomes (ManualRequest OR LessonRequest) AND SessionActive. The parentheses matter. If SessionActive is applied to only one branch, the other request may bypass it.
| ManualRequest | LessonRequest | SessionActive | StudyLamp |
|---|---|---|---|
| False | False | True | False |
| True | False | True | True |
| False | True | True | True |
| True | True | True | True |
| True | False | False | False |
| False | True | False | False |
These selected cases test the alternative requests and the shared condition. They are not the complete eight-row truth table; add the two missing combinations yourself and predict their results. Explain why both must also produce false when SessionActive is false.
When reviewing a drawn rung, identify where the branches rejoin and which conditions apply after that point. The visual position of a contact should agree with the Boolean grouping you intended. If the editor has a different layout or execution convention, verify it in that editor rather than relying on an approximate ASCII drawing.
A normal coil and a set/reset operation do different jobs
In the simple model used here, a normal coil writes the evaluated Boolean result whenever that instruction executes. A false result writes false. A set-style operation can set a value when its condition is true without necessarily clearing it when the condition later becomes false. A reset-style operation provides a corresponding clearing action under its specified condition.
These are related concepts across environments, but exact instruction behaviour, prescan handling and retained data need platform-specific documentation. Do not assume that a graphical set/reset instruction, an SR function block and another vendor's latch instruction are interchangeable in every circumstance.
Before choosing an operation, write the required state transitions. Should the indicator follow a condition immediately, remain on after a momentary request, or remember a state across a particular interruption? Those are different requirements. Select and test an implementation against the one you actually need.
The set/reset reference and latching tutorial explore persistent logical state. For a first lesson, make the initial value and the clearing condition explicit. A remembered value without a documented reset or initialisation rule is difficult to assess.
A worked seal-in example with an explicit model
The following example controls only a virtual indicator called Active. The learning model executes the equation once per step, using the previous Active value as state. StartRequest and StopRequest are Boolean inputs. Initially Active is false. StopRequest has priority over StartRequest.
The equation is nextActive = (StartRequest OR previousActive) AND NOT StopRequest. A seal-in branch is one graphical way to represent the previous-state term in an appropriate ladder environment. This equation is not a safety function or a complete motor-control design.
| Step | StartRequest | StopRequest | Active before step | Active after step |
|---|---|---|---|---|
| 1 | False | False | False | False |
| 2 | True | False | False | True |
| 3 | False | False | True | True |
| 4 | False | True | True | False |
| 5 | False | False | False | False |
| 6 | True | True | False | False |
| 7 | True | False | False | True |
At step two, the start request makes the OR term true and there is no stop request, so the new state is true. At step three, the start request has disappeared, but the previous true state keeps the OR term true. At step four, StopRequest makes the final condition false, so the stored state clears.
Step six proves the stated priority when both requests are true. Step seven reveals another property: if StartRequest remains true after StopRequest becomes false, the indicator becomes active. This model uses a level-sensitive start request. It does not require a new rising event after stopping.
That distinction is essential. If your requirement says “a fresh start action is required”, this simple equation is insufficient for every possible input sequence. You need to define and implement event handling or another appropriate state rule. Do not claim that a familiar seal-in pattern automatically satisfies every restart requirement.
State and execution order must be visible in your explanation
A useful introductory scan model samples inputs, executes a program and updates outputs. Real controllers can have multiple tasks, asynchronous I/O, immediate operations and other behaviours outside that simplified picture. Use the simple model to learn a concept, then identify the differences in the target system.
Within an explicitly sequential program, a later operation can observe a value written by an earlier operation. If several instructions write the same variable, the result depends on which instructions execute and in what order. That is why finding every writer of a value is a useful diagnostic step.
Avoid turning this into the rule that all outputs always change only after one universal scan sequence. The target controller and configuration decide that behaviour. Similarly, a timer's relationship to elapsed time cannot be inferred solely from how often a rung appears to execute.
Practise with the scan-cycle explanation and the product's scan-cycle highlighting view. State which model you used when documenting an observation. The CODESYS ladder editor documentation also shows why editor and processing-order details belong to a specific implementation.
Turn an example into a testable exercise
Begin with a short requirement and a known initial state. List the inputs you will change, the result you expect and the observation that will establish it. Keep each test small enough that a disagreement has only a few plausible explanations.
For the virtual Active indicator, useful cases include no requests, a start request, release of start, a stop request, simultaneous start and stop, and a held start during stop release. The last case matters because it distinguishes the demonstrated level-sensitive behaviour from a fresh-start requirement.
Record both successful and unsuccessful results. If a case fails, preserve the original observation before editing. Explain what the failure suggests and which one change you will test next. A sequence of unexplained edits can eventually produce the expected output while leaving the underlying misunderstanding intact.
After correcting a case, rerun the earlier ones. A change that fixes held-start behaviour could alter initialisation or stop priority. Regression testing in a tiny learning example builds a useful habit before you work with a larger sequence.
The start-stop learning exercise is a related activity. Compare its stated inputs and assumptions with this tutorial instead of assuming that two similarly named examples have identical requirements.
Diagnose the first incorrect condition
Suppose the virtual Ready indicator remains false when you expected true. Check the stated input values first. If MaterialAvailable is actually false, the AND result may be correct. If both source values are true but one contact evaluates false, inspect the instruction type and the referenced variable.
If the contact results are correct but the final value differs, inspect the branch grouping and the operation writing the result. Then look for another writer. This order follows the logic's evidence path and helps avoid changing an unrelated part of the example.
For a state-holding problem, write down the previous state as well as the current inputs. Two tests with identical inputs can legitimately produce different results if their initial states differ. A screenshot that omits state history may be insufficient to explain the behaviour.
The PLC fault-finding workflow extends this reasoning. In a learning environment, deliberately changing one condition can clarify a hypothesis. Production equipment requires the site's authorised procedures and appropriate supervision; a tutorial is not permission to alter a live system.
Common beginner misunderstandings to correct early
Treating a contact symbol as a wiring instruction
The symbol tests a program value. Establish the relationship between the device, input and variable separately. Use the exercise's definitions to decide whether a positive or negated condition expresses the requirement. Do not select the instruction from a physical switch label alone.
Confusing a command with physical feedback
A program value called RunCommand describes an instruction or request. It does not independently prove rotation, movement or another physical outcome. Even a learning example benefits from separate names for request, accepted state and simulated feedback when those distinctions are relevant.
Counting a continuing condition as repeated events
A true value across several steps is not necessarily several occurrences. If the requirement is one count per new item, define the event and its detection. The Mitsubishi training guide includes a detailed event-counting brief that illustrates this distinction without assuming universal vendor syntax.
Assuming a familiar pattern covers every restart case
The seal-in equation in this article restarts when a held StartRequest remains true after StopRequest clears. That behaviour follows the equation. If the intended process requires a fresh request, the requirement and implementation need additional reasoning. Test the changed sequence explicitly.
Copying code without identifying its environment
Instruction names, data types, task behaviour and reset semantics can differ. Record the platform, version and assumptions alongside any example. A program that works in a browser learning model may need a different implementation in a vendor engineering environment.
Use ladder practice in a South African learning plan
For an electrician, engineering student or new automation learner, choose a course that provides individual practice and feedback on these fundamentals. Ask the provider to show an exercise where the learner predicts and explains changed conditions. A lesson should do more than reproduce a finished rung from the instructor's screen.
If you are comparing courses in Johannesburg, Pretoria, Durban, Cape Town or online, use the same entry-level assessment questions. The location does not change Boolean logic, while access to devices, software and instructor support can change the learning experience. The South African PLC course guide helps you compare those practical differences.
Build a small portfolio of explained examples: an AND condition, an OR condition with a shared permission, a state-holding indicator and an event-counting exercise. Keep each requirement, test table and limitation together. This gives an instructor or employer more useful evidence than an unexplained image of a complex ladder network.
Questions about learning ladder logic
Where should PLC programming for beginners start?
Start with one Boolean condition and predict the output before running it. Add a second condition only when you can explain the first truth table, then test a remembered state and its reset. Useful PLC training for beginners gives feedback on these predictions and introduces software navigation alongside the reasoning. You do not need to begin with an entire conveyor project.
Can I learn ladder logic without owning a PLC?
You can practise supported Boolean logic and state behaviour in a suitable simulator. Use the model's documented instructions and keep the environment clear in your notes. Physical wiring, measurement and equipment-specific work require separate practical learning.
What is the difference between a contact and a coil?
A contact tests a referenced condition. A coil or related output instruction writes or changes a value according to its defined behaviour. The graphical similarity to electrical symbols does not make the program a physical circuit diagram.
Why does a seal-in rung stay true after start is released?
In the example here, the previous Active state is an alternative true condition in the OR term. The state therefore remains true until StopRequest clears it. That explanation depends on the declared initial state and update model.
Is a latch always better than a normal coil?
No. They express different behaviour. Write the required transitions and choose an instruction or pattern that matches them. Verify reset, initialisation and simultaneous-condition behaviour in the target environment.
What should I learn after my first rung?
Practise branch grouping, state, event detection and test writing before adding timers and sequences. Then use the timers and counters guide. Progress when you can explain changed cases, not merely when one example appears to work.
Start with one prediction
Open the browser PLC practice demo and choose a supported introductory exercise. Write down what you expect before changing an input. Compare the observation with the requirement and preserve the case that exposed a misunderstanding.
Keep the first project small. Clear variable meanings, explicit state and a handful of well-chosen tests are the foundation on which more complex ladder programs become understandable.