IEC SFC Step Transition: Actions, Branches and Restart

An IEC SFC step transition describes how a Sequential Function Chart moves between active steps when its transition conditions are satisfied. Steps organise sequence state; actions define work associated with that state. Correct interpretation also requires the chart's branch rules, action qualifiers and execution settings. The diagram alone does not specify every runtime detail.

This reference helps South African PLC learners read SFC, Siemens GRAPH and Studio 5000 chart examples critically. The worked sequence processes fictional inspection data and changes display state only. It does not command a valve, heater or machine, and its explicitly chosen evaluation rules are not claimed as a native controller implementation.

This site has a commercial connection to PLC Simulator. Its educational tools can support sequence reasoning, but they do not guarantee native GRAPH or SFC compilation. The generated illustrations are conceptual learning scenes rather than vendor interfaces or evidence of production results.

Read steps, transitions and actions as separate elements

A step identifies a stage of the sequence, such as Waiting or Review. A transition contains the condition for advancing from its preceding active step or steps. An action describes associated work, which might update a display, call logic or manipulate a defined application variable according to its qualifier and execution rules.

Do not read a step box as proof that a physical output is on. The step's action may have an interlock, be delayed, be inactive under a particular mode or write a request later processed elsewhere. The actual output path needs its own review.

Element	Useful question when reading a chart
Initial step	What becomes active on the relevant initialisation path?
Active step	Which stage or stages currently hold sequence state?
Transition	Which complete Boolean condition permits progression?
Action	What work executes, when, and with what lifetime?
Alternative branch	Which one path is selected if several conditions are true?
Parallel branch	Which paths become active together and what permits their join?

A transition should express a testable condition. “Inspection complete” is incomplete if the program cannot distinguish a fresh completion for this inspection from a retained completion belonging to the previous one. Define the data source, validity and relevant request identity.

Use meaningful step and transition names. A name such as SampleReadyForCurrentRequest explains more than T3. Keep the code-level expression nearby so a reviewer can see whether the implementation includes the required freshness and quality checks.

A compact chart is useful for communicating the sequence, while a transition table exposes conflicting conditions and missing paths. Use both views when the diagram alone hides important decisions. The sequencer logic patterns guide develops requirements before choosing a graphical chart or Structured Text implementation.

Define the worked sequence's execution contract

The fictional exercise has five states: Waiting, Capture, Review, Complete and Held. Exactly one state is active in this model. Each invocation reads a coherent set of Boolean inputs and performs at most one state transition. Display indications are then derived from the resulting state.

StartEvent requests a new exercise cycle. SampleReady means a valid sample for the current request has been captured. Approved means that sample's review has been accepted. AckEvent acknowledges the completed result. Hold blocks progress, and ResumeEvent requests a return from Held to Waiting after Hold is false.

These names are contracts, not raw sensor aliases. The model assumes SampleReady and Approved already include their required quality and request association. An implementation must establish those conditions before treating them as transition inputs.

Current state	Condition and priority	Next state
Waiting	StartEvent true and Hold false	Capture
Capture	Hold true	Held
Capture	Hold false and SampleReady true	Review
Review	Hold true	Held
Review	Hold false and Approved true	Complete
Complete	Hold true	Held
Complete	Hold false and AckEvent true	Waiting
Held	Hold false and ResumeEvent true	Waiting
Any state	No applicable condition	Keep current state

Hold has priority over normal progression from Capture, Review and Complete. Waiting does not enter Held solely because Hold is true; it simply refuses the start request. Held does not resume automatically when Hold clears. These are deliberate teaching choices, not universal SFC rules.

Returning from Held goes to Waiting in this exercise. It does not resume the interrupted stage. A real process may require a different recovery decision based on what happened while execution was interrupted. Record that policy explicitly rather than assuming every sequence should restart or resume identically.

02

Trace normal progression one invocation at a time

Start in Waiting with all inputs false. On an accepted StartEvent, the model moves to Capture. A later valid SampleReady moves it to Review. Approved then moves it to Complete, and AckEvent returns it to Waiting.

Invocation	State before	Relevant accepted input	State after
1	Waiting	StartEvent	Capture
2	Capture	SampleReady	Review
3	Review	Approved	Complete
4	Complete	AckEvent	Waiting

Because the model allows one transition per invocation, supplying StartEvent, SampleReady and Approved together while Waiting still ends the first invocation in Capture. It does not skip directly to Complete. This makes the example's evaluation policy visible and testable.

Do not assume a native SFC uses that policy. Some engineering systems offer execution settings that allow progression through multiple immediately satisfied transitions. Confirm the chart's configuration before comparing a native trace with this worksheet. The PLC scan-cycle reference helps distinguish task execution from what a watch display happens to show.

