PLC Sequencers and State Machines: Design, Code and Troubleshooting

Direct answer

A PLC sequencer advances a process through ordered steps. A PLC state machine makes each operating condition an explicit state and permits only documented transitions between states. The two ideas overlap: a linear step sequencer is a restricted state machine, while a state machine can branch, recover, retry, hold, abort and fault.

For most non-trivial machines, use one explicit current-state value, one proposed next-state value and one transition commit at the end of each PLC execution. Default commands to their inactive condition before evaluating the current state. Let the current state assert its commands, then evaluate guarded transitions in documented priority order. Record previous state, transition reason, elapsed time and first-out fault. This avoids scattered step bits, multiple output writers and accidental movement through several states during one scan.

Use a table-driven or shift/register sequencer when identical stations or fixed output patterns move in a simple order. Use SFC when the engineering team benefits from a standard graphical step/transition representation, especially for parallel or alternative branches. Use an ISA-88 phase or PackML-aligned model when reusable equipment procedures, recipes or a standardized machine-state interface matter. The representation does not remove the need for command ownership, transition priority, timeouts, restart policy, abnormal recovery and tests.

Download the PLC sequence contract, 24-case acceptance matrix and complete IEC Structured Text batch example.

Sequencer, state machine, SFC or shift register?

Match the mechanism to the process topology

Mechanism	Best fit	State representation	Main strength	Common failure mode
explicit state machine	branching machine or process with abnormal paths	enumeration or one-hot states	readable transitions, recovery and diagnostics	undocumented priority in a large CASE
step sequencer	linear or mostly linear operation	integer step plus step data	simple ordered progression	hidden jumps and overloaded step numbers
table/output sequencer	fixed output patterns	index into masked output table	compact repeatable pattern	table writes physical outputs without feedback proof
shift/register sequencer	parts move through equivalent stations	one bit/data record per position	tracks material position naturally	lost synchronization after reject, jam or restart
SFC	chronological steps with alternative/parallel branches	active SFC steps	graphical process visibility	assuming editor notation defines project recovery policy
ISA-88 phase/recipe model	reusable process equipment and recipes	phase states plus commands	modular procedural control and traceability	mixing recipe procedure with equipment control
PackML-aligned machine state	packaging-machine interface/state consistency	defined machine states/modes	common supervisory vocabulary	copying state names without implementing exact command/response rules

A drum or SQO-style sequencer can be correct for a fixed washing pattern, light bank or repeated station outputs. Rockwell’s current SQO documentation describes an indexed array, mask, destination and control position; it advances on a false-to-true enable event. That is materially different from a feedback-governed state model. Never call an output table “complete” merely because its index advanced. Physical feedback, quality, timeouts and recovery remain separate design responsibilities.

SFC is not merely a drawing. IEC 61131-3 defines SFC elements for structuring programs and function blocks. Current CODESYS documentation describes steps, transitions and processing order; alternative branches are evaluated in order and parallel branches activate together. Schneider and Beckhoff document comparable step/transition concepts, but exact action qualifiers, execution order, forcing, online diagnostics and restart behavior are product surfaces to verify.

Keep canonical ownership clear

This guide owns sequence architecture, implementation and fault recovery. The dedicated Sequential Function Chart guide owns SFC notation, branch construction and detailed chart practice. The Structured Text guide owns the language broadly, and the PLC program testing guide owns test architecture and regression levels. Use those specialists rather than duplicating a general language or testing course here.

Write the sequence contract before code

Define state, action, guard and evidence

Every state needs an engineering contract:

Contract element	Question to answer	Batch example
identity	what stable operating condition does this state mean?	Mixing means fill closed, drain closed, mixer requested
entry	what happens once when the state becomes active?	snapshot mix duration and reset elapsed counter
continuous action	what is evaluated or commanded every execution?	assert MixerCmd; monitor feedback and permissives
completion guard	what qualified proof permits the normal transition?	elapsed mix duration and required quality conditions
abnormal guard	what fault, abort or mode event overrides normal flow?	mixer feedback lost; Abort request; permissive failure
timeout	how long can the state legitimately remain active?	recipe mix duration differs from maximum allowed process time
exit	what must be recorded or cleared when leaving?	store from/to/reason/time; remove state-owned request
recovery	can it retry, resume, restart or only return to Idle?	project permits one controlled retry after inspection

