S7-300 CPU319-3 PN/DP STOP from SFB20: Diagnostic Buffer Fix

1. Problem Statement and Operational Impact

The SIMATIC S7-300 CPU 319-3 PN/DP (Siemens catalog number 6ES7 318-3EL00-0AB0) periodically transitions into STOP with no operator action on the mode selector. Toggling the keyswitch from RUN to STOP and back to RUN clears the fault, but the next event re-stops the controller. The CPU diagnostic buffer contains the standardized Siemens event:

Stop caused by PG or SFB20

Because no programming device is attached during the fault window, the remaining plausible trigger is the remote CPU-control function block SFB20 (STOP) being executed by a peer CPU over a configured S7 connection, or by an HMI/SCADA that still holds PG-class privileges. The cost of an unplanned STOP on a running machine line is measured in lost batches, scrap, safety interlocks disengaging, and intermediate-circuit trips on drives; the fix therefore has to address both the immediate symptom (the STOP event itself) and the root cause (the stray SFB20 caller or the unprotected STOP port).

2. Affected Hardware and Firmware

Refer to the Siemens Industry Online Support entry for the CPU 319-3 PN/DP manual and to the SIMATIC S7-300/400 System and Standard Functions reference (Volumes 1 and 2) for the SFB20 STOP function block interface.

3. Reading the Diagnostic Buffer Entry

Open Online > Accessible Nodes in STEP 7, select the affected CPU, and launch PLC > Diagnostics/Settings > Module Information. In the Diagnostic Buffer tab, locate the entries with timestamps matching each STOP. Each entry exposes:

• Event ID (hex) - e.g., 16#4921, 16#4923, 16#4925
• Event text - Stop caused by ... text
• Additional Information 1/2 - mode selector position, connection ID, source TSAP
• Operating-mode transition - RUN → STOP reason code

Decoding the Stop caused by PG or SFB20 entry:

Double-click the entry in STEP 7 to view supplementary details; the Additional Information field very often contains the connection ID and source TSAP of the offending SFB20 caller. Capture several days of buffer entries as .txt before any code change so the trend can be compared afterwards.

4. What SFB20 (STOP) Actually Does

SFB20 is a standardized communication function block that issues a remote CPU STOP command to a partner CPU over a configured S7 connection. The block interface (from the System Software for S7-300/400 System and Standard Functions reference) is:

Common STATUS codes returned to the SFB20 caller:

If a peer CPU program calls SFB20 against this CPU with REQ=TRUE, the partner CPU is forced to STOP. The receiving CPU's diagnostic buffer then records the SFB20-initiated STOP event. The same event is produced when an HMI issues a PG-class STOP command, since the CPU cannot distinguish a human-initiated PG stop from an SFB20 stop at the buffer-entry level.

5. Root Cause Analysis Path

The STOP is driven by one of the following root causes. Resolve them in the order shown:

1. Remote SFB20 call against this CPU - A peer CPU executes SFB20 targeting the LADDR of this CPU. Most common in systems with HMIs, supervisory PLCs, or process-control masters that re-use STOP/RESUME logic for redundancy.
2. HMI / SCADA with PG-class STOP - Some TIA/WinCC flexible screens have an enabled Stop PLC button wired through a connection that triggers a PG-style STOP. An HMI without an attached programming cable can still produce a PG-class STOP if it holds PG rights.
3. Misconfigured NetPro connection - An S7 connection set to S7 Communication rather than PUT/GET only allows STOP/RESUME capability; remove the privilege where it is not needed.
4. Missing error OBs - Without OB121/OB122 the CPU enters STOP on programming/I/O errors that surface in the same diagnostic buffer area, making SFB20 STOPs harder to identify.
5. External STOP from PROFIBUS master using SFC12 - Some D_ACT_DP sequences call SFB20 implicitly to deactivate DP slaves, which can be misinterpreted as a CPU STOP if the master has the wrong LADDR.

6. Step-by-Step Diagnostic Procedure

Execute these steps on the affected CPU before modifying any program:

1. Capture the diagnostic buffer: in STEP 7, go to PLC > Diagnostics/Settings > Module Information, click Diagnostic Buffer, and Save As as .txt. Capture several days of entries.
2. Identify the connection source: in the same buffer entry, look at Additional Information 1 (often contains the connection ID and TSAP). Open NetPro and map the ID back to the partner CPU.
3. Inventory every SFB20/STOP call in the network: from STEP 7 Options > Cross References, search the entire plant for SFB20 calls. Confirm whether any point at the affected CPU.
4. Search HMI projects: in TIA Portal or WinCC flexible, search for Stop PLC or any function linked to the connection to this CPU.
5. Verify the OB load set: in PLC > Module Information > Information, confirm which OBs are loaded. The protected OBs (OB80-OB87, OB121, OB122) must be present and at the correct priority.
6. Capture an offline copy: of the affected CPU program and the network of all peer CPUs that have configured S7 connections to it.
7. Tag every SFB20 caller: identify the engineering team and ECM record that introduced each SFB20 call so a removal request can be filed.

7. Implementing Error OBs (OB80-OB87 and OB121-OB122)