A transition becoming true before its preceding step is active also needs interpretation. In the model, a valid input is considered when its relevant state is evaluated. Whether a real application should accept an already-true completion, require a fresh event or discard an old request depends on the interface contract.

For the teaching display, CaptureIndicator is true only when the resulting state is Capture, and ReviewIndicator only when it is Review. The two indications are never true together because this model has one active state. This is a software invariant, not proof about physical actuator interlocking.

Make alternative paths unambiguous

Consider Review with Approved and Hold both true. The table requires Held, not Complete. Implementing the normal transition as Approved without considering Hold could create competing eligible paths. The resulting selection might then depend on the chart's documented branch ordering.

For this exercise, the normal-path condition is Approved AND NOT Hold and the hold-path condition is Hold. They cannot both be true. The expressions make the policy visible even if the diagram is rearranged.

Approved	Hold	Normal transition	Hold transition
False	False	False	False
True	False	True	False
False	True	False	True
True	True	False	True

CODESYS documents evaluating alternative branches from left to right and opening the first whose transition is true. That is a specific implementation rule, not a reason to claim a universal IEC rule for every chart. See the CODESYS branch reference.

Mutually exclusive conditions can simplify review, but they do not eliminate the need to inspect the rest of the sequence. A different action may modify a condition, another chart may share data, or a request may be stale. Document the observation point and the values used for the decision.

A held sequence also needs a way to remain held. In the model, ResumeEvent while Hold remains true has no effect. When Hold becomes false, the model still waits for ResumeEvent. Returning to Waiting and receiving a new StartEvent occur through separate evaluations under the chosen one-transition policy.

03

Parallel branches require a complete join condition

A parallel chart can have more than one active step, so the single-state assumption of the worked sequence does not apply to every SFC. Consider a separate fictional exercise with two independent data checks: RecordCheck and LabelCheck. Each branch reaches its own ready step after completing its work.

The join requirement is that both branches are ready and JoinPermission is true. One branch completing early does not authorise completion of the combined operation. This can be written as RecordReady AND LabelReady AND JoinPermission for the teaching model.

RecordReady	LabelReady	JoinPermission	Join allowed
True	False	True	False
False	True	True	False
True	True	False	False
True	True	True	True

Test all eight Boolean combinations, including the four not displayed in this compact table. Also verify that ready states belong to the current request. Two true flags from different exercise cycles should not be interpreted as completion of one coherent job.

The CODESYS processing-order documentation states that a parallel convergence advances when all final branch steps are active and the following transition is true. It also describes action processing and transition evaluation order, which matter when diagnosing an unexpected trace. Consult the CODESYS SFC processing order.

Parallel chart paths do not automatically mean instructions execute simultaneously on separate processor cores. Read “parallel” first as a sequence-state relationship, then inspect the runtime's scheduling and action-order rules. Shared writes between branch actions still need ownership and conflict review.

Action lifetime is not just step lifetime

Action qualifiers influence when an action is active or executed. For example, CODESYS documents N as non-stored, S as stored until reset, and R as overriding reset. Its P qualifier also has a documented deactivation execution, so “pulse” should not be casually translated into “this code runs exactly once overall”. See the CODESYS action qualifiers.

Separate the lifetime of an action from the lifetime of a variable it writes. If an action assigns a variable true and later stops running, that alone does not universally specify what resets the variable. Inspect the language form, qualifier, native last-scan behaviour and any other writers.

For a fictional indication model, define NonStoredIndicator directly from StepActive on every evaluation. Define StoredIndicator to become true when StepActive is true and remain true until ClearStored is true, with clearing given priority in this model. This demonstrates different state lifetimes without claiming to reproduce every native action-control implementation.

Evaluation	StepActive	ClearStored	NonStoredIndicator	StoredIndicator
1	False	False	False	False
2	True	False	True	True
3	False	False	False	True
4	False	True	False	False

The stored indication survives step deactivation in evaluation 3. The model's explicit clear removes it in evaluation 4. If a real stored action has no reachable reset path, later sequence stages may continue to see its effect. Review normal completion, cancellation, holds and recovery when checking that path.

The set/reset priority reference explains stored Boolean state and simultaneous requests. Keep those state rules distinct from action execution count and chart progression.

04

Siemens GRAPH actions and project scope

Siemens' STEP 7 V20 standard-action reference covers GRAPH for S7-300, S7-400 and S7-1500. It describes N, S, R, delayed D and limited-time L actions, with interlocks affecting execution. This does not support describing GRAPH as historically S7-1500-only or treating every action as an ordinary continuously assigned coil. See the Siemens GRAPH standard actions.