Do not encode “Step 30” until the team agrees what Step 30 proves. The downloadable contract treats commands, feedback, quality, elapsed state time and transition evidence as different values. A command is intent. Feedback is observed evidence. A transition may require qualified feedback; the command bit cannot satisfy its own proof.

Separate sequence, equipment and physical outputs

A robust call path is usually:

qualified inputs → equipment objects → sequence → equipment requests → command arbiter → physical outputs

The sequence asks “fill,” “mix” or “drain.” Equipment objects decide whether the valve or motor request is permissible, track commanded versus proven state and expose faults. One final ordinary-control arbiter resolves Auto, Manual, maintenance and other command sources before the physical output mapper writes addresses. A separate safety system can remove energy or permission independently; the normal state machine neither creates nor proves a safety function.

Multiple sequence states must not write the same physical coil in distant routines. Default sequence requests false once, then allow only the active state to assert them. An exception—such as a valve required open during an approved controlled abort—belongs in the explicit Aborting state, not an unrelated override rung.

Worked fill–mix–drain state model

Normal and abnormal states

The teaching sequence uses seven states:

ID	State	Ordinary command intent	Normal exit	Abnormal exit
0	Idle	all process requests inactive	Start edge and Ready → Filling	invalid/restart reconciliation → Faulted or recovery policy
10	Filling	fill valve requested	qualified HighLevel → Mixing	timeout/abort/permissive policy
20	Mixing	mixer requested	recipe duration complete → Draining	feedback fault/abort/permissive policy
30	Draining	drain valve requested	qualified LowLevel → Complete	timeout/abort/permissive policy
40	Complete	process requests inactive	acknowledgment/new-cycle policy → Idle	diagnostic fault policy
95	Aborting	defined safe-path requests only	safe feedback and Abort released → Idle	abort-path timeout → Faulted
98	Faulted	ordinary process requests inactive	healthy authorized reset → Idle	remain latched

The downloadable compact example deliberately omits a generic Hold state because hold behavior is process-specific. Freezing a mixer timer while leaving the mixer running is different from stopping it and preserving remaining time. Holding a vessel while heat input continues can be dangerous or ruin material. Add Hold only after defining output, timer, recipe, quality, agitation, thermal and resume behavior for every state.

Put transition priority in the code and specification

Two guards can be true in one scan. High level may arrive on the exact scan that the fill timeout expires. Abort may arrive as normal completion becomes true. A reset request may coincide with the fault condition disappearing. Choose and test priority explicitly.

One defensible example is:

1. safety permission is handled by the safety architecture, outside this ordinary sequence;
2. internal invalid-state handling removes ordinary commands;
3. Abort overrides normal transitions;
4. active fault conditions override normal completion where the process requires it;
5. qualified completion outranks timeout at the exact equality boundary where documented; and
6. lower-priority normal alternatives are evaluated in a declared order.

There is no universal ranking for every process. For a fill operation, treating HighLevel as success at the timeout boundary can be valid if the feedback is fresh and qualified. Another specification may classify it as a timing failure. What matters is that the cause/effect, implementation and acceptance test agree.

One transition per PLC execution

Use CurrentState and NextState

The core two-phase pattern is:

FillValveCmd := FALSE;
MixerCmd := FALSE;
DrainValveCmd := FALSE;
NextState := State;
CandidateReason := None;

CASE State OF
    Filling:
        FillValveCmd := TRUE;
        IF HighLevel THEN
            NextState := Mixing;
            CandidateReason := HighLevelReached;
        ELSIF StateElapsed >= FillTimeoutTicks THEN
            NextState := Faulted;
            CandidateReason := FillTimeout;
        END_IF;
    (* remaining states *)
END_CASE;

IF NextState <> State THEN
    PreviousState := State;
    State := NextState;
    LastReason := CandidateReason;
    StateElapsed := 0;
ELSE
    StateElapsed := StateElapsed + 1;
END_IF;

The CASE executes actions for the state that was current at the start of the call. It can nominate one next state. The final block commits that one transition. Commands for the new state begin on the next execution. This creates a predictable observation point and prevents Filling → Mixing → Draining in one scan when multiple conditions are already true.

