S7-GRAPH Steps Advance Without True Transition: Root Causes and Field-Proven Fixes

A sequencer step in S7-GRAPH exits even though the transition condition has not become TRUE. The classic symptom: step S49 is configured to advance to the next step only when bit M994.0 is TRUE. With M994.0 = FALSE, the step should remain active indefinitely. In practice the step exits anyway, sometimes within a single PLC scan, sometimes intermittently, regardless of what boolean condition is wired into transition T58. This guide walks through the S7-GRAPH execution model, the four root causes that account for the vast majority of these cases, and a diagnostic procedure that closes them out in the order Siemens support engineers typically apply them.

1. Problem Description

The user-visible symptom is a step that exits in violation of the documented transition rule. The rule is simple: a step is active, the FB evaluates the transition logic; if the transition evaluates to TRUE, the step is deactivated and the next step in the chain becomes active on the following scan. If the transition evaluates to FALSE, the step remains active.

Three observable behaviors typically accompany the fault:

• The step briefly becomes active (the X49 flag is set in the instance DB) and clears within one OB1 scan.
• Whatever condition is typed into the transition - M0.0, M994.0, even a constant that should never be TRUE such as 0 - appears to be ignored. Replacing the condition with another bit does not change the behavior.
• The sequencer was not written from scratch. It was copied, modified, or stitched together from an existing program, and the engineer has already concluded the process logic itself is not the issue.

These three signals together point away from a logic error in the process and toward a sequencer edit/compile artifact, an action that bypasses the natural transition, or an external force on the transition condition.

2. S7-GRAPH Execution Model: Steps, Transitions, and Actions

S7-GRAPH compiles a sequencer into a Function Block (FB). The rest of the PLC program calls the FB, and the FB owns a static instance Data Block (DB) that holds the active step number, timers, counters, and the per-step flags Xnn. The FB is processed inside the same OB1 (or OB for cyclic execution) that runs the rest of the program, so the S7-GRAPH FB and any FBD/STL code that touches the same M-bits or step flags see each other within one scan.

Each step has four editable regions in the FBD/LAD editor:

Each transition is a single Boolean expression. S7-GRAPH supports three transition structures:

• Standard transition - one or more contacts in series/parallel that evaluate to a single boolean.
• Alternative branch (OR) - if any branch in the branch set becomes TRUE, the step advances.
• Simultaneous branch (AND) - all branches must be TRUE to advance.

The execution rule is unambiguous: a step exits only when (a) the step is active, (b) the transition logic evaluates to TRUE, and (c) the sequencer's enable/initialization inputs (INIT_SQ, OFF_SQ, ACK_EF, SW_AUTO/SW_TAP/SW_MAN) are in the state expected by the program. If a step exits when the transition reads FALSE in your watch table, one of these three conditions is being met by something other than the explicit transition logic.

2.1 S7-GRAPH Block Interface Parameters

The compiled FB exposes a standard set of inputs and outputs that the calling program can read or write. Knowing which parameter is which is essential to diagnosing the issue.

For an in-depth description of how these parameters interact during step execution and transition monitoring, see Siemens KB 1668619 - What tips and tricks are available in S7-GRAPH for executing and monitoring steps and transitions?

3. Root Cause Analysis: Why a Step Exits When Its Transition is FALSE

Four root causes account for the vast majority of "step exits with no transition" cases. They are listed in the order Siemens support engineers usually check them.

3.1 Dangling or Default-TRUE Transition Logic From Copy/Paste

When a sequencer is copied and then reworked, the underlying STL/FBD source of the FB can carry an orphaned branch, a default-TRUE rung, or a comparator that always evaluates to TRUE. The visible T58 condition in the S7-GRAPH editor shows M0.0 or M994.0, but the compiled FB still contains a parallel path that evaluates to TRUE before the user-written condition is even consulted.

Common artifacts that survive an edit:

• A comparator such as ==I 0 against a default-zero tag (TRUE at start-up, FALSE later - so the symptom appears only briefly).
• An unused OR-branch that survived a delete operation. The FBD view collapses OR branches into a single wire; the STL view reveals the extra rung.
• A status-bit contact such as X49 wired into the same transition as M994.0. X49 is TRUE while S49 is active, so the OR is always TRUE while the step is active and the step exits on the first scan.
• An empty transition left from a paste operation. In some S7-GRAPH versions, an empty transition is treated as default-closed; in others, default-open. Behavior depends on the S7-GRAPH version that generated the FB and the version that re-imported it.

To check, open the FB in STL view. In TIA Portal, right-click the sequencer body and select Switch to STL. Read the compiled code under the transition label. The transition block should contain one rung whose only contact is the transition operand.

3.2 External Forces on the Transition Condition

If M994.0 is being written anywhere else - by the HMI, by another step's actions in a different sequencer, by an FB call, by an OB100/OB101 startup routine, or by an active force table - the condition can become TRUE at the same scan the S7-GRAPH FB reads it. The classic symptom is "the transition looks FALSE in my watch table" but the step still exits. The watch table may not include the OB1 pre-image that the FB uses.

To rule this out, open the cross-reference for M994.0. In STEP 7 classic, use Options > Reference Data > Display and filter to M994.0. In TIA Portal, navigate to Project tree > PLC > Cross-reference and filter to M994.0. If the list shows any write besides the comment "used in T58," that is your root cause.

Also check the active force table. In TIA Portal, open Online > Force table and confirm no force is active on M994.0 or any Xnn flag. Forces survive recompile and download and are a frequent cause of "it worked in the office and not on the machine."

3.3 Actions Inside the Step or Its Predecessor Force a Different Step Active

S7-GRAPH allows you to put S, R, and CALL actions in a step. The most subtle is the S/R action against a different step in the same sequencer, or a step in a different sequencer in the same FB. When the FB executes a "set step Sx" action, it overrides the natural transition and makes Sx the active step on the very next scan. Likewise, a "reset step S49" action would clear the current step before the transition is even evaluated.

In the symptom case, S49's actions or its predecessor's actions may be writing to a step in the same sequencer. The most common mistake when copying sequencers is leaving an action such as RC S50 (reset step 50) or SC S49 (set step 49) that was originally meant for a different branch.

3.4 JUMP Action Bypassing the Transition

S7-GRAPH supports JUMP-to-step actions (JC, JP, JR). A JUMP is essentially a forced transition: it does not consult the transition condition. If a JUMP action was left in the step's actions during editing, the step will exit regardless of the boolean logic in T58.

To check this, expand every action in the step and look for JP, JC, or JR symbols. A JUMP that targets the next step is redundant with the natural transition but still forces the exit; a JUMP that targets a different step overrides the entire sequencer logic.

3.5 Troubleshooting Matrix

4. Step-by-Step Diagnostic Procedure

Work the procedure in order. The first three checks resolve more than 90 percent of "step exits with no transition" tickets.