Check the exact CPU, engineering edition and required options in the course or project quotation. Do not infer a universal additional GRAPH licence charge from an HMI diagnostic object's licensing requirements. Engineering, controller support and optional visualisation features are separate questions.

There is also no useful universal claim that GRAPH is slower than an equivalent CASE statement. A meaningful comparison needs equivalent behaviour, the same target, measured execution conditions and an agreed performance criterion. For learning, choose the representation that exposes the required sequence clearly, then verify target constraints.

Studio 5000 execution and restart settings

Rockwell's version 38.01 SFC Execution tab documents two progression modes: executing current active steps only, or continuing until a false transition prevents further progress. It also provides restart-at-most-recent and restart-at-initial choices, plus automatic reset, programmatic reset and no-last-scan options. These are project execution settings, not merely diagram formatting. See the Studio 5000 SFC Execution settings.

The same documentation notes that processing multiple steps in a scan can lead to watchdog timeout. A chart with immediately true transitions therefore needs a bounded progression review. Do not change execution mode simply to make a demonstration finish faster without examining its loops and workload.

Restart position also does not establish that retained process data is current or that external equipment is ready. A sequence can return to a familiar step with changed real-world conditions. Define how the application validates its context before continuing.

Review hold, restart and recovery as separate cases

In the worked model, Hold directs active processing into Held and blocks a new start in Waiting. ResumeEvent returns Held to Waiting only after Hold clears. These rules deliberately avoid pretending that a saved step identifier describes everything needed for recovery.

For an actual application, list the information needed to resume: the current request, confirmed completed work, relevant input validity and any external actions that may have occurred. Decide which information can be trusted after interruption and which must be reacquired.

Do not assume that restarting at the initial step is always harmless. Initialisation logic might repeat an external action. Nor should resuming the last step be assumed correct if the process changed while execution was interrupted. The appropriate policy comes from the application requirements and validation evidence.

In South African training discussions about power interruptions, ask learners to distinguish controller state from process state. A desktop exercise can demonstrate recovery decisions without claiming that a generic restart mode makes a batch or machine safe.

05

Debug the condition, action and observation point

When a chart appears stuck, begin with the active step set and the complete outgoing transition conditions. Record which operand is false and whether the operand belongs to the current request. Check quality and update timing before changing the transition expression.

When a chart advances unexpectedly, inspect competing branches, already-true completion flags and execution mode. If several transitions can execute in one invocation, a slow watch display may never show an intermediate step even though it was processed. Use suitable native trace or diagnostic evidence rather than inferring non-execution from one screen refresh.

When an indication remains active after leaving a step, inspect its action qualifier and all writers. Determine whether the action continues, the variable remains stored, or another routine assigns it. Those are different causes and need different corrections.

Use PLC program-testing exercises to organise expected state traces and counterexamples. Confirm the available educational scope. The model checks here do not demonstrate native chart compilation, scan timing or physical output behaviour.

Questions about SFC steps and transitions

Can more than one SFC step be active?

Yes, parallel sequence structures can represent several active paths. The worked five-state example deliberately permits only one active state. Check the chart structure and runtime rules before applying that invariant to a different SFC.

Does a true transition always move to the next step?

The relevant preceding step or steps must be active, and other documented conditions or execution settings may apply. In the teaching model, a true input for another state has no immediate effect. Native charts need their own checks for minimum step times, modes and branch eligibility.

Why does an S action remain effective after its step ends?

A stored action is designed to have a lifetime extending beyond its originating step until its reset conditions are met. Also distinguish continued action execution from a variable left at its last assigned value. Inspect the exact qualifier and reset path rather than assuming step deactivation clears everything.

Is SFC better than Structured Text for sequences?

Compare readability, available diagnostics, team familiarity and target support for the actual sequence. A chart can make branches visible; Structured Text can make state calculations explicit. Neither representation removes the need for clear transition priorities, data validity and recovery behaviour.

What should a PLC course in South Africa demonstrate?

Request a normal state trace, a simultaneous-condition case, a parallel join and a restart discussion using the stated controller and engineering version. Learners comparing training in Gauteng, KwaZulu-Natal or the Western Cape can use the same assessment questions. Avoid choosing from unsupported promises about platform speed or universal licence requirements.

06

Keep a sequence portfolio that another learner can verify

Include the transition table, initial state, input contract and expected trace before the chart screenshot. Mark the chosen evaluation policy and explain which results came from a mathematical model versus native software. Add a counterexample where stale completion or competing conditions would produce the wrong path.

For additional state-expression practice, explore Structured Text learning resources, checking the current exercises and access terms. A text model can support reasoning without being described as an imported native SFC chart.

A useful SFC review makes active states, transition eligibility, action lifetime and recovery policy visible together. That evidence lets another person follow the sequence and understand why it advances, waits or enters a hold condition.