Troubleshooting S7-300 CPU 315-2DP DB Value Not Updating

Problem Overview

A common fault pattern reported on SIMATIC S7-300 systems running software redundancy with two CPU 315-2DP controllers is the apparent non-persistence of a command bit written into a valve's data block. The engineer observes the following symptoms on STEP 7 (SIMATIC Manager) in online mode:

1. A control bit such as DB322.DBX0.0 is set to 1 inside the calling logic block (for example, in FC201 / FC50 / Network 8).
2. When the user opens the destination data block in Monitor/Modify, the bit does not show the value that the program code just wrote.
3. Forcing the value by re-opening the data block in the editor and downloading it to the PLC restores the bit — but only until the next program cycle erases it again.
4. The fault is intermittent: the same logic works correctly for many cycles before the symptom recurs.

The diagnostic trap is that the CPU is behaving correctly; the apparent contradiction between the program view and the data block view is caused by the FB/DB interaction model and by STEP 7's online display behaviour. The objective of this reference is to walk through the root cause analysis, in-cycle diagnostics, and corrective actions for this class of fault.

Affected Hardware and Software Configuration

The configuration described in the field incident is a classic Siemens S7-300 software-redundant topology:

The CPU 6ES7 315-2AG10-0AB0 is a 6ES7315-2AG10-0AB0 variant (firmware V2.x) that supports software redundancy when paired with an identically configured partner. The IM 153-2BA00 modules (note the B-suffix) are the active backplane for the ET 200M stations on PROFIBUS-DP and are required for redundant I/O behaviour. Confirm the firmware release with Siemens Industry Online Support before applying any upgrade.

Software Redundancy Behaviour — Why the Bit Appears "Lost"

Software redundancy on the S7-300 does not mirror the process image bit-for-bit between partners; instead, the standby CPU receives data via the redundancy function blocks (FB101…FB104) that copy selected areas (typically marked DBs and M-bit ranges) from the master. Three consequences are important for this fault:

1. The DB byte/bit being monitored may be overwritten by the redundancy copy in the same OB1 cycle. If the FB2 instance DB for valve 322 is in the partner-replicated area and the standby CPU becomes momentarily master, the value visible in online mode can appear to revert.
2. The FB call sequence matters. If the user's FC50 / Network 8 writes DB322.DBX0.0 := 1 before the redundancy FB copies the DB out to the partner, the value will be sent. If the write happens after, the partner (and therefore the master on next failover) still holds the old value.
3. STEP 7 online display is a sampled view. When you toggle a bit in FC201, the CPU executes the rest of the cycle — including any code that clears the same bit a few milliseconds later — before the STEP 7 PC receives the next status frame. The bit therefore appears to "never change" in the data block view even though it did briefly flip.

The most common of these three causes in field reports is the third: the OPEN_COMMAND (or CLOSE_COMMAND) is set in one network and reset in a later network of the same FB. The reset is so quick that, by the time the user opens the destination DB in online mode, the bit has already been written back to zero. This matches the original incident description exactly:

"the OPEN_COMMAND is reseted in the FB2/NW14 so if you set the command bit it's reseted after a few milliseconds so normally it's impossible to monitor this change in the DB"

Root Cause Analysis

Work the following decision tree before touching the program. Each branch has a verification step that can be executed without modifying code.

Why a Re-Download "Fixes" It

When you open the DB in the offline editor and download it to the PLC, STEP 7 performs an initial value download that writes the entire DB image into the load memory and into the work memory — including the current command bit. Because the program then runs once and the same clearing network fires, the symptom returns within one cycle. This is why the user reports the fix works "for one time only." It is not a fix; it is a side effect of an unconditional DB overwrite.

Diagnostic Procedure (STEP 7 V5.x)

Follow these steps in order. Each step produces a verifiable observation before moving on.

Step 1 — Confirm the Affected DBs

Open a VAT (PLC → Monitor/Modify → VAT) and add the following symbols, watching at the highest refresh rate your PG/PC interface supports:

DB322.DBX0.0    // OPEN command input
DB322.DBX0.1    // CLOSE command input
DB322.DBX2.0    // OPEN output (from FB2)
DB322.DBX2.1    // CLOSE output (from FB2)
DB322.DBW4      // Status word (interlock, fault, position feedback)
M  100.0        // External OPEN trigger you set in FC201
M  100.1        // External CLOSE trigger you set in FC201

