S7-GRAPH Programming: Sequencers, Interlocks, and Branches

Overview

S7-GRAPH is the optional STEP 7 package for programming sequential control systems using a state-machine style notation that maps directly to the Sequential Function Chart (SFC) element of IEC 61131-3. According to Siemens, "GRAPH is a graphic programming language for creating sequential control systems. Sequences can be programmed in a fast straightforward manner using sequencers" (see Creating GRAPH programs (S7-300, S7-400, S7-1500)). The same package is available as S7-GRAPH V5.3 for Classic STEP 7 on S7-300/400 and as the integrated GRAPH editor in TIA Portal for S7-300/400/1500.

An S7-GRAPH sequencer expresses a process as a network of steps joined by transitions with executable actions attached to steps and interlocks / supervisions guarding the run time behaviour. The sequencer compiles to a Function Block (FB) plus an instance DB that holds step state, mode selection, fault flags, and diagnostic timers. The runtime scans the active step every OB1 cycle, evaluates its leaving transition, fires any edge-driven actions, and walks forward when the transition becomes true.

Engineers new to S7-GRAPH typically have questions in five areas, which are all covered below:

1. Interlocks and supervisions
2. Event-dependent actions versus permanent operations
3. Terminations and jumps
4. Alternative branching (OR)
5. Simultaneous branching (AND)

Reference target: TIA Portal V20 with the S7-GRAPH optional package, on S7-1500 (CPU 1515-2 PN as a representative part number). Differences for S7-300/400 and for Classic STEP 7 are flagged inline.

Prerequisites

Confirm the following before creating an S7-GRAPH project:

The minimum firmware for S7-GRAPH online watch on SIMATIC S7-PLCSIM is V4.5 of PLCSIM with TIA Portal V17+; older combinations produce read-only views of the sequencer.

Sequencer Block Architecture

An S7-GRAPH sequencer is always an FB of type GRAPH. The editor builds the state machine inside the FB; at compile time it generates the instance DB containing:

• Step flags — one bit per step (S1, S2, …, Sn)
• Active step — current step number (S_ACTIVE, INT)
• Mode control byte — AUTO / MANUAL / TAP / TOP / OFF / INIT
• Fault flags — supervision error (FAULT), interlock error (S_INTERLOCK), acknowledgement request (ACK_SF_REQ)
• Elapsed-time counters for every step
• Transition flags used for diagnostics
• Edge memory for rising / falling event actions

The standard interface of the sequencer FB exposes the symbols below. Their semantics are identical in Classic STEP 7 and TIA Portal:

The complete predefined set is documented in the TIA Portal online help under Sequencer interface parameters. For Classic STEP 7 the same list is in the S7-GRAPH V5.3 manual (module C1 of the S7-300/400 training package, available through the Siemens Automation Cooperates with Education (SCE) portal).

Steps, Transitions, and Actions: The Core Elements

Three primitives appear at every junction in the GRAPH editor:

• Step — represents a stable state of the process. While active it executes its attached actions and accumulates elapsed time.
• Transition — Boolean condition evaluated between two steps. When the leaving step is active and the condition is true, control advances to the next step.
• Action — commands issued from a step. Each action has an action qualifier that defines when the action fires and whether the assigned operand is stored.

The qualifier is the single most important piece of metadata on an action line:

The qualifier is placed immediately before the operand in the action editor. Examples:

Permanent vs. Event-Dependent Actions

Actions themselves are split into two kinds based on their position inside the step object.

Permanent operations (Ständige Anweisungen) belong to the body of the step, not to an action line. They run on every scan for which the step is active, independent of any edge. Typical uses:

• Set a runtime flag (e.g. "DB_State".step_active_X1 := 1;)
• Compute a derived value every cycle
• Override interlocks in commissioning or test mode

Because permanent operations repeat every scan, do not place level-sensitive on/off commands there. Use an N-qualified action instead, otherwise the assignment happens on every cycle rather than on a clean step edge.

Event-dependent actions sit in the action list of a step and execute on a specific event defined by the qualifier. Common events:

• Step entry — qualifiers S, D, P, SD, DS
• Step exit (falling edge, available for stored qualifiers) — R, SL
• Step active (level) — N
• Conditional — qualifier wrapped in parentheses, e.g. (N), (S), (D)

The practical rule: use an event-dependent action for anything that should fire once, and use a permanent operation only for cyclic logic that must repeat every scan.