Loading the standardized error OBs does not cause the STOP to disappear on its own; the OBs simply keep the CPU in RUN while logging the fault. The root cause still has to be addressed. Field experience (as reported in the source thread) shows that adding OB121 alone made the system stable for a few days, then STOPs resumed: this pattern strongly indicates that some STOPs were triggered by programming errors (e.g., bad DB access) while others came from SFB20 STOP commands. Load all available error OBs in one pass:

7.1 Minimum OB121/OB122 Skeleton

In STL, drop this into OB121/OB122 to keep the CPU running while the diagnostic buffer records the fault:

// OB121 - Programming Error
// Local variables: OB121_SW_FLT (WORD), OB121_RES0_1 (WORD),
//                  OB121_RES0_2 (WORD), OB121_PRIORITY (BYTE)

L     #OB121_SW_FLT           // Fault identifier
L     #OB121_RES0_1           // Block type/number where fault occurred
L     #OB121_RES0_2           // DB/operand where fault occurred

// Set a marker to record the fault location
L     1
S     M    100.0              // Programming-fault indicator

// Increment a counter for trending
L     MW   202
+     1
T     MW   202

BE

7.2 OB87 Skeleton - Communication Error (directly relevant to SFB20)

// OB87 - Communication Error
// Local variables: OB87_FLT_ID (BYTE), OB87_RES_INFO_1 (WORD),
//                  OB87_RES_INFO_2 (WORD)

L     #OB87_FLT_ID            // B#16#34 = bad connection resource
                              // B#16#35 = timeout
                              // B#16#36 = redundancy error
L     #OB87_RES_INFO_1        // Connection ID
L     #OB87_RES_INFO_2        // Source TSAP / source address

// Increment a fault counter and log
L     MW   200
+     1
T     MW   200

// Pulse a single-cycle marker for HMI trending
SET
S     M    110.0              // Comm-fault indicator

BE

8. Eliminating Unwanted SFB20 STOP Requests

After the OBs are in place, the root cause still has to be removed.

8.1 Audit and Remove the SFB20 Call

Search the entire project for SFB20 calls:

// STEP 7 cross-reference search
// In SIMATIC Manager:
//   Options > Cross References
//   Object: SFB20
//   Result: list of every CALL SFB20,..., with instance DB and address

Once located, replace the SFB20 with a controlled PG-class Stop CPU call using SFC12/SFC46 - or remove the call entirely. The peer code should look like this when STOP is genuinely required under interlock:

// Peer CPU: Controlled remote STOP via SFB20
// LADDR = logical base address of the affected CPU (from HW Config)
A     "Maintenance_Active"
A     "Operator_Confirms_Stop"
=     "SFB20_REQ_Pulse"

CALL  "STOP_REMOTE" , DB20
   REQ   := "SFB20_REQ_Pulse"
   LADDR := W#16#0100         // example logical address of partner CPU
   STOP  :=
   ERROR :=
   STATUS:=

8.2 Remove PG Rights from HMI / SCADA

HMI connections to the CPU default to PG-class access on S7-300 unless tightened. Restrict it:

1. Open NetPro > Properties > Partner > Connection for every HMI-S7 connection.
2. Set Operating Mode to PUT/GET only if the HMI does not need full PG rights.
3. Alternatively, in Properties > CPU > Protection, assign a CPU password and configure the access level to Read-only for the HMI user.

8.3 Restrict the SFB20/STOP Capability at the CPU

The CPU319-3 PN/DP supports the Connection Resources table in HW Config. For each S7 connection, set the Operating Mode field to PUT/GET instead of S7 Communication if STOP/RESUME is not required. PUT/GET does not carry the STOP privilege and cannot be misused to put a peer CPU into STOP.

9. Hardening the CPU Against Remote STOP

After the immediate STOPs are stopped, harden the configuration to prevent recurrence:

10. Verification, Monitoring, and Long-Term Stability

Once the changes are loaded, monitor the CPU for at least 30 days before considering the fix closed:

1. Diagnostic buffer trend: export the buffer weekly and verify no new Stop caused by SFB20 entries.
2. OB121/OB122/OB87 counters: trend the marker/counter word inserted in section 7. A persistently rising counter indicates an unaddressed fault.
3. Mode retention: confirm the CPU stays in RUN across full shift changeovers, weekend power-on cycles, and plant handovers.
4. Peer CPU SFB20 audit: capture the SFB20 caller project source and store in the engineering change management (ECM) record so future modifications cannot reintroduce the call.
5. Alarms: raise the OB87 counter trip value to Alarm priority (HMI tag, siren, or email) so future recurring faults cannot be ignored.
6. Connection list diff: keep a baseline of NetPro connections and diff it quarterly against the running configuration; any newly added S7 communication connection is a candidate for future STOP abuse.

The user's source thread indicated that OB121 alone made the issue recur after a few days. This pattern is diagnostic of an SFB20 STOP arriving over a configured S7 connection - adding OB121 will not protect against a peer-side SFB20. The complete fix path is therefore: (a) confirm the SFB20 caller is identified and removed; (b) add the full OB8x + OB12x set; (c) lock down the CPU against PG-class STOP; (d) verify for at least 30 days; (e) document the change in ECM.

11. Quick Reference Summary

For the underlying Siemens manuals see the Siemens Industry Online Support entry for the CPU 319-3 PN/DP and the SIMATIC S7-300/400 System and Standard Functions reference. The SIMATIC S7-300 product page lists firmware updates and product notifications that frequently include SFB20 STOP behavior fixes.