1. Open the S7-GRAPH FB in STL view. Right-click the sequencer body in TIA Portal and switch from FBD to STL. Read the compiled code under T58. Confirm the only rung is the expected M0.0 or M994.0 reference. Look for any Xnn contact that auto-evaluates TRUE while the step is active, any unused OR branch, and any constant-TRUE rung.
2. Run a cross-reference on the transition operand. In STEP 7 classic, use Options > Reference Data > Display. In TIA Portal, open the cross-reference tool. Any write access to M994.0 outside the S7-GRAPH FB is suspect - including writes from HMI tags, OB100/OB101, and other FBs.
3. Inspect the step's actions and permanent instructions. In the FBD view, expand every action block. Note any S or R that targets a step in the same sequencer, any JUMP action, and any CALL that runs a different FB.
4. Inspect the predecessor step's actions. A predecessor can clear the current step with an R action or set a different step as active with an S action. Walk the chain back at least one step.
5. Disable all force tables. In TIA Portal, open Online > Force table and confirm no force is active on M994.0 or any Xnn flag. Stop and clear the force table before continuing.
6. Recompile the S7-GRAPH FB and re-download to the PLC. If the on-line FB and the offline FB are out of sync, the on-line program may be running an older version that still has the bad transition. This is a frequent cause of "I fixed it in the editor but the PLC still does the wrong thing."
7. Run a single-scan test with the simulator or PLCSIM. Force M994.0 to FALSE, then advance one OB1 cycle and observe whether S49 exits. If it exits under controlled conditions, one of the four root causes above is confirmed.
8. Inspect the instance DB. If the FB has been recompiled with a new interface and the instance DB was not regenerated, the FB may read a stale step number from the DB. Symptoms include steps that "skip" or behave erratically. Always regenerate the instance DB after recompiling an S7-GRAPH FB.

4.1 Step and Transition Flow Visualization

The diagram shows the legitimate flow S49 → T58 → next step, plus two rogue paths that can force the step to exit regardless of the transition logic. Rogue path 1 is an in-step action (JUMP, S, R). Rogue path 2 is an external write to the transition operand (HMI, OB100, force table). Both bypass the natural transition logic.

5. Fix Procedure

Once the root cause is identified, the fix falls into one of four patterns.

5.1 Fix a Dangling Transition

1. Open the S7-GRAPH FB in STL view.
2. Delete the redundant rung that evaluates to a constant TRUE, an Xnn flag, or a tag that is always TRUE.
3. Confirm the only remaining path is the M0.0 / M994.0 contact.
4. Recompile, regenerate the instance DB, and full-download.

5.2 Remove an External Force on the Condition

1. Open the cross-reference and identify the writer.
2. If the writer is an HMI tag, remove the HMI write or add a confirmation bit that the HMI must set explicitly.
3. If the writer is another step's action, modify that action to set the bit only when the process actually demands it.
4. Recompile and re-download the entire PLC program if the writer is in a different FB.

5.3 Remove an Inappropriate S/R/CALL Action

1. Open the step's actions in the FBD view.
2. Delete any S/R that targets a different step in the same sequencer unless the process truly requires a forced step change.
3. Replace CALL actions that indirectly modify sequencer flags with the intended function block call, but ensure the called FB does not write to the same M-bit or step flag.
4. Recompile, regenerate the instance DB, and full-download.

5.4 Remove a JUMP Action

1. Open the step's actions.
2. Locate the JC / JP / JR block.
3. Decide whether the JUMP is needed. If not, delete it. If it is needed, the natural transition logic in T58 may be redundant - in which case the cleanest fix is to keep the JUMP and remove the T58 condition, or keep T58 and remove the JUMP, depending on which path the process demands.
4. Recompile, regenerate the instance DB, and full-download.

6. Online Verification and Cross-Reference

After the fix, run the following verification sequence before going back to production.

1. Recompile the S7-GRAPH project. In TIA Portal, right-click the PLC and choose Compile > Software (rebuild all). In STEP 7 classic, choose Program > Compile (rebuild all blocks).
2. Download the project to the PLC. Always full-download when changing FB instances.
3. Open a watch table with the following tags: M994.0, the active step flag (S_ACTIVE), the current step number (S_NO), the predecessor's X-flag (X48 or whatever the predecessor is), the successor's X-flag (X50 or whatever the successor is), the transition number that just fired (T_NO), and the IL_ERR / SF_ERR bits if interlocks and supervisions are used.
4. Force M994.0 to FALSE in the watch table, then toggle INIT_SQ to start the sequencer. The step should remain active and S_TIME should increment scan by scan.
5. Set M994.0 to TRUE and confirm the step advances exactly once and the next step becomes active. S_NO should change once. S_TIME should reset.
6. Reset M994.0 to FALSE and confirm the next step's transition logic does not allow further advancement.
7. Watch T_NO during the transition. If T58 is the transition that fires, T_NO will read 58. If a different transition number appears, the step is being advanced by a transition you did not expect.