Do not copy the numeric/tick syntax blindly. The downloadable code is educational IEC-style ST; enumeration qualification, initialization, maximum integer syntax and timer types vary. In production, use the exact periodic task or vendor timer semantics, document whether comparisons occur before or after time accumulation, and test just-before/equal/just-after boundaries on the target.

Scan-by-scan trace

Assume a 10 ms periodic task, state starts at Filling, HighLevel is false in Scan 100 and becomes qualified before Scan 101:

Scan	state at entry	qualified inputs	command evaluated	next-state proposal	state after commit	elapsed after call
100	Filling	HighLevel false	Fill true	Filling	Filling	18
101	Filling	HighLevel true	Fill true	Mixing	Mixing	0
102	Mixing	HighLevel true	Mixer true	Mixing	Mixing	1
103	Mixing	MixDone false	Mixer true	Mixing	Mixing	2

The fill request remains true during the execution that observes completion and becomes false on the next execution. The equipment/physical output update point determines when hardware sees the change. If the application requires outputs to change in the transition scan, implement an explicit exit/arbitration phase and test the exact task/I/O update sequence; do not quietly write the output a second time after the CASE.

Entry, exit and state timers

Detect entry without duplicating transitions

Entry is true when a transition has just committed into the state. Common patterns include a Transitioned flag plus new State, comparing State with PreviousEvaluatedState, or platform-native SFC step-entry actions. Use entry for one-time initialization, recipe snapshot or diagnostic event creation—not for a physical output that must remain asserted continuously.

Exit information should be recorded at commit: from state, to state, reason, timestamp or tick, batch/recipe ID and relevant values. Do not clear evidence before the historian/HMI can consume it.

Distinguish three forms of time:

Time	Purpose	Reset point	Example
state elapsed	diagnostic time since state entry	every committed transition	“Mixing for 00:03:27”
process duration	normal recipe target	state entry or accepted recipe snapshot	mix for 180 s
maximum allowed	fault/abnormal threshold	state entry; independent policy	mixer feedback within 2 s; drain complete within 90 s

A normal recipe duration is not necessarily a timeout. Completing Mixing after 180 seconds is expected; losing mixer feedback for two seconds is a failure; remaining in Mixing for 20 minutes may be a separate supervisory timeout. Give each timer a requirement and diagnostic identity.

Hold, stop, abort, fault and reset

These commands are not synonyms

Request/state	Intended outcome	State memory	Output behavior	Return path
Hold	pause in a defined resumable condition	preserve explicit resume state/data	project-specific; not automatically “freeze everything”	Resume after cause/conditions clear
Stop	controlled end of activity	often does not preserve active step	complete an orderly stop path	Idle/Stopped
Abort	leave normal procedure through defined safe path	preserve cause and relevant context	remove normal requests; issue approved abort-path requests	Idle or Faulted only after proof
Fault	represent detected failure	latch first-out evidence	defined fault response; ordinary outputs normally removed	authorized reset/recovery
Reset	acknowledge and clear eligible latched state	archive then clear permitted evidence	must not create a start edge	Idle or recovery-check state

“All outputs off” is not a universal safe process action. A cooling, ventilation, lubrication or drain request may be required during an abnormal path, subject to the hazard analysis and independent safety design. Represent that action in an explicit abort/fault-recovery state with feedback and timeout, while safety-rated functions remain in the safety system.

Reset must be conditional. Require the initiating request released, active failure cleared, safe feedback established, correct mode/authority and a new reset edge. Then return to a non-running state. Reset should not both clear a fault and reinterpret a held Start as permission to energize.

First-out faults and sequence diagnostics

Record why the state changed

A state number alone tells an engineer where the sequence stopped, not why. Expose at least:

• current and previous state names/IDs;
• state elapsed time and maximum expected time;
• last committed transition and reason;
• first-out fault code, state and timestamp/tick;
• active hold/stop/abort request and accepted command owner;
• every transition guard as a readable Boolean with value quality/age;
• commands beside independent feedback;
• recipe, batch and software revision identifiers;
• bounded transition history; and
• retry/recovery attempt count.

First-out means the first decisive unacknowledged cause wins. If Filling times out, the fill request is removed, and valve feedback then reports closed unexpectedly, FillTimeout remains first-out while the later mismatch can remain an active secondary condition. Overwriting the initiating cause with consequences produces the familiar maintenance report “machine faulted because machine is faulted.”

