Siemens GRAPH N-Action Bit Stuck TRUE After Step Exit S7-1500

1. Problem Description

On a Siemens SIMATIC S7-1500 CPU 1515-2 PN controlling a hydraulic press, a sequential function chart (SFC) authored in S7-GRAPH and called from OB35 at 10 ms runs a 99-step transfer-reference initialization routine. Each step uses an "N" (non-stored) action to write a step-correlated marker (S1..S99) into a global DB. After several production shifts, the maintenance engineer finds the sequencer parked at step 1 (a side effect of an E-stop reset driven by a PILZ safety controller), but the global DB still shows S99 := TRUE in addition to the expected S1 := TRUE. The orphan S99 blocks the next automatic start because it acts as a latched process guard. The bit is only cleared when the operator manually resets it through a watch table.

The symptom is not a GRAPH defect. It is the standard semantics of the N action combined with the absence of any companion R action. This article documents the action-qualifier model, the diagnostic procedure, the corrective patterns, and a preventive design rule that eliminates the entire class of "stuck step marker" issues.

2. GRAPH Action Qualifier Semantics

S7-GRAPH distinguishes between step actions (evaluated only while the step is active) and permanent instructions (evaluated every OB cycle regardless of step state). For boolean outputs the relevant qualifiers are:

The N qualifier is a level-driven "assign while active" instruction. As long as the step is active, the GRAPH runtime writes the operand TRUE each OB35 cycle. The moment the step transitions to inactive, the runtime stops writing. The target operand keeps whatever value it last received. In the failing case, the target was last written TRUE, so it remains TRUE.

3. Root Cause Analysis

For the failing press, the chain of events is deterministic:

1. Step 99 is active; its N action writes "DB_Sequence".S99 := TRUE every OB35 cycle (10 ms).
2. An emergency stop fires. The PILZ safety controller drops the run-permit output wired to the S7-1500.
3. The sequencer logic interprets the lost run-permit as a step-exit condition. The higher-level initialization routine forces the sequencer into step 1.
4. Step 1's N action writes S1 := TRUE. Step 99 is now inactive, so the GRAPH runtime no longer writes the S99 operand.
5. S99 retains the value from its last write (TRUE). No other code resets it.
6. On the next start attempt, the interlock guarding the initialization sees S99 = TRUE and blocks the start.
7. The operator is forced to manually clear the bit, which masks the real defect for several shifts before it is reported.

This is by design. The "issue" is the missing reset path, not the GRAPH engine. Three amplifiers must be ruled out before applying the fix:

• Multiple writers: Some other FB, HMI tag list, or peripheral access may set the same DBX bit, masking the GRAPH write.
• Overlapping access: A MOVE that targets a full byte, word, or dword covering the S99 offset will silently overwrite the GRAPH write with a different pattern.
• CPU firmware defect: Historical CPU/GRAPH combinations (notably older S7-300 firmware with GRAPH V5.x) had edge-case bugs where N-action signals were latched into instance-DB scratch space. The S7-1500 family resolved these from firmware V1.6 onward; current V2.9.x maintenance releases do not exhibit the problem. The CPU firmware version in the failing machine is not stated, so confirm it before drawing any conclusion.

4. State Machine View of the Latch

The following inline diagram illustrates the data flow. Step 99 activates, the N action writes S99 = TRUE, the E-stop forces an unconditional jump to step 1, and the S99 line remains latched because no writer drops it.

5. Diagnostic Procedure

Use the following sequence to confirm the analysis and rule out the three amplifier conditions.

5.1 Read the GRAPH instance DB online

1. In TIA Portal open the GRAPH FB and connect online to the CPU.
2. Open Watch & Force Tables > Monitor/Modify and drag the GRAPH instance DB into the table.
3. Filter on the step-state area. The relevant offsets in the instance DB are Internal.Step[X].Active (BOOL), where X is the step number. Active must be TRUE only for the currently active step; all others must be FALSE. This proves the GRAPH runtime correctly deactivates the steps.
4. Cross-check Internal.Step[X].Interlock and Internal.Step[X].Supervision to ensure the step exited cleanly and was not held in an error state.