Trigger the action from the HMI or by writing M100.0 := 1 via Monitor/Modify. Watch for the sequence:

1. M100.0 goes to 1.
2. DB322.DBX0.0 briefly goes to 1 (write from FC50/FC201).
3. DB322.DBX0.0 immediately returns to 0 (reset inside FB2).
4. DB322.DBX2.0 stays at 0 (output not latched).

If step 3 happens within the same OB1 cycle, the fault is the missing latch, not the database.

Step 2 — Monitor FB2 Internals with Call Environment

The Call Environment tool is the only way to see the static tags of an instance DB without altering the program. Procedure:

1. Open FB2 in the SIMATIC Manager editor.
2. If Debug → Call Environment is greyed out, choose Debug → Operation and switch the CPU to Test Operation. The mode key on the CPU must be in RUN or RUN-P; Test Operation requires an active online connection.
3. Select Debug → Call Environment — the dialog lists every call site of FB2.
4. Tick Open Data Blocks at the bottom of the dialog and enter the instance DB number for the affected valve (for example, 322).
5. Press Monitor On (the glasses icon).
6. Trigger the action again from FC201.

The static tags of FB2 are now visible. Look specifically for:

• OPEN_REQUEST, OPEN_ACTIVE, OPEN_DONE, OPEN_FAULT
• INTERLOCK_OK, PERMISSIVE_OK, EMERGENCY_STOP
• Any timer tags (T_OPEN_TIMEOUT, etc.) that are still running

If any of these conditions is FALSE, the FB2 logic is correctly suppressing the output and the apparent "missing bit" is actually a healthy interlock working as designed.

Step 3 — Capture the Cycle Trace

For intermittent faults, the VAT refresh rate is not sufficient. Use the S7 Trace function (if licensed) or insert a one-shot rising-edge detection that latches the command into a separate marker:

// Latch command for diagnostics
A   DB322.DBX0.0       // OPEN command as seen by FB2
FP  M 200.0            // One-shot on rising edge
S   M 200.1            // Diagnostic latch

Watch M200.1 in the VAT. If it never latches despite the command being driven from FC201, then FB2 is genuinely never seeing a 1 on its command input — the data block view is misleading you.

Common Code Smells in the Valve FB

After running the diagnostics above, you will normally find one of the following patterns. Each is listed with the fix.

Smell A — Set-and-Reset in the Same Cycle

// Network 8 (FC50): request open
A   M 100.0
S   DB322.DBX0.0
// Network 9 (FC50): reset open request
A   DB322.DBX2.0        // if open output already active
R   DB322.DBX0.0

Fix: Replace the unconditional reset with an edge-triggered reset that only fires on the rising edge of the output feedback. Add a watchdog timer (e.g., 5 s) so a stuck output cannot latch the request indefinitely.

Smell B — Interlock Not Documented in the HMI Tag List

The HMI sees DB322.DBX0.0 as the operator command, but the FB uses a different internal tag (for example, DB322.DBX0.4) after applying interlocks. The HMI shows the bit as 0 because the FB copied it back after rejecting it.

Fix: Map the HMI to the post-interlock status tag (typically DB322.DBX2.0) instead of the command tag, and expose the interlock reason as a separate word for diagnostics.

Smell C — Redundancy Copy Overwriting the Bit

When the standby CPU becomes master (or even during normal partner updates), the redundancy FB copies DB322 from the partner buffer. If the partner's DB322 has not yet received the new command — because the master's write to DB322 happened after the redundancy copy block — the partner will overwrite the local copy on the next redundancy tick.

Fix: Move the redundancy copy block (FB101 in the standard Siemens redundancy library) to the very end of OB1 so all user logic executes first. Confirm by inspecting the call order in OB1:

1. OB1 — cycle start
2. FC50 — valve control (writes DB322.DBX0.0)
3. FB101 — redundancy partner update (copies DB322 to partner)
4. FC90 — HMI data preparation
5. OB1 — cycle end

Smell D — Re-Download as a Hack

If operators have been trained to "open the DB and download it," they are working around a logic bug. This must be removed before the system is handed over. The re-download masks a real fault and erodes the audit trail, because the DB timestamp will change without a corresponding source-code change.