Do not create an unbounded log in a PLC. Store a fixed ring buffer or publish transition events to a qualified historian. Each event should be written atomically enough that state, reason and time agree. Define wrap, power-cycle and time-source behavior.

Troubleshoot from state and guards, not coils alone

Symptom	Evidence to compare	Likely design or field causes	Decisive next check
never leaves Idle	Start edge, mode, Ready, rejection reason	held request, no edge, mode owner, stale permissive	trend raw request and accepted edge in same task
skips a step	state history, multiple state writes, commit count	cascading IFs, duplicate sequencer call, HMI state write	prove one state writer and one commit per execution
stuck Filling	fill command/feedback, level value/quality/age, elapsed	valve failed, sensor never qualifies, timeout disabled	test feedback chain and exact timeout setting
faults at normal completion	completion and timeout guard values/priority	equality priority wrong, task/timer boundary	replay just-before/equal/after trace
resumes to wrong step	saved resume state, mode/hold transitions	one shared “paused” bit, resume state overwritten	inspect committed Hold entry and resume target
reset starts machine	held Start, edge memory, reset/start priority	level-driven Start, edge memory reset incorrectly	require request release and separate reset edge
HMI state differs from logic	publish task/order, mapping, stale timestamp	duplicate state tags, asynchronous copy	identify authoritative state owner and freshness
timer resets randomly	instance call, conditional execution, task ownership	FB skipped, local temporary timer, duplicate calls	prove one persistent instance called every intended scan
output stays on after state exit	final writer, manual/override, output map	multiple writers, latched coil, task order	cross-reference every write and command owner
first fault changes	fault latch/update order	secondary symptoms overwrite cause	add first-write-wins plus active-fault list
restart continues unexpectedly	retained state, boot flag, feedback reconciliation	state retained without authorization	trace cold/warm/download policy from first scan
recipe changes mid-cycle	accepted recipe version and live editor value	sequence reads mutable HMI recipe continuously	snapshot accepted parameters with batch ID

Startup, restart, retention and online change

Define every restart class

“On restart go to Idle” is incomplete. Consider cold power-up, warm restart, RUN after STOP, task re-enable, watchdog recovery, program download, online change, controller replacement and communication reconnect. The exact distinctions are target-specific.

For each class, decide:

1. whether State, recipe, elapsed time, first-out and history are retained;
2. what ordinary commands are permitted on the first executions;
3. how actual valve, motor, axis and level feedback is reconciled;
4. whether the sequence enters Idle, Faulted, Hold or a dedicated RecoveryCheck state;
5. what operator/remote authority must reauthorize movement; and
6. what evidence records the restart and decision.

Blindly forcing Idle can lie about a vessel that remains full or a conveyor part midway between sensors. Blindly retaining Mixing can re-energize equipment after power returns. A recovery-check state can read qualified physical state, remove ordinary commands, require inspection or establish a controlled route before allowing Idle.

Retain stable business/process facts only when the risk assessment requires them: batch ID, accepted recipe version, material position or completed phase. Transient edge memory, timers and commands may need reinitialization. Verify the exact platform’s retain/persistent memory, download initialization and online-change behavior; source-level RETAIN syntax alone is not recovery evidence.

Snapshot recipes and parameters

Do not read a mutable HMI recipe structure every scan during a batch. Validate and accept a versioned recipe at the start boundary, copy the permitted parameters into an active-cycle snapshot and record its ID/hash. Reject or queue changes during active execution unless the specification permits a controlled parameter update. Bounds belong in both recipe validation and equipment control.

ISA-88 is useful when procedural elements and reusable equipment phases must be separated. It provides models and terminology rather than a ready-made PLC program. The sequence still needs exact phase command/state handshakes, arbitration, failure response and target validation.

Manual, Auto and sequence ownership

Keep state separate from mode

Mode answers who or what may command equipment; state answers what the sequence is doing. Do not overload Step 0 to mean Idle, Manual, Faulted and NotReady. Define Auto, Manual, Maintenance and other modes in an arbitration layer with one owner and visible command source.

When Auto changes to Manual during an active state, choose a policy: reject the mode change, enter Hold, execute controlled Stop or transfer only after the equipment reaches a boundary. Never let both paths write the same output. When returning to Auto, require an explicit resume/restart decision rather than treating the mode bit as a Start command.