5.2 Cross-check the global DB

1. Open the global DB and look at the same bit offsets written by N actions.
2. Trigger a step exit (transition the sequencer) and observe the bit. It will hold its last value - that is the expected N-action behavior.
3. If a partner R action is missing, the bit stays latched. The watch table is the fastest way to demonstrate this to colleagues who do not yet trust the analysis.

5.3 Search for redundant writers

1. Use Cross-references on the S99 tag. TIA Portal reports every read, write, and IN/OUT assignment across the project.
2. Inspect each reference. If any other FB, HMI tag list, or peripheral access writes the same bit, you have a multiple-writer condition.
3. Verify that no other block writes the same DBX byte. A MOVE_BLK or MOVE that targets a full byte/word/dword covering the S99 offset will silently overwrite the GRAPH write. The fix here is to isolate the marker in its own byte or to use an unshared DB.

5.4 Verify firmware and software versions

1. Read the CPU's firmware version via Online & Diagnostics > Diagnostics > Module Information.
2. Confirm the TIA Portal project version against the GRAPH package in Options > Software Packages. Refer to the SIMATIC S7-1500 CPU 1515-2 PN operating instructions and the S7-GRAPH for S7-1500 programming and operating manual for the qualifier semantics applicable to your version.
3. Cross-check the Siemens compatibility tool for the CPU article number (6ES7515-2AM02-0AB0) and the installed firmware.

6. Corrective Solutions

Choose the pattern that matches your process semantics. Three robust options are listed in order of preference.

6.1 Companion R action in a dedicated cleanup step

Add a "step 0" before step 1, and an "end" step after step 99. In the end step, place R actions for every bit the sequence drives. The end step is entered when the sequence finishes and is held there. If an E-stop forces a re-initialization that bypasses the end step, the next start must first re-enter it. To make the cleanup unconditional, attach it to a permanent instruction in step 1 (see 6.2).

// Step "S_End" action block (GRAPH editor)
R "DB_Sequence".S1;
R "DB_Sequence".S2;
R "DB_Sequence".S3;
// ... through ...
R "DB_Sequence".S99;
R "DB_Sequence".RunComplete;

6.2 Permanent instruction as a one-shot reset

Permanent instructions are evaluated every OB35 cycle regardless of step state. Place a permanent instruction inside the GRAPH FB that clears all S-bits when the sequencer is parked in step 1:

// Permanent instruction P0 in the GRAPH FB (SCL body)
IF "iDB_G".Internal.Step[1].Active THEN
    "DB_Sequence".S2  := FALSE;
    "DB_Sequence".S3  := FALSE;
    "DB_Sequence".S4  := FALSE;
    // ... through ...
    "DB_Sequence".S99 := FALSE;
END_IF;

The permanent instruction fires every OB35 cycle. While the sequencer is parked in step 1, all other S-bits are forcibly cleared. The single-cycle latency is well within the 10 ms OB35 period.

6.3 Replace N with S/R pairs

If the intent of the original N action is "latch when the step runs, unlatch at the end", change it to a pair:

This pattern is preferable to the N action when the marker has process meaning outside the step. With S/R the engineer is forced to think about reset ownership, which is exactly what was missing in the failing press.

7. GRAPH Instance DB Layout and Debugger Use

Each GRAPH FB has a dedicated instance DB whose layout follows the GRAPH source. The areas of interest for diagnosis are:

Use the GRAPH debugger in TIA Portal: Project tree > GRAPH FB > right-click > Start GRAPH Debugger (available from TIA Portal V15.1 with the S7-GRAPH V15.1 package for S7-1500). The debugger overlays the current step state, the active transition, the interlock and supervision flags, and the queued events. When the failing machine is replicated in the debugger, the operator can step through the sequence in MANUAL or JOG mode and observe the bit latching in real time.

8. OB35 Cycle Timing Analysis

The press uses OB35 at 10 ms with an average measured runtime of 8 ms. The remaining 2 ms is the headroom for transient load. A formal analysis:

t_OB35_total = t_OB_overhead + sum(t_logic_blocks) + sum(t_actions)

Given:
  t_OB_overhead     = 1.0 ms (system + GRAPH framework)
  t_logic_blocks    = 6.5 ms (per measurement)
  N_steps           = 99
  N_actions_per_step= 2
  t_N_action_write  = 350 ns (CPU 1515 typical, depends on operand type)

t_OB35_max = 1.0 + 6.5 + (99 * 2 * 350e-6)
           = 7.5 + 0.069
           = 7.57 ms  (within 10 ms budget)

The N-action write contribution is ~70 microseconds - negligible. OB35 timing is not the cause of the S99 latch, but a marginal cycle time will mask other GRAPH defects. Always verify with Online & Diagnostics > Cycle / Clock Memory. The current OB35 time must stay under 9 ms consistently; if it ever exceeds 10 ms, the OB will be skipped and the GRAPH engine will skip a full cycle, which can produce intermittent step-transition bugs that look similar to a stuck bit.

9. Firmware and TIA Portal Version Caveats

Historical notes for CPU 1515-2 PN (article number 6ES7515-2AM02-0AB0) drawn from the Siemens support database:

• Firmware V1.5 (released 2013): initial release. Several GRAPH edge-case defects addressed in V1.6.
• Firmware V1.6 (released 2014): corrected N-action behavior when combined with permanent instructions.
• Firmware V1.8 (released 2015): corrected instance-DB offset reporting bug that confused watch tables.
• Firmware V2.0 and later (2016+): stable GRAPH behavior; recommended minimum for new deployments.
• Firmware V2.9.x (current): includes additional diagnostic functions and security updates.
• TIA Portal V14 SP1 with GRAPH V14 SP1: corrected instance-DB offset reporting.
• TIA Portal V15.1 / V16 with GRAPH: added the integrated GRAPH debugger for S7-1500; prior versions required the standalone S7-GRAPH tool.

The machine in the report uses an unspecified firmware. The decision path is: (1) read the actual firmware from the CPU's Module Information; (2) if it is below V2.0, schedule a firmware update as part of the corrective work; (3) if it is at V2.0 or higher, the firmware is not the root cause and the fix is the reset-action pattern from Section 6. Refer to the S7-1500 CPU 1515-2 PN operating instructions and the S7-GRAPH for S7-1500 function manual for the canonical action qualifier definitions.

10. Verification and Commissioning Tests

After applying the chosen corrective pattern, run the following sequence on the press:

1. Compile and download the GRAPH FB. Confirm no compile errors and that the instance DB initializes.
2. Place the controller in MANUAL mode. Run the sequence step by step from the GRAPH debugger.
3. Confirm each step's N action writes its bit and that the bit drops at step exit (if the corrected pattern uses R, the bit must drop to FALSE within one OB35 cycle of the step exit).
4. Force step 99 active, then trigger an E-stop. Verify the sequencer returns to step 1 with all other S-bits FALSE.
5. Switch back to AUTO and start the cycle. The interlock guarding the initialization must accept the start without manual bit resets.
6. Repeat the E-stop at every 10th step (1, 10, 20, 30, 40, 50, 60, 70, 80, 90, 99). The bit state after re-init must be clean each time.
7. Run 50 consecutive automatic cycles to ensure no edge case re-introduces the latch.
8. Capture a GRAPH trace of one AUTO cycle and archive it in the project for future reference.
9. Document the firmware, TIA Portal version, GRAPH package version, and the corrective pattern chosen in the maintenance log for traceability.

11. Preventive Design Rule

Encode the following rule in your programming standard:

Following this rule eliminates the entire class of "stuck step marker" issues. The failing press is a textbook case: the engineer used the S-bits as a process mirror of the active step, but stored them in a global DB without reset ownership and without consumer logic that re-derived them from the instance DB. The same pattern is observed in many S7-300 to S7-1500 retrofits where the original code was written against an older GRAPH version with different defaults.

FAQ