plc-programming-examples · South Africa
PLC Programming Examples: 20 Projects and Worked Tests
Explore PLC programming examples across 20 project topics. Learn to write requirements, test a worked selection model and document simulation results.
PLC programming examples are useful when you can explain the requirement, predict the result and test a change. A finished ladder diagram is only one part of that evidence. You also need initial conditions, input meanings, instruction assumptions and a clear account of what the example does not demonstrate.
This guide organises 20 project topics and provides a complete fictional request-selection exercise. Use the topics as learning routes, not ready-to-download production designs. Machine-themed examples require particular care: simulated outputs and passing test cases do not establish that physical equipment or a safety function is suitable for use.
This website is commercially connected to PLC Simulator. The PLC practice curriculum is an independent learning option. Check the actual scenario and access conditions; the topic list here does not promise that every linked article corresponds to an identical graded product exercise.
Choose a project from the concept you want to learn
For a first exercise, use a small Boolean requirement with all input combinations visible. Then introduce stored state, event counting or timing separately. Combining several unfamiliar features at once makes it harder to explain which assumption caused an unexpected result.
The official IEC 61131-3:2025 description identifies Structured Text, Ladder Diagram and Function Block Diagram, with SFC elements for program organisation. That provides context for language names, not proof that all vendor tools accept the same project or execute every feature identically.
If you need a specific platform, record its controller, software version and supported instructions. Reimplementing a familiar concept can help you learn another environment, but it still requires platform-specific checks. Our ladder logic foundations guide is a starting route for the notation.
Five introductory project topics
1. Start-stop memory
The start-stop seal-in topic introduces a maintained logical state. In a software exercise, define the initial state and what happens when start and stop occur together. Also specify the effect of a held start after stop is released. A basic holding expression does not automatically require a fresh start event or validate a physical stop circuit.
2. Momentary versus maintained control
The jog versus latch topic helps compare a value that follows a held input with one that retains state. Use fictional indicators while learning the distinction. Write what should happen when a mode changes or two requests overlap; do not infer a suitable machine response from a generic example.
3. Repeating timer indication
The flashing beacon topic is a route into repeated timed states. Define the on interval, off interval, starting condition and reset behaviour. Check whether the model uses supplied time steps or a runtime clock, and distinguish an observed animation from a measured timing result.
4. Delayed staging
The on-delay staging topic introduces a condition that must remain true before another logical stage becomes available. Specify what starts and resets the delay, including loss of a prerequisite. Keep fictional stage outputs separate from claims about a motor's actual command, feedback or stopping behaviour.
5. Counting events
The bottle-counting topic provides a setting for distinguishing a held input from repeated events. Document whether the selected counter instruction detects an edge itself or requires another event signal. Test a held input and reset interaction rather than adding an edge instruction from habit without checking the environment.
Five topics for state, limits and selection
6. Bounded up/down counting
The parking-counter topic introduces upper and lower limits. Define the result when both entry and exit events arrive together, and when either boundary is reached. A number constrained by software is not independent evidence of actual occupancy; the learning model needs its own stated assumptions about events.
7. Mutually exclusive states
The star-delta topic can motivate studying two outputs that should not overlap in a model. Test the reachable states and transitions under the stated assumptions. Such a study does not prove contactor behaviour, electrical protection, mechanical interlocking or the suitability of an actual starter design.
8. Alternating selection
The pump-alternation topic introduces selecting between alternatives over successive requests. Specify where the selection history is stored and what happens when an option is unavailable. Use the example to reason about state ownership; an alternation diagram alone does not establish process reliability or physical fallback performance.
9. Separate switching thresholds
The float-switch topic provides a route into level conditions and state changes. Define which combinations are expected and how conflicting or missing inputs are represented. Do not assume that two thresholds solve every form of chatter, sensor failure or rapid physical cycling.
10. Analogue threshold interpretation
The tank-level topic connects values, units, ranges and conditions. Include invalid quality or unavailable data in the learning specification. A threshold comparison can be tested mathematically, while the correctness of an instrument reading and the appropriate equipment response require separate evidence.
Five topics for event histories and sequences
11. Conveyor command and status
The conveyor start-stop and E-stop topic requires a clear distinction between educational program states and a real emergency-stop function. Use a software model to discuss command, observation and reset requirements. Do not treat a simulated permission bit as proof of a physical safety chain or restart prevention.
12. Event association
The sorting-by-height topic introduces connecting a detected item with a later decision. Define the assumed spacing, ordering and model timing. Test two closely spaced fictional events and explain what information identifies each item. A single pulse animation does not prove a real product-tracking system.
13. A timed state sequence
The traffic-light topic is a familiar setting for states and transitions. Use it as a fictional display sequence with explicit initial conditions. A model that avoids conflicting display states is not a road-traffic controller design or evidence that a public installation meets its required standards.
14. Remembering a request
The pedestrian-request topic introduces retaining a request until a later stage handles it. Define when the request is accepted, cleared or ignored. Repeated requests should follow the written rule, rather than whatever an overlapping collection of timers happens to produce.
15. Opposing-direction requests
The sliding-gate topic can be used to discuss arbitration between two directions in a fictional model. Include simultaneous requests and unknown limit information. The model does not validate entrapment protection, physical sensing or an actual gate's recovery and stopping requirements.
Five topics for larger learning projects
16. Multi-stage operation
The car-wash sequence topic combines stages, completion conditions and interruption. Start with a small fictional sequence and make the transition table readable. Define what is remembered after interruption and what must be re-established before continuing; do not use a generic “safe state” label without a specific scope.
17. Conflicting observations
The silo-fill topic can motivate a study of input combinations that disagree with the model's assumptions. Separate “unexpected combination observed” from a claim that a particular sensor is faulty. A useful exercise documents the uncertainty and the next observation needed to distinguish explanations.
18. Recipe and progress data
The batch-mixer topic introduces parameters, progress and completion records. In a fictional model, define when new parameters are accepted and what happens to progress after cancellation. A saved recipe is not proof of a completed batch, material balance or suitable recovery action on equipment.
19. Reset versus initiation
The press-interlock topic needs an explicit educational boundary. It can help learners discuss why acknowledging or resetting a condition is different from initiating an action. A PLC exercise is not a press safety design, a validated safeguarding system or permission to operate machinery.
20. First-event recording
The first-fault topic introduces preserving an initial event while later events arrive. Define how simultaneous observations are handled and whether the model has sufficient timing information to establish order. A chosen priority is not proof of which physical fault happened first.
Worked example: selecting one of two practice requests
Use a fictional learning screen with two requests for a practice card, A and B. When the screen is enabled, it should select A if A is requested. Otherwise, it should select B if B is requested. When disabled, it selects neither. If both requests are true, A has priority.
The inputs are Enabled, RequestA and RequestB. The outputs are SelectedA and SelectedB. All are Boolean. This model has no stored state, timer, physical output or safety role. Inputs are evaluated as one supplied combination.
The requirement is intentionally small enough to check completely. It combines enabling, priority and mutual exclusion without requiring a machine-themed example. Do not interpret its priority choice as a general recommendation for equipment control; it is simply the rule of this fictional exercise.
Derive the expressions
A is selected when the screen is enabled and A is requested. B is selected when the screen is enabled, A is not requested and B is requested:
SelectedA = Enabled AND RequestA
SelectedB = Enabled AND NOT RequestA AND RequestB
The second expression contains the priority decision. If you omit NOT RequestA, both outputs become true when both requests are true and the screen is enabled. That would contradict the stated requirement.
These are Boolean model expressions, not source files compiled for a named controller. A ladder implementation must use the selected environment's supported tests and assignments. The contacts and coils reference provides a related notation route.
Check all eight input combinations
| Enabled | Request A | Request B | Selected A | Selected B |
|---|---|---|---|---|
| 0 | 0 | 0 | 0 | 0 |
| 0 | 0 | 1 | 0 | 0 |
| 0 | 1 | 0 | 0 | 0 |
| 0 | 1 | 1 | 0 | 0 |
| 1 | 0 | 0 | 0 | 0 |
| 1 | 0 | 1 | 0 | 1 |
| 1 | 1 | 0 | 1 | 0 |
| 1 | 1 | 1 | 1 | 0 |
The first four rows establish that disabling the screen selects neither card. The final row establishes A's priority. Across all rows, the outputs are never true together. Both can legitimately be false, so mutual exclusion does not mean that one output must always be selected.
A learner who tests only A alone and B alone could miss the simultaneous-request defect. The final row is the distinguishing case. A learner who tests only enabled operation could miss a missing enable condition, so the disabled rows also have a purpose.
Change one requirement and revise the tests
Suppose the next exercise version should reject simultaneous requests instead of prioritising A. Keep it as a separate version. Change the A expression to require B false, while B still requires A false. The final truth-table row then becomes zero for both outputs.
Seven rows remain unchanged. The simultaneous-request row distinguishes the two versions. This is a useful review habit: when a requirement changes, identify which expected results should change and which should remain stable.
Do not call either version universally correct. Each implements a different stated rule. If the requirement is ambiguous about simultaneous requests, settle that ambiguity before using the implementation as the answer.
Record the evidence and its limits
Keep the requirement, eight-row table, expressions and observed results with the exercise version. If you run it in a simulator, name that environment and record any assistance. If you only check the Boolean model, describe the result as a model check rather than native PLC execution.
The complete table establishes the output relation for this stateless Boolean specification. It does not validate physical timing, I/O quality, task scheduling or a safety function. Larger projects have additional state and inputs, so eight tests would not automatically cover their behaviour.
For independent practice, explore the PLC Simulator curriculum and choose a supported exercise that fits the concept. This article's selection model is not a claim that an identical ready-made scenario is included.
Build a test record before making the project larger
Start each project with input meanings, output meanings and any stored state. Include units and valid ranges for numbers. Write the normal behaviour and the cases that require a specific decision: simultaneous requests, invalid information, reset, cancellation or a missing prerequisite.
Then choose tests that distinguish the intended rule from plausible mistakes. In a counter example, held inputs and reset interaction matter. In a threshold example, values immediately around the boundary matter. In a sequence, initial state and transition priority matter. The number of tests follows the behaviour being checked, not a universal minimum copied into every project.
When a result differs, record the first discrepancy and investigate its cause. Change one relevant part, then repeat the affected tests and any others needed to check the intended behaviour. Keep a note of the earlier failure so a reviewer can understand the correction.
The PLC technician training guide develops this diagnostic approach. For a smaller study schedule, use the home-learning plan. Neither route promises workplace competence after completing a fixed number of examples.
Choose the next reference from the concept your project needs. Use bit shifts and rotations for bounded bit histories, PLC maths instructions for numeric operations and their limits, SFC steps and transitions for explicit state progression, and string instructions for text handling. Each reference helps you state assumptions before extending an exercise.
Choose the implementation environment deliberately
A generic expression can communicate a requirement, while a runnable project depends on its language and platform. Check data types, instruction names, state storage, call order and reset behaviour. Do not assume that a timer field name or counter block from one vendor can be pasted unchanged into another environment.
If the objective is vendor-specific work, use the appropriate tools and documentation. The Siemens training guide, Allen-Bradley guide and CODESYS guide help frame those choices. Shared concepts are useful preparation, but compatibility must be established for the actual target.
For observation practice, the independent scan-cycle highlighting feature is relevant to explore. Use what the tool actually exposes and record limitations if an individual evaluation cannot be observed directly.
Use projects in South African training discussions
A learner in Johannesburg, Cape Town, Durban or another location can bring a small project record to a course enquiry. Ask the provider which parts it can assess and which additional hardware or software practice it offers. A specific request is easier to evaluate than asking whether a course makes someone an expert.
If you are studying around shifts or limited connectivity, keep the requirement and predictions available separately from the online tool. You can review a truth table without executing a simulator. When you resume, establish the initial state and version before comparing new results with earlier ones.
For employer-funded learning, identify the actual target platform and desired evidence. Do not assume that a portfolio project satisfies a specified qualification, vendor course or workplace authorisation. The PLC certification guide explains those different claims.
A portfolio can include fictional projects if they are labelled honestly. Keep employer code, diagrams and confidential process details out of public examples without permission. State what you implemented, what was supplied and what feedback helped you improve it.
Questions about PLC programming examples
What makes PLC programming exercises suitable for advanced training?
Advanced PLC programming needs more explicit requirements and stronger evidence, not merely more rungs. Extend one exercise with simultaneous requests, invalid data, restart behaviour and two independent instances. Define the required result for each case before changing the implementation. For advanced PLC training, ask the instructor to review your assumptions, test coverage and the limits of the simulated result as well as the final code.
Which example should a beginner try first?
Start with a small Boolean rule whose complete input table you can understand, such as the request-selection example above. Then add state, timing or counting one concept at a time. Choose an exercise that fits your current knowledge rather than treating a machine-themed title as proof of the right difficulty.
Can these project topics be used in ladder or Structured Text?
Many concepts can be expressed in different languages, but the implementation must follow the selected environment's syntax and supported behaviour. Keep the requirement and tests independent of the notation where possible, then verify the actual program in its target context.
Are the linked examples production-ready designs?
No. They are educational topic routes. Physical equipment requires its own requirements, appropriate engineering, assessment and authorised validation. A successful software exercise does not establish that a machine, electrical circuit or safety function is suitable for operation.
Do passing tests prove a PLC program is correct?
They support the tested behaviour under the stated assumptions. A complete truth table can cover a small stateless Boolean relation. A larger stateful application requires additional analysis and evidence; a handful of successful scenarios is not a universal proof.
How many projects do I need for a job application?
There is no single project count that establishes suitability for every role. Ask the employer what evidence it needs. A clearly explained project can demonstrate specific practice, but does not replace a required qualification or prove experience you have not gained.
Can I practise without a physical PLC?
You can begin with requirements, truth tables and supported software models. Select a simulator or engineering environment that supports the behaviour you want to investigate. Hardware-dependent skills and observations need additional practical instruction and evidence.
What should I do when two examples disagree?
Compare their requirements, input meanings, initial state, instructions and execution assumptions. They may implement different rules. If they claim the same rule, identify a distinguishing test and check the applicable documentation rather than choosing the more convincing screenshot.
Start with a requirement you can explain
Complete the eight-row selection table, implement the supported expressions and test the simultaneous-request case. Then change the requirement to reject simultaneous requests and identify the one row that changes.
That gives you a reusable learning method for the 20 topics: specify the behaviour, predict the result, test the cases that matter and describe the limits. Expand the project only when you can explain the smaller version clearly.