Manual operation must honor the approved interlocks and equipment limits appropriate to that mode. It must not mutate sequence state simply to make the HMI animation follow a manually operated valve. Instead, the sequence observes equipment feedback and reconciles through its defined hold/recovery path.

Vendor and language implementation notes

IEC Structured Text CASE

An enumeration plus CASE is readable, diffable and portable at the pattern level. Portability ends at exact enumerated-type syntax, initialization, timers, retain/persistent behavior, task scheduling, I/O process images, event logging and online change. Some targets support methods, properties, interfaces and object-oriented state patterns; do not add abstraction that makes online fault diagnosis harder for the plant team.

IEC Sequential Function Chart

SFC represents steps, transitions, actions and branch structures. Current CODESYS documentation states that alternative branch transitions are checked left-to-right and the first true branch opens; parallel branches execute together. That ordering is a priority rule, not a neutral drawing detail. Current Schneider documentation likewise distinguishes alternative and parallel branches. Beckhoff documents step/transition pairing and SFC online behavior. Verify action qualifiers, implicit flags, step time, processing order and reset semantics in the exact version.

PLCopen’s SFC construction guidance provides do/don’t patterns and maps a PackML example to SFC. It does not certify a specific application or establish a machine’s safe response.

Rockwell ladder sequencers and SFC

Studio 5000 sequencer instructions SQI, SQL and SQO target consistent, repeatable operations. Current SQO documentation states that a false-to-true enable increments the control position, selects array data, applies a mask and combines it with the destination. Treat the enable edge, .POS, .LEN, mask and destination ownership as part of the contract. A masked destination can preserve unrelated bits, which is powerful but easy to misread during troubleshooting.

Use explicit state logic or Studio 5000 SFC when branching, abnormal recovery and readable state evidence outweigh a compact output table. Confirm controller family and available-language support; never use ordinary sequencing instructions as a safety function.

Siemens S7-GRAPH and CASE

S7-GRAPH is Siemens’ graphical sequential-control surface for the supported STEP 7 generations. Siemens documentation demonstrates designing, downloading and testing a sequential control system. Current projects may also implement explicit state machines in SCL/Structured Text or ladder. Exact GRAPH availability, block interface, supervision/interlock behavior, diagnostics and migration depend on STEP 7/TIA edition, CPU and project version. Preserve those dependencies in the software manifest.

CODESYS, Beckhoff, Schneider and Omron

Ecosystem	Native/typical choices	Verify before translation
CODESYS	SFC editor or ST CASE; steps/actions/transitions and implicit variables	SFC processing order, action qualifier behavior, task, compiler/runtime version
Beckhoff TwinCAT 3	SFC or ST within persistent PLC instances	XAE/XAR build, task call order, step actions, boot project and retain data
Schneider Machine Expert	SFC or ST/LD POUs	controller support, SFC processing/flags, task and initialization behavior
Omron CJ/CS/CX lineage	SFC support where documented, ladder/ST depending CPU/tool	CPU/software generation, action/transition language, memory/address behavior
Omron NJ/NX/Sysmac	typed variables and ST/ladder patterns; product-specific sequence support	exact CPU/IDE language features, task/retain and online-change rules

The vendor mapping is a translation register, not proof that identical source compiles or runs identically. Translate one state/guard/action at a time, then run the same acceptance matrix on each target.

Acceptance-test the graph

Test transitions, not only end-to-end cycles

The downloadable matrix contains 24 cases. At minimum prove:

• every allowed normal transition;
• every disallowed/illegal transition attempt;
• each guard false individually;
• simultaneous guards according to declared priority;
• completion just before, exactly at and just after timeout;
• command versus feedback disagreement;
• bad/stale feedback quality;
• Hold/Resume from every eligible state;
• controlled Stop and Abort from every active state;
• abort-path failure;
• first-out preservation with secondary faults;
• reset rejection and accepted reset with request release;
• cold/warm/download/task restart policy;
• Auto/Manual transfer and one command owner;
• recipe change during a cycle; and
• invalid enumeration/default branch.

State coverage is not transition coverage. Visiting all seven states once does not prove every path, priority or failure response. Build a transition table where rows are current states, columns are events/guards and cells define next state, reason and action. Blank must mean “stay with explicit reason” or “illegal and fault”—never “nobody decided.”

Progress from logic to physical evidence