If the step exits with M994.0 forced FALSE, return to the diagnostic procedure. The on-line FB may still be the pre-fix version - confirm the FB timestamp in the on-line block list matches the latest compile.

7. Edge Cases and Common Pitfalls

7.1 Multiple Sequencers in the Same Step

S7-GRAPH allows multiple sequencers to run in parallel inside one FB. Each sequencer has its own active step. If the step number in the symptom message (S49) belongs to sequencer 2 but the transition (T58) belongs to sequencer 1, the cross-reference can be misleading. Use the SQ_ID or SEQ qualifier in the S7-GRAPH block interface to disambiguate. For guidance on this, see Siemens KB 1668619 which documents the execution and monitoring behavior of multiple sequencers in the same FB.

7.2 Initial Step Behavior

The initial step (the one with the double outline) becomes active the first time the sequencer is initialized. If you look at S49 right after a power-on and see it as active then immediately inactive, you may be observing a different step becoming active via an alternative branch. Add the SQ_FLAGS or sequencer state output to the watch table to identify the active sequencer.

7.3 Step Actions With Time-Delayed (D) Qualifier

The D (delayed) action is independent of the step transition. A D action can fire once its delay timer expires even if the step is no longer active, depending on the action qualifier flag. Review every D action in the step to confirm none of them sets a flag that the next step interprets as a transition condition.

7.4 OB100 Startup Behavior

An OB100 (warm restart) or OB101 (hot restart) routine can write to M994.0 or to step flags during startup. If the step exits at power-on, the OB100 is suspect. Comment out all writes in the OB100 and re-test. Also confirm that the OB100 is not initializing any Xnn flags that the sequencer reads as a transition condition.

7.5 Instance DB Mismatch

If the FB has been recompiled with a new interface and the instance DB was not regenerated, the FB may read a stale step number from the DB. Symptoms include steps that "skip" or behave erratically. Always regenerate the instance DB after recompiling an S7-GRAPH FB. In TIA Portal, right-click the FB and choose Compile > Software (rebuild all); in STEP 7 classic, choose Program > Compile (rebuild all blocks) and confirm the instance DB is updated.

7.6 Symbol Table Inconsistency

If the symbol table has a different operand for M994.0 in the offline and on-line views (for example, because a recent edit renamed the symbol but the on-line PLC is still using the old symbol table), the watch table may show the new symbol while the FB reads the old address. Synchronize the symbol table and the FB before diagnosing further.

8. Best Practices When Editing Sequencers

• Always view new sequencers in STL first. The FBD view hides constant-TRUE rungs and OR-branch artifacts. A 30-second STL scan saves hours of debugging.
• Maintain a single source for transitions. Never let an HMI or another FB write to a transition operand; route all conditions through named step flags or named process bits. This also makes the cross-reference meaningful.
• Prefer natural transitions over JUMP actions. JUMP is a code smell in S7-GRAPH; if you need a forced transition, document why in the step comment.
• After every edit, recompile and re-download the entire S7-GRAPH FB and its instance DB. Partial downloads can leave the on-line program in an inconsistent state and the diagnostic process will point at the wrong place.
• Keep the S7-GRAPH version consistent across the engineering team. Programs generated by a newer S7-GRAPH version and then re-opened in an older version lose certain qualifiers. The Siemens KB article 1668619 documents version-specific behavior in the execution and monitoring of steps.
• Use the S7-GRAPH debugger's Status view to step through transitions one cycle at a time. This is the fastest way to confirm whether a transition is evaluating TRUE or FALSE on a given scan.
• Document every JUMP, S, and R action in the step comment. Future engineers (including yourself in six months) will not have to guess why the step exits.

9. Frequently Asked Questions