Corrective Actions

Apply the corrective actions in the order listed. Each action has a verification step.

Action 1 — Latch the Open/Close Commands

Convert the valve FB to use a proper latching pattern. Reference structure for the instance DB (UDT):

The FB2 logic should follow this flow:

1. Edge-detect CMD_OPEN_REQ and CMD_CLOSE_REQ.
2. Validate IL_OK AND PERM_OK AND NOT EMERGENCY_STOP.
3. Set OUT_OPEN or OUT_CLOSE accordingly.
4. Start a watchdog timer (typical: S_ODT with 5–10 s).
5. Reset the command only when the feedback position matches or the watchdog expires.

Action 2 — Reorder OB1 Call Sequence

Open OB1 in the editor and confirm the call order. The redundancy FBs must be the last user block called in OB1, after all process logic. If your project uses the Siemens-standard SWR_REDUN library, the order is normally:

// OB1 snippet
CALL FC 50       // Process logic (writes DB322)
CALL FC 90       // HMI data preparation
CALL FB 101 , DB100   // Software redundancy partner update
CALL FB 102 , DB101   // Status / diagnostics
BE

Do not place FB101 before FC50; the partner will receive stale data on the first failover.

Action 3 — Enable Process Operation Diagnostics

Switch the CPU from Test Operation back to Process Operation after diagnostics. Test Operation forces outputs and can mask interlock faults in production. The mode is changed via PLC → Operation in SIMATIC Manager, or by turning the mode key on the CPU front panel.

Action 4 — Document the Correct Online Refresh Path

Update the operator HMI screens so the command status reflects OUT_OPEN / OUT_CLOSE, not the raw CMD_*_REQ. Provide a separate diagnostics faceplate showing IL_OK, PERM_OK, EMERGENCY_STOP, and the watchdog timer remaining.

Verification Procedure

After the corrective actions are applied, run the following sequence to verify both the fix and the absence of regression.

1. Place the CPU in RUN-P with the password-protected mode switch.
2. Open the VAT containing the symbols listed in Step 1 above.
3. Force M100.0 := 1 from Monitor/Modify.
4. Confirm within 500 ms that DB322.DBX2.0 (open output) is 1.
5. Confirm within the configured travel time (typically 3–10 s) that DB322.DBX2.0 returns to 0 and STATUS reports POSITION_OPEN = TRUE.
6. Open the FB2 Call Environment with instance DB 322 attached. Confirm OUT_OPEN latched and released cleanly.
7. Force a partner failover by stopping the master CPU. Within the configured redundancy switchover time (typically < 700 ms for software redundancy), confirm the standby takes over and the valve completes its move without operator intervention.
8. Remove all diagnostic latches (M200.x) and re-download the project.
9. Sign the commissioning checklist and archive the VAT trace.

Related Fault Patterns to Rule Out

Before closing the ticket, verify these adjacent failure modes that often present with the same symptom.

Best Practices for Valve FBs on S7-300 Software-Redundant Systems

• Always latch commands in instance DBs, never in M-bits. M-bits are not guaranteed to survive a partner failover on all S7-300 software-redundancy configurations; DBs marked for replication are.
• Use edge-triggered request bits (FP) for the operator command and store the latched request in the instance DB. The HMI reads the latched request and the FB clears it after completion.
• Place the software-redundancy FBs last in OB1 so they copy the final, settled state of all process DBs to the partner.
• Provide a separate STATUS word that exposes the reason a command was not honoured (interlock, permissive, ESD, watchdog). This eliminates the "I clicked Open and nothing happened" support call.
• Never rely on a re-download of the DB to fix a runtime fault. If re-download is required to recover, the program logic is wrong; the operator procedure must not include a download step.
• Document the partner DB replication list in the project README. The Siemens SW_REDUN library marks DBs by calling FB101 with the DB numbers explicitly — verify every valve DB appears in this list.
• Use a separate diagnostics DB (for example, DB900) that records every command-rejected event with a timestamp. The S7-300 CPU clock (read from the diagnostic buffer) is sufficient; for higher resolution, sync the time via SIMATIC Time-of-Day synchronisation on PROFIBUS.

FAQ