Test level	What it can prove	What it cannot prove alone
deterministic ST/unit harness	next-state logic, priority, counter boundaries, first-out	exact target timer/task/I/O behavior
integrated application simulation/emulation	object handshakes, HMI mapping, supported runtime behavior	all modules, networks, device physics or safety
target/HIL	exact controller execution, I/O/network/device simulator interactions	complete installed mechanics/process/operator behavior
FAT	assembled panel, devices, HMI, sequence, faults and controlled recovery	site utilities, installed field conditions and production material
SAT	installed process, wiring, operations and handover	future untested software/configuration changes

Fault injection requires authorization and a safe fixture. Do not force physical outputs to “get through” a sequence. Inject through qualified test interfaces, simulate feedback only under controlled visible mode, and prove teardown removes forces, bypasses and simulated values.

Practical design review checklist

Before release, a reviewer should be able to answer yes to all of these:

Review question	Evidence
is one state authoritative?	one declared owner and cross-reference
is one transition committed per call?	two-phase pattern or documented SFC semantics plus trace
does every state default and own its commands?	output/request ownership map
are command and feedback separate?	typed interface and timeout tests
are simultaneous guards prioritized?	transition table and equality tests
are hold/stop/abort/fault distinct?	cause/effect and state diagram
is reset conditional and non-starting?	reset-rejection/release tests
are restart/download rules explicit?	restart matrix and target evidence
is recipe data snapshotted/versioned?	batch record and mutation test
are diagnostics actionable?	first-out and bounded history example
is manual/auto arbitration single-owner?	command-source trace and mode tests
are physical and safety limits acknowledged?	HIL/FAT/SAT and safety lifecycle records

Practice the sequence logic interactively

Use the Structured Text simulator to rehearse state, guard, timeout and first-out patterns from the downloadable example. Vary HighLevel, LowLevel, Abort and Reset cases and compare the trace with the acceptance matrix.

Disclosure: PLCProgramming.io and PLCSimulationSoftware.com share ownership. The browser tool is a generic logic-learning environment, not Studio 5000, S7-GRAPH/TIA Portal, CODESYS, TwinCAT, Machine Expert, Sysmac Studio or a controller target. It cannot prove vendor SFC processing, compiler behavior, task/I/O timing, persistence, online change, devices, networks, process physics or safety response. Evaluate this CTA by scenario start, registration and paid conversion—not clicks alone.

Answer map for engineers and AI assistants

Question	Concise answer
What is a PLC sequencer?	Logic that advances a controlled process through ordered steps based on time, events or qualified feedback.
What is a PLC state machine?	One explicit current operating state with a defined set of guarded transitions to other states.
Is a sequencer a state machine?	A linear step sequencer is a restricted state machine; branching/recovery models are broader.
How should a PLC state machine be coded?	Default commands, evaluate one current state, propose one next state, then commit once per execution.
Why use NextState?	It prevents multiple cascaded transitions and creates a clear transition-evidence point.
Should step bits drive outputs?	State-owned requests may drive an arbiter; physical outputs should still have one final owner and feedback proof.
What is SFC?	IEC 61131-3 graphical step/transition elements for structuring chronological control flow.
When is SQO appropriate?	Fixed indexed/masked output patterns; not by itself for complex feedback and recovery.
What is first-out?	The earliest decisive unacknowledged failure is retained while later symptoms are recorded separately.
Can a sequence resume after power loss?	Only if a documented restart policy reconciles retained state, real feedback, material and authorization.

Frequently asked questions

What is the difference between a PLC sequencer and a state machine?

A sequencer emphasizes ordered steps, often linear. A state machine emphasizes stable operating states and allowed guarded transitions, including branches and abnormal paths. Many practical PLC sequences are implemented as state machines.

What is the best way to program a PLC sequence?

Use the simplest representation that keeps ownership and recovery explicit. For branching logic, an enumerated CASE state machine or SFC is usually clearer than scattered step bits. For fixed patterns, a table or sequencer instruction may be appropriate.

Why should a PLC make only one state transition per scan?

It prevents a set of simultaneously true conditions from cascading through multiple states in one execution. It also makes commands, transition reasons and scan traces deterministic and testable.

Should PLC outputs turn off before a CASE statement?

Default sequence requests inactive once before evaluating the active state, then let that state assert the required requests. A final equipment/command arbiter should own physical outputs and enforce mode, permissive and safety-interface priorities.