Interlocks (Intra-Step Logic)

From the S7-GRAPH manual: "An interlock is a programmed condition within a step. An interlock influences the execution of individual actions."

Mechanically, an interlock is a Boolean condition written into the dedicated interlock field of a step — for example "PartPresent" AND NOT "E_StopActive". While the step is active:

• If the interlock is true, every action of that step executes normally; all qualifiers fire on their respective edges.
• If the interlock is false, every action whose qualifier is wrapped in parentheses (e.g. (N), (S), (D)) is suppressed.

An interlock is a per-step enable signal. It does not stop the sequence from advancing, and it does not appear as a fault. It is the cleanest way to express "this step is allowed to drive outputs only when safety pre-conditions are met."

Example: a "Press ram extend" step needs both a part-present sensor and a guard-closed signal. Without an interlock the ram extends whenever the step is active regardless of guard state. With an interlock it only extends while both conditions remain true — if the operator opens the guard mid-stroke the action drops instantly, but the sequence can still advance when the leaving transition becomes true.

To wire a real signal as interlock, place the condition in the step's interlock field (TIA Portal shows it as the top half of the step box, marked with an I). The compiler then routes the condition to the action suppression logic.

Supervisions (Transition Watchdogs)

From the same manual: "A supervision is a programmable condition within a step. A supervision influences the way in which control passes from one step to the next."

A supervision is also a Boolean attached to a step. While the step is active the runtime checks the condition every scan:

• If the condition becomes true while the leaving transition is also true, the sequencer treats this as an error. The leaving transition is blocked, the sequencer enters the ERROR state, and FAULT rises.
• The operator must then ACK_SF to clear the fault, after which the sequence can advance manually.

The canonical pattern is "step X must complete within N seconds". The condition is then "DB_Seq".STEP_X.T > 10s (elapsed-time supervision). When the leaving transition is satisfied but the process hasn't moved, supervision fires, the sequence goes into ERROR, and the operator diagnoses.

A supervision is the right place to put:

• Maximum-time assertions ("cycle complete in < 30 s")
• Uniqueness constraints ("two limit sensors reading active simultaneously")
• Sensor plausibility ("pressure above 5 bar AND flow below 1 L/min")
• Watchdog between a go command and the done feedback

Implementation tip: combine the supervision with an alarm action so the HMI shows both the symbolic step number and a human-readable fault text. The supervision field (lower half of the step, marked with an S) accepts both a single Boolean and a structured condition with timer references.

When the sequencer enters ERROR the S_ACTIVE output still reflects the step that caused the fault. Holding INIT_SQ resets the sequence to step 1; alternatively a manual S_NEXT after ACK_SF walks the sequencer past the offending transition.

Alternative Branching (OR)

GRAPH supports two non-linear shapes: alternative (exclusive) branches drawn with a single fork line, and simultaneous (parallel) branches drawn with a double fork line.

Alternative branches are exclusive: only one of the parallel paths is selected per cycle.

• The leaving transition below step N opens.
• The incoming transition of the lane whose condition first becomes true is selected; any remaining lanes become inactive for that cycle.
• The branches converge at a join transition; control proceeds once the selected lane completes.

Use alternative branches for either/or dispatch: route product to line A or line B based on recipe, go to cleaning or to maintenance from "end of batch", pick between two recipes with same preconditions.

Rules of thumb when designing an OR split:

• Put the most safety-critical lane first (lowest transition number) so it cannot be starved by a slower upstream signal.
• Avoid overlapping true transition conditions — overlapping trues cause non-deterministic selection. If overlapping is unavoidable, prefer simultaneous branching with a downstream decision step instead.
• Label each transition with the condition it represents (e.g. "recipe".mode = 2) so the editor view remains self-documenting.

Simultaneous Branching (AND)

Simultaneous branches are parallel: when the leaving transition is true, all incoming lanes fire at once and all parallel steps become active together. Each lane then processes independently, and the sequence does not leave the branching until the joining transition downstream becomes true.

Mechanically:

1. Step N has a transition below it that branches into two or more parallel lanes drawn with a double horizontal line.
2. When the transition is true, both downstream steps become active simultaneously and S_MORE rises.
3. Each lane processes independently (interlocks, supervisions, jumps, actions are all local).
4. A joining transition downstream waits for the last active lane to finish before the merge step activates.

Use simultaneous branches for genuinely independent work that should not serialize:

• Two valves opening and closing in parallel as part of the same phase
• A pump pre-charge running concurrently with a heater warm-up
• Synchronising motor axes that must share a common handshake but not interlock

Be aware of:

• The merge transition must explicitly handle "all parallel steps finished". The default is an AND across the preceding step flags; make the editor render the joining condition so it is auditable.
• Cross-lane data exchange must go through instance-DB bits because intra-scan ordering is deterministic but cross-lane ordering is not.
• Every parallel lane can produce its own supervision fault; build an aggregated ERROR handler that lists all parallel contexts.

Terminations, Jumps, and the Sequence End

Three mechanisms handle non-linear control flow.

Sequence end (terminator): a step whose transition connects to the End object. When the transition becomes true, the sequencer switches to the OFF state, every step deactivates, and the scan stops. To restart, drive INIT_SQ from the calling program or the HMI.

Jump to step: drawn as an arrow from a transition to a step upstream or downstream of the current step. The jump may be conditional (only fires when the transition is true) or unconditional (always fires when the transition evaluates true). Important: only the target step becomes active after the jump — the jumped-over steps do not see a rising edge and therefore do not fire any edge-triggered actions. Pair jumps with a dedicated transition reset bit to avoid stale flags.

Loop back (jump to earlier step): a jump to an earlier step implements retry/iterate logic. Define a maximum-loop counter using the sequencer's UDINT counter in the instance DB, and use a separate transition to break out of the loop into a fault branch when the counter exceeds a threshold.

Branch terminator (empty step): an alternative or simultaneous lane can be terminated early with an empty terminator step. The runtime evaluates the empty terminator immediately and moves to the joining transition.

The canonical retry pattern with alternative branching is: try → success transition to next step → failure transition jumps back to try with a counter increment step in between.

Operating Modes and the Control Interface

S7-GRAPH sequencers expose four operating modes plus two reset states, normally driven by an HMI control block:

The mode bits are mutually exclusive. The compiler generates a runtime error in the instance DB if more than one mode bit is active in the same cycle.

For each step you can also configure step-specific permission bits (often grouped as S_AUTO, S_TAP, S_MAN, S_TOP) so that the same step behaves differently in AUTO vs MANUAL — for example, jogging an axis in MANUAL while locking the axis in AUTO.

Commissioning, Verification, and Debug

Take an S7-GRAPH block from source to a verified running sequencer with this sequence:

1. Compile the FB in the GRAPH editor (Project → Compile). Errors appear in the diagnostics window. Common issues are dangling transitions, unconnected alternative branches, action qualifiers with mismatched brackets, and missing operator rights.
2. Download FB and instance DB. Use Online → Download to Device in TIA Portal (or PLC → Download in Classic). In RUN mode, both should download; in the unlikely event of a download error on the GRAPH FB, switch to STOP and retry.
3. Open GRAPH Watch (Online → Monitor / Modify) and view the sequencer in three panes: Structure (steps + transitions with raw Boolean values), Active Status (current step, elapsed times, mode), and Cross-references.
4. Force SW_AUTO first, then drive the initial transition by simulating the binary inputs the sequencer expects. Check that the active step number changes only when the leaving transition is true.
5. Trigger a supervision fault by holding the leaving transition false for longer than the supervision time. Verify that the sequencer enters ERROR, that FAULT rises, and that a rising edge on ACK_SF clears it.
6. Verify interlocks by clearing the interlock bit while the step is active. Actions marked (N), (S) etc. should be suppressed — their assigned operand should not see a rising edge.
7. Verify branching by alternating the parallel path conditions. In alternative branching, only one lane activates per cycle; in simultaneous branching, both lanes activate at the same time and S_MORE rises.
8. Walk the sequencer in TAP mode: set SW_TAP, then pulse S_NEXT repeatedly. Confirm that every step takes exactly one operator click to advance and that no step is skipped.
9. Verify the HMI tag wiring with a watch table on the GRAPH instance DB: every HMI-controlled BOOL/INT (mode, ACK_SF, INIT_SQ, OFF_SQ, S_SEL) must read and write to the exact symbolic address shown.

The instance DB layout is fully symbolic and can be inspected in a watch table. Use the predefined UDT GRAPH_STATE (or the equivalent block-parameter view in the watch) for cross-referencing in diagnostic blocks.

Troubleshooting Matrix

FAQ