learn · South Africa
Sequencer Logic Patterns: States, Completion and Timeouts
Learn sequencer logic patterns with state transitions, stale Done tests, restart rules and timeouts, plus practical South African PLC training questions.
Sequencer logic patterns describe how a PLC application moves between defined steps, recognises completion and selects outputs. A reliable learning example specifies what happens when inputs arrive together, a completion signal remains true, a timeout expires or operation is interrupted. Choosing step bits or a step number is only one part of that design.
This guide builds a fictional five-stage packaging sequence for South African PLC learners. It uses supplied completion signals and virtual commands, with explicit reset and restart rules. It does not describe protective wiring, prove that a physical mechanism has returned to a suitable position or prescribe a machine recovery procedure.
For the execution foundation, read how a PLC scan affects program values. The difference between the state at the start of an evaluation and the state written halfway through it explains many surprising sequencer results.
Practise PLC sequence logic →A state machine can use different encodings
A state machine has defined states and rules for moving between them. It can be represented by an enumeration, an integer with named values, a set of Boolean step flags or another suitable structure. “State machine” and “step counter” are therefore not mutually exclusive design categories.
With an integer representation, prefer meaningful names such as Fill and Inspect in the specification. A number can identify one state at a time, but it can still contain an unsupported value. Include a defined response for an invalid state instead of assuming the data type guarantees a valid sequence.
With Boolean flags, define whether Idle has its own flag or means that every productive-step flag is false. For five productive steps with Idle represented by all false, the valid count of active productive flags is zero or one. Requiring exactly one would incorrectly reject Idle.
OR-ing the flags answers only whether at least one is true. It cannot distinguish one active flag from three. To check mutual exclusion, count the true flags or use an equivalent explicit check. Of the 32 possible combinations of five Boolean flags, six contain zero or one true value; the other 26 violate that particular single-step representation.
There is no universal eight-step threshold at which a different representation becomes correct. Branching, shared actions, platform support, diagnostic needs and the maintenance team's ability to review the implementation are more useful selection criteria.
Define the five stages and two non-running states
Our model has seven named states: NeedsReset, Ready, Fill, Cap, Label, Wrap and Inspect. The five productive states occur in that order. The labels describe a software exercise; a real capping or wrapping mechanism may need several substates and additional feedback.
Each productive stage has one supplied Boolean completion input and one virtual command. FillDone belongs to Fill, CapDone to Cap, and so on. The model does not infer product quality, actuator position or the reason why an input changed.
The additional inputs are Start, Reset, StopActive and Permission. True StopActive requests cancellation. True Permission allows the exercise to process its ordinary rules. We assume one coherent input snapshot and valid, nondecreasing timestamps measured in milliseconds for each evaluation.
At initialisation, choose NeedsReset; both arming flags are false. Set the previous Reset value to the current raw Reset input so that a button already held at startup does not count as a new reset edge. All five virtual commands are false.
The two arming flags have different jobs. StartArmed records that Start was observed released while Ready. CompletionArmed records that the current stage's Done input was observed false after entering that stage. Neither flag is a statement about physical safety.
Calculate the next state from the old state
Take a copy of the old state, calculate the decision for that state and assign the selected next state once. A transition into Cap must not immediately run Cap's transition logic during that same evaluation.
The CODESYS CASE statement reference describes selecting a branch by comparing the condition with its labels. A CASE-based implementation can express this pattern clearly when its input state and assignment discipline are controlled. The same behavioural contract can be implemented in ladder logic.
Use the following priority order for this exercise:
- An invalid state, active Stop or absent Permission selects NeedsReset and clears both arming flags.
- In NeedsReset, a fresh Reset edge selects Ready. This transition does not accept Start in the same evaluation.
- In Ready, observing Start false arms a subsequent Start. Start true while armed enters Fill and clears both arming flags.
- In a productive stage, reaching the timeout selects NeedsReset before considering completion.
- Otherwise, a false current Done input sets CompletionArmed. A true current Done input advances only if that flag was already true.
Every transition into a productive stage records its entry timestamp and clears CompletionArmed. Returning from Inspect to Ready clears StartArmed. Update previous Reset from the raw input on every evaluation, including evaluations blocked by Stop or Permission.
Finally, derive each command from the resulting state. FillCommand is true only for Fill, CapCommand only for Cap, and similarly for the other stages. NeedsReset and Ready produce no productive commands. This mapping has one owner for each virtual command.
Why a list of independent IF statements can skip stages
Suppose the old state is Fill, its completion is armed and all five Done inputs are true. An ordered list that writes State=Cap, then tests the newly written Cap state, can continue to Label, Wrap, Inspect and Ready in one evaluation.
Our model selects only Cap. Cap starts with completion unarmed, so the old true CapDone input cannot immediately advance it even on the next evaluation. This is a defined protection against stale completion indications in the teaching interface.
Putting set and reset instructions on the same ladder rung does not, by itself, establish how every other reader observes the state. Review all writers, execution order and output consumers. The PLC latching guide explains why instruction order and priority matter.
Accept completion only under the specified contract
On entry to a stage, ignore that stage's current Done level for arming purposes. On a later evaluation while that stage remains active, Done must be false to arm completion. A subsequent true value can then advance the sequence.
This means a completion signal that was already true when the stage began must return false before it can be accepted. It also means a low observation during a previous stage does not arm the next stage. Each stage establishes its own completion history after entry.
This is one deliberately simple interface contract. A command/acknowledgement interface using operation identifiers may be more appropriate in another application. A level that means “position currently reached” may also need different handling from a signal that means “this requested operation has finished”. Name the signal and specify its lifecycle before selecting an edge rule.
Do not insert one-shots everywhere as a substitute for that specification. Some commands must remain true through a stage; other actions occur once on entry, and others wait for an acknowledgement. The correct duration follows the interface, not a universal sequencer convention.
Worked trace with stale Done inputs
The following trace starts in NeedsReset with previous Reset false. Permission remains true and StopActive remains false. All Done inputs are true unless a row names a false input. Start remains held from 400 through 1700 ms.
| Time | Start | Reset | Done input changed for this row | Result after evaluation |
|---|---|---|---|---|
| 0 ms | 1 | 0 | None | NeedsReset |
| 100 ms | 1 | 1 | None | Ready, Start unarmed |
| 200 ms | 1 | 1 | None | Ready, Start unarmed |
| 300 ms | 0 | 0 | None | Ready, Start armed |
| 400 ms | 1 | 0 | None | Fill, completion unarmed |
| 500 ms | 1 | 0 | None | Fill, still unarmed |
| 600 ms | 1 | 0 | FillDone false | Fill, completion armed |
| 700 ms | 1 | 0 | None | Cap, completion unarmed |
| 800 ms | 1 | 0 | None | Cap, still unarmed |
| 900 ms | 1 | 0 | CapDone false | Cap, completion armed |
| 1000 ms | 1 | 0 | None | Label, completion unarmed |
| 1100 ms | 1 | 0 | LabelDone false | Label, completion armed |
| 1200 ms | 1 | 0 | None | Wrap, completion unarmed |
| 1300 ms | 1 | 0 | WrapDone false | Wrap, completion armed |
| 1400 ms | 1 | 0 | None | Inspect, completion unarmed |
| 1500 ms | 1 | 0 | InspectDone false | Inspect, completion armed |
| 1600 ms | 1 | 0 | None | Ready, Start unarmed |
| 1700 ms | 1 | 0 | None | Ready, still unarmed |
| 1800 ms | 0 | 0 | None | Ready, Start armed |
| 1900 ms | 1 | 0 | None | Fill, new cycle |
The 500 and 800 ms rows show why an already-true completion input is not enough. The 1600 and 1700 ms rows show why holding Start across cycle completion does not automatically begin another cycle under this policy.
The output trace follows the resulting state. At 700 ms, FillCommand is false and CapCommand is true. This describes the software command mapping at the evaluation boundary. It does not prove that a physical filling device has closed before a physical capping mechanism moves.
Timeouts need an explicit boundary and priority
Assign every productive stage a fictional 2,000 ms timeout for the classroom exercise. This shared value keeps the example easy to test; it is not a suggested duration for filling, capping or any real machine action.
Elapsed time is the current timestamp minus the entry timestamp for the active stage. If elapsed time is greater than or equal to 2,000 ms, choose NeedsReset. Timeout wins over Done when both conditions are present in the same evaluation.
For a Fill stage entered at 100 ms, an armed true FillDone at 2099 ms can advance to Cap: elapsed time is 1999 ms. The same inputs at 2100 ms instead select NeedsReset because elapsed time is exactly 2000 ms. These are separate test runs from the same starting condition.
If execution resumes after a long scheduling gap, the timestamp comparison detects that the deadline has been reached. This model does not pretend an evaluation occurred during the gap. Record the observed timeout and distinguish it from a precise measurement of when a physical process became late.
Use a meaningful application requirement when choosing actual deadlines. “Twice the expected step time” is not universally correct, and a timeout does not identify a unique failed component. The timer reference explains why timer invocation and timing assumptions must also be documented.
Stop, reset and restart are separate decisions
StopActive or lost Permission selects NeedsReset and removes the virtual commands. Restoring Permission does not return the model to the interrupted stage. A fresh Reset edge is required to reach Ready, followed by observing Start released and then accepting a new Start.
A Reset press that occurs while Stop remains active is consumed by the raw Reset history. Holding Reset while Stop is released does not create a fresh edge. Release Reset and press it again under permitted conditions to reach Ready in this exercise.
Likewise, Reset and a held Start together do not start a cycle. The reset transition selects Ready with Start unarmed, and only Ready's later evaluations can establish a new start request. Reset is not a combined “clear and run” command.
For a real machine, choosing the first production step after an interruption may be inappropriate. Material, pressure, movement and actuator positions may require a recovery procedure. Clearing software step bits is not evidence that the process has returned to its initial physical condition.
The motor-control restart guide provides a smaller related example. Treat these as software policies to understand and assess, rather than a universal emergency-stop or power-restoration design.
Sustained commands and entry actions
In our model, each productive command stays true while its state is active. That makes the command trace unambiguous. A stage may also need an entry action, such as recording the entry timestamp, which happens once when the stage changes.
A one-evaluation pulse is not automatically suitable for a physical actuator or remote application. A receiver may need a maintained request, a minimum pulse width or an acknowledged transaction. Conversely, repeatedly issuing an entry-only command throughout a stage can unintentionally retrigger an operation.
Document each output's ownership, duration and cancellation behaviour. One stage can legitimately coordinate more than one output, and an output can be used in more than one stage through a single arbitration rule. There is no general requirement that every state must map to exactly one physical actuator.
If you add parallel work, revisit the state model. “Only one productive stage is active” is the invariant of this serial exercise, not an invariant for every process with simultaneous branches.
Where SFC fits
IEC 61131-3:2025 describes SFC elements for structuring programs and function blocks alongside its programming-language suite. Check the supported edition, controller and development tools rather than assuming every installed environment has identical SFC features.
The CODESYS SFC processing-order documentation distinguishes alternative branches from parallel branches and explains action processing. In a parallel branch, more than one step can be active intentionally. Native action qualifiers and execution order require their own review.
SFC can make a sequence's structure visible, but it does not eliminate the need to define completion, interruption, timeout and output behaviour. A graphical chart with unclear transitions can be as ambiguous as poorly organised ladder logic.
For an assessment, compare two representations of the same serial contract. They should produce the same state and output traces under the same input history. Then identify what would have to change before introducing a genuine parallel branch.
Build a useful sequencer test set
Test normal progression, all Done inputs initially true, a Done input permanently false, Stop during every productive stage, lost Permission, held Reset across restoration and held Start across completion. Include the timeout boundary and an invalid stored state.
Inspect the complete output set after each evaluation. For this serial model, either no productive command is true or exactly one is true. An output staying latched from a previous stage can violate the intended behaviour even when the displayed state number looks correct.
The scan-cycle highlighting resource is relevant to observing execution and value changes. Use it to connect a visible transition to the logic that caused it, without assuming every simulator reproduces a native SFC runtime.
Keep expected and observed traces together using the approach described in PLC program testing. A successful final state alone does not show whether intermediate stages were skipped or conflicting commands appeared.
South African course and interview questions
For PLC sequencing training in Johannesburg, Pretoria, Durban, Cape Town or online, ask for an individual exercise with abnormal input histories. A learner should explain why a transition occurred, not merely reproduce a demonstration that works when buttons are pressed in the expected order.
Useful assessment questions include: what happens if all completion inputs are true before Start, which condition wins at the timeout boundary, and why does an old Reset press not count after an interruption? Ask the learner to show the result in a trace and identify the relevant rule.
For a course involving HMI parameters, connect this lesson to recipe management and batch snapshots. A sequence should use the intended active settings; changing a draft recipe should not silently change the meaning of a running test.
Choose a representation your team can review and maintain in the actual platform. The evidence of competence is a clear sequence specification, tested exceptional cases and an explanation of the limits of the software result.
Common sequencer questions
Is an integer step number less reliable than step bits?
Neither representation is automatically reliable. An integer needs valid-state checks and controlled assignments; Boolean flags need a defined encoding and mutual-exclusion checks. Both need the same transition and recovery specification.
Why does my PLC skip several steps in one scan?
Later logic may be reading state values written earlier in that scan. Completion signals may also already be true. Compare the old state with the selected next state and specify how each new stage establishes a valid completion indication.
Should every sequencer output use a one-shot?
No. Choose the output duration from the receiving interface and the intended action. This exercise uses sustained virtual stage commands and separate entry timestamps. A one-shot is a particular event mechanism, not a universal actuator rule.
Does resetting to the first step make a machine ready to restart?
It establishes a software state only. A physical process may still contain material, stored energy or equipment in an unsuitable position. Recovery needs its own application-specific requirements and verification.
Test your PLC sequence logic →