How do I add a timeout to every PLC step?

Maintain state elapsed time that resets on committed entry, and compare it with a documented maximum for that state. Keep normal duration and feedback-response timeouts separate. Test just-before, equal and just-after boundaries.

What happens when completion and timeout are true in the same scan?

The documented priority decides. Use ordered IF/ELSIF guards or equivalent SFC rules, record the selected reason and acceptance-test the equality case. There is no safe universal assumption.

How should Hold work in a PLC sequence?

Define it per state: which outputs remain, which timers continue, what material/process limits apply, what state is preserved and what permits Resume. “Freeze everything” is not a sufficient or universally safe policy.

What is the difference between Stop and Abort?

Stop usually follows a controlled normal stopping path. Abort overrides normal procedure and enters a defined abnormal safe path, preserving cause and requiring physical proof before returning. Project terminology must be specified consistently.

How do I prevent Reset from restarting the sequence?

Require the original request released, fault cleared, safe feedback, authorized reset edge and return to Idle or RecoveryCheck. Keep Start and Reset edge memories and priorities separate.

Should PLC sequence state be retentive?

Only under a documented restart strategy. Retaining state can preserve material context but may reissue commands after power returns. Reconcile real feedback and require appropriate reauthorization before movement.

When should I use Sequential Function Chart?

Use SFC when graphical steps, transitions, alternative branches or parallel branches improve engineering and online diagnosis. Verify the exact platform’s processing order, action qualifiers, initialization and restart behavior.

When should I use a Rockwell SQO instruction?

Use SQO for consistent indexed output patterns where its array, mask, destination and edge-driven position semantics fit. Add separate feedback, fault, timeout and recovery logic; do not treat the table as physical proof.

How do I troubleshoot a sequence stuck on one step?

Inspect current state, elapsed time, every transition guard with quality/age, command versus feedback, active hold/abort/fault, and first-out history. Then verify one state writer, one FB call and timer-instance persistence.

Can a browser simulator validate my production sequencer?

No. It can help rehearse supported state logic and test cases. Validate the exact source, toolchain, runtime, task, I/O, devices, process, restart behavior and safety functions using the required target, HIL, FAT and SAT evidence.

Primary sources and review trail

Reviewed 31 August 2026. Product behavior and documentation versions change; preserve the exact manual/tool/runtime revision with the application test record.

1. IEC 61131-3:2025 — current syntax/semantics scope for ST, LD, FBD and SFC structuring elements.
2. PLCopen Software Construction Guidelines: SFC — official SFC construction guidance and PackML mapping example.
3. PLCopen downloads — official SFC and OMAC PackML mapping resources.
4. CODESYS SFC overview — steps, transitions and chronological sequence scope.
5. CODESYS SFC processing order — documented verification, action and transition processing.
6. CODESYS SFC branches — alternative/parallel branch behavior and evaluation order.
7. Rockwell Studio 5000 sequencer instructions — current SQI/SQL/SQO role summary.
8. Rockwell Sequencer Output (SQO) — array, mask, destination, position and execution semantics.
9. Siemens S7-GRAPH sequential-control example — official graphical sequential-control design/program/test material.
10. Beckhoff TwinCAT SFC programming — current SFC POU and step-transition editor workflow.
11. Beckhoff SFC steps and transitions — step/transition pairing and properties.
12. Schneider Machine Expert SFC — graphical action/step/transition scope.
13. Schneider SFC branches — documented alternative and parallel branch semantics.
14. Omron CJ2 software manual — SFC overview and ladder/ST action and transition context.
15. ISA-88 series — procedural, equipment, recipe and machine/unit-state context.
16. ISA-88 committee scope — batch-control terminology, architecture and sequential-control relationship.
17. ISA procedure automation and state-based control — state-based control and recovery context for continuous processes.

Scope and limitations

The diagrams, CSVs and Structured Text are vendor-neutral educational artifacts. They do not define a safe state, validate a process recipe, compile unchanged on every IEC platform or replace cause/effect review, hazard analysis, target tests, HIL, FAT, SAT or functional-safety validation. Exact task rate, timer equality, input filtering, I/O update, communication age, physical command arbitration, persistence, online change and restart behavior must be designed and proven for the selected controller, firmware, toolchain, modules, equipment and process.