ES
Siemens S7-Graph: Sequential Control Programming Guide

Siemens S7-Graph: Sequential Control Programming Guide

Programming guide for Siemens S7-Graph in TIA Portal covering sequencer design, transition conditions, supervision, and integration with standard PLC code.

Published on February 24, 2026

Siemens S7-Graph

Siemens S7‑Graph (often shown as GRAPH in TIA Portal) is the Siemens implementation of the Sequential Function Chart (SFC) programming paradigm defined by IEC 61131‑3. It provides a graphical environment to design deterministic sequential control sequences by dividing processes into steps, transitions, branches, jumps, interlocks and supervision functions. This guide explains core concepts, concrete implementation steps in TIA Portal, compatibility notes, industry best practices and troubleshooting tips for production use. It is intended for automation engineers deploying sequential logic on S7‑300, S7‑400 and S7‑1500 CPUs (S7‑1200 does not support GRAPH) and integrates facts and procedures from Siemens documentation and field references.

Key Concepts

Understanding the S7‑Graph model and its runtime mapping into Function Blocks (FBs) and Data Blocks (DBs) is essential for robust sequences. The following subsections break down the elements you will use daily when building GRAPH programs.

Overview of the GRAPH/SFC Model

S7‑Graph implements the SFC concept: a sequence consists of steps that contain actions and are connected by transitions which evaluate Boolean conditions. Steps can be active or inactive, and only active steps execute their associated actions. The language supports branching (conditional and simultaneous), jumps, endpoints and event-driven behaviour. According to the TIA Portal GRAPH manual, GRAPH provides specialized qualifiers for actions (N, S, R, etc.), supervision modes, and extensions for internal arrays and parameters (the io‑G7Arrays extension) that help map the graphical sequence to PLC memory and I/O structures (see Siemens TIA Portal GRAPH manual).

Steps, Actions and Qualifiers

Each step contains one or more actions. Actions perform operations such as setting/resetting outputs, assigning variables, starting timers or incrementing counters. Actions use qualifiers to determine how they behave when a step is active:

  • N (Non‑stored): Executes while the step is active; values are not stored persistently across scan cycles.
  • S (Set) and R (Reset): Set and reset operations for persistent outputs or memory bits.
  • Timed actions and counters: Use standard timer/counter primitives as actions; GRAPH provides qualifiers and drag‑and‑drop access to timers and counters from the toolbox.

Use qualifiers consistently to avoid race conditions; for example, use S/R for latched outputs and N for momentary control signals that require continuous evaluation.

Transitions and Conditions

Transitions evaluate Boolean expressions (contacts, tags, comparators). A transition becomes true when its condition evaluates to logical 1 and the logical neighborhood rules allow the step change. Transitions can be single‑condition or compound (AND/OR), and GRAPH supports explicit NO (normally open) style representations as used in ladder logic. In TIA Portal you write transition logic with the same tag names and functions used in LAD/FBD/STL, enabling reuse of existing boolean expressions and function calls.

Branches, Jumps and Endpoints

GRAPH supports both conditional branches (choose one of multiple paths based on transition conditions) and simultaneous branches (parallel sequences). It also supports jumps — direct transfers to a step number — which in modern TIA Portal versions can be implemented by specifying the target step number (e.g., jump to step 3). This is an improvement over older Step7 behavior where jumps required disabling and enabling of steps. Endpoints mark sequence termination and are used for graceful stops or to trigger new sequences.

Supervision, Interlocks and Events

Supervision provides runtime monitoring for timeouts and fault conditions. GRAPH includes supervision modes (V‑mode and others) and parameters such as RESET_CRIT (introduced in V5.0) to handle fault resets and critical error handling (H_IL_ERR, H_SV_FLT). Interlocks (represented as -(C) interlock blocks) are preconditions that prevent sequence activation if safety or process conditions are not met. Events can be used to trigger jumps, forced resets or to integrate with operator HMI actions.

Block Architecture and Data Mapping

To execute a GRAPH program in S7 controllers you must use a specific block architecture: typically a FB block contains the GRAPH network, an instance DB (the FB's DB) stores the sequencer state and internal variables, and an OB/FC calls the FB (for example from OB1). GRAPH also supports extension blocks to expose internal arrays and parameters through "io‑G7Arrays" (Array[*] of USInt), which is useful when you need to access internal state or diagnostics from outside the FB. Always create an instance DB for each FB; reusing the same FB without distinct instance DBs will lead to shared state and incorrect behavior.

Compatibility, Versions and Standards

S7‑Graph aligns with the SFC specification in IEC 61131‑3 and with Siemens product compatibility matrices. Key compatibility facts:

  • Supported CPUs: S7‑300, S7‑400 and S7‑1500 families (examples: CPU 1511‑1 PN, 1512). S7‑1200 does not support GRAPH in TIA Portal.
  • TIA Portal versions: GRAPH is available in TIA Portal V15 and later for S7‑300/400/1500. TIA Portal documentation up to V20 includes updated guidance and new features for GRAPH on S7‑1500.
  • FB versions: S7‑Graph FB libraries use versioning (e.g., Graph V5.3 for S7‑300/400). Ensure FB and extension block versions match the target CPU and TIA Portal version when migrating projects.
  • Standard compliance: GRAPH implements the SFC model per IEC 61131‑3, which simplifies documentation, testing and certification of sequential logic compared to ad‑hoc ladder structures.

As documented in Siemens programming guidelines and the TIA Portal GRAPH manual, always validate FB/DB versions after migrating projects from Classic Step7 to TIA Portal to avoid runtime incompatibilities.

Implementation Guide

This section provides a practical step‑by‑step workflow for implementing a GRAPH sequence in TIA Portal from project setup to deployment and validation.

1. Project Setup and CPU Selection

Create a new TIA Portal project and choose a compatible CPU (for example CPU 1511‑1 PN or 1512 for S7‑1500). According to Siemens documentation, GRAPH is not available for S7‑1200, so select S7‑1500 or S7‑300/400 where appropriate. Configure hardware and network settings before adding GRAPH blocks to avoid rework.

2. Create the GRAPH FB and Instance DB

Add a new Function Block (FB) and select the GRAPH language editor for its main network. When you save the FB, TIA Portal will prompt you to create an instance Data Block (DB) automatically; this DB stores the step bits, timers and counters for that sequence. Use one instance DB per independent sequence or per machine instance to ensure independent runtime state, especially in multi‑machine architectures.

3. Define Steps, Actions and Transitions

Use the sequence view to place steps and transitions. Enter action code inside steps using qualifiers (N, S, R) as needed. Write transition conditions using tags and boolean logic; where complex boolean logic exists, consider implementing the condition as a separate FC/FB and calling it from the transition to keep the GRAPH visually clear.

  • Prefer explicit naming conventions for steps (e.g., STEP_StartPump, STEP_FillTank).
  • Use comments for transition conditions that reference sensors or operator interlocks.
  • Use the io‑G7Arrays extension if you need external access to step state or counters for diagnostics.

4. Implement Supervision and Interlocks

Configure supervision timers for steps that must complete within time bounds. Use the supervision V mode and RESET_CRIT parameter to define how the sequence behaves on faults and how it can be reset (Siemens GRAPH manual). Add interlocks as -(C) blocks so the sequence cannot start unless safety and process preconditions are satisfied.

5. Integrate with Standard PLC Code (LAD/FBD/STL)

Drag and drop FC/FB calls, tags or networks into GRAPH actions or, conversely, call the GRAPH FB from standard OB1 or other FCs. Use consistent tag structures between GRAPH and the rest of the program so that HMI variables, diagnostics and alarms can be shared. GRAPH actions can reference FCs for complex arithmetic or control algorithms, enabling modularization.

6. Call the GRAPH FB from OB1

Call the GRAPH FB from OB1 (or the appropriate cyclic OB) with its instance DB. If you need multiple independent sequences, call multiple instances of the same FB with distinct DBs. For event driven sequences you may call the FB inside conditional OB logic or via dedicated Trigger FC/OB patterns.

7. Simulation, Testing and Validation

Use the online test tools in TIA Portal to step through the sequence, force inputs and monitor step activation bits in the instance DB. Validate timing behaviour by observing supervision timers and ensure reset procedures behave as intended. For safety‑critical sequences, document the step/transition table, expected timing, and failure modes in the project documentation as required by IEC 61131‑3 compliance and internal QA procedures.

8. Migration from Step7 Classic

If migrating legacy Step7 GRAPH projects, use the TIA Portal migration tools and review FB/DB versions carefully. Some constructs may require rework (e.g., jumps and extension blocks). Test migrated sequences thoroughly as memory mapping and FB semantics may have changed between Step7 Classic and TIA Portal implementations.

Best Practices

These recommendations reflect field experience and Siemens guidance to produce maintainable, safe and high‑performance GRAPH sequences.

  • Use one FB instance per machine unit: Avoid shared instance DBs for independent machines to prevent unintended state sharing.
  • Keep transitions simple: When transition logic becomes large, encapsulate it in a function call and reference the result in the transition for improved readability.
  • Name everything clearly: Step names, transition names and action descriptions should map to physical process steps and sensors/actuators.
  • Prefer S/R for safety‑critical outputs: Use Set/Reset qualifiers for actuators that must remain latched despite transient scan variations.
  • Document supervision timeouts: Record expected step durations and configure supervision timers accordingly; log H_SV_FLT faults for diagnostics.
  • Leverage io‑G7Arrays carefully: Use extension arrays when external systems require read access to internal state, but be mindful of memory and alignment constraints described in the Siemens manual.
  • Keep GRAPH small and modular: Break large sequences into sub‑FBs and call them from a master FB to improve clarity and testability.
  • Use version control and comment changes: Annotate sequence changes and keep archived versions to aid certification and rollback in production plants.

Common Pitfalls and Troubleshooting

Even experienced engineers can encounter common issues when working with S7‑Graph. Below are recurring pitfalls and corrective actions.

  • Missing Instance DBs: If multiple sequences share an instance DB unexpectedly, create distinct instance DBs for each FB instance to avoid state corruption.
  • Incompatible FB versions after migration: Ensure you update FB/extension block versions to the target runtime. Verify that Graph V5.3 or the appropriate version is used for S7‑300/400 projects.
  • Unexpected jumps or step behavior: Check for unintended jumps and ensure numbered jumps reference existing step IDs. In TIA Portal you can jump directly to step numbers; ensure maintenance staff understand the difference from legacy Step7.
  • Supervision faults: If H_SV_FLT or H_IL_ERR occur, review RESET_CRIT settings and ensure supervision timers match process reality.
  • S7‑1200 confusion: Attempting to use GRAPH on S7‑1200 will fail silently in some toolsets; confirm CPU selection before creating GRAPH blocks.

Specification Comparison

The following table summarizes common CPU and TIA Portal compatibility points for GRAPH use. Use this as a quick reference when planning hardware and software versions.

Item Supported Notes
S7‑1500 (e.g., 1511‑1 PN, 1512) Yes Fully supported in TIA Portal V15+; recommended for new projects.
S7‑300 / S7‑400 Yes Supported via GRAPH FB versions (e.g., V5.3). Migrate with care from Step7 Classic.
S7‑1200 No GRAPH is not supported on S7‑1200; use state machines in Structured Control or Ladder instead.
TIA Portal Version V15 – V20+ Enhanced GRAPH editor features and updated FBs available in V15 and later; consult TIA Portal V20 docs for latest changes.
IEC 61131‑3 SFC Compliance Yes GRAPH implements SFC constructs consistent with IEC 61131‑3.

Integration with HMI and Diagnostics

Design your HMI screens to expose active step names, transition status and supervision timers. Map step activation bits from the instance DB to HMI tags for visual diagnostics. Log H_SV_FLT and H_IL_ERR faults with timestamps to facilitate root cause analysis. Use clearly labeled operator controls for manual overrides and sequence resets; implement access control for critical reset functions to comply with safety policies.

Summary

S7‑Graph provides a graphical, standards‑

Related Platforms

Related Services

Frequently Asked Questions

Need Engineering Support?

Our team is ready to help with your automation and engineering challenges.

sales@patrion.net