Reading Siemens S7-300F CPU Status and Diagnostics at Runtime

Overview

Engineers who have programmed a Mitsubishi MELSEC Q-series, iQ-R, or A-series controller rely on a well-known set of special relay (SM) bits, special registers (SD), and link relays for real-time visibility into PLC health, scan timing, and error state. The Siemens SIMATIC S7-300 / S7-300F family, including the fail-safe CPU 315F-2PN/DP, exposes equivalent information through a different but equally deterministic mechanism: error and diagnostic organization blocks (OBs), the system function SFC51 "RDSYSST" for reading system state lists (SSLs), the data-record system function SFC59 "RD_REC" / SFB52 "RDREC" for module diagnostics, the diagnostic buffer, and the status word (STW) of the CPU. This reference consolidates the runtime status sources, the SFCs/SFBs that surface them, and the standard approach used to forward the information to WinCC flexible, WinCC, or a plant SCADA system. Field-proven configurations, common pitfalls, and concrete STL/SCL call examples are included.

Siemens S7-300F Diagnostic Architecture

CPU and module status in an S7-300/400 is not concentrated in a single memory area. Instead, it is distributed across three layers that the user program can sample at runtime:

1. Event-driven: Organization Blocks (OBs). The operating system calls a specific OB when a defined fault, interrupt, or restart event occurs. Local variables declared in the OB's interface give the event timestamp, the logical base address, the channel, and the error code.
2. Polled: System state lists via SFC51 "RDSYSST". A long list of static or slowly-changing data (LED states, communication status, module identification, diagnostic buffer) is read on demand by passing the corresponding SSL_ID to the call.
3. Process-image level: Status word (STW), accumulator flags, and F-channel passivation bits. These are read with normal bit/byte logic just like any input or memory bit.

For monitoring only, SFC51 covers most requirements. For guaranteed capture of a transient diagnostic event, an OB is mandatory - by the time the user program polls for the event, it may already have been cleared by the operating system.

Diagnostic Organization Blocks (OBs)

The S7-300 operating system invokes the following OBs automatically. If the OB is not present in the project and a triggering event occurs, the CPU transitions to STOP unless a default OB (e.g., OB 121/122) is allowed. Always load every diagnostic OB you might need, even if the body is empty, so that the system event is logged and execution continues.

STL skeleton for an OB 82 diagnostic handler (ladder / FBD is also accepted by Step 7):

FUNCTION_BLOCK FB_DiagInt
VAR_TEMP
    t_info : DATE_AND_TIME;
    w_flt  : WORD;
    w_mdl  : WORD;
    b_io   : BOOL;
    i_len  : INT;
    ad     : ARRAY[0..7] OF BYTE;
END_VAR

BEGIN
    t_info := OB82_DATE_TIME;       // 8 bytes BCD - feed to DTL conversion
    w_flt  := OB82_FLT_ID;           // Identifies incoming vs outgoing fault
    w_mdl  := OB82_MDL_ADDR;         // Logical base address of the module
    b_io   := OB82_IO_FLAG;          // 0 = input, 1 = output
    i_len  := OB82_LEN;              // Length of diagnostic data in bytes
    ad     := OB82_DIAG;             // Up to 8 bytes of channel-specific diag
    // Forward to a global status DB and to WinCC flexible tag list
    "dbStatus".diagFlg        := TRUE;
    "dbStatus".lastOB82FltId  := w_flt;
    "dbStatus".lastOB82Mdl    := w_mdl;
    // Set the global "report to SCADA" marker
    "dbStatus".newDiagPending := TRUE;
END_FUNCTION_BLOCK

SFC51 "RDSYSST" - System State Lists

SFC51 is the single most powerful diagnostic call on the S7-300. It returns partial system state lists (SSLs) that the user program can poll at any time. The call signature in STL is:

CALL SFC 51
  REQ    := TRUE            // or a rising edge for one-shot reads
  SSL_ID := W#16#0019       // requested SSL
  INDEX  := W#16#0000       // element index within the SSL
  RET_VAL:= MW 200          // error code
  BUSY   := M 201.0
  SSL_HEADER := DB_Hdr       // STRUCT: DWORD length, WORD SSL_ID
  DR     := P#DB_List.DBX0.0 BYTE 40   // destination area
NOP 0

The DR (destination) area must be at least as long as the SSL entry plus the 6-byte SSL header. Always size the destination DB to the maximum entry length reported for your CPU; if too small, SFC51 returns W#16#8544 (destination area too small) without writing the data.

Common SSL_IDs for Runtime Status

Notes on the LED SSL (W#16#0019): the returned data is six bytes per CPU: the first two bytes encode state (0 = LED off, 1 = LED on, 2 = LED flash slow, 3 = LED flash fast), the second two bytes encode colour (0 = green, 1 = yellow, 2 = red, 3 = white, 4 to 6 = vendor-specific). For the 315F-2PN/DP the relevant LEDs are SF (group fault), BF1 (PROFIBUS DP), BF2 (PROFINET 1), BF3 (PROFINET 2 on two-port CPUs), RUN, STOP, FRCE (force active), MSTR (master on PN ring), and REDF (PROFIsafe / F-error). The reference PDF for decoding these into the HMI was the entry referenced in the original task - see Siemens Industry Online Support entry 22727527 and 9985721 for the S7-300 / S7-400 mapping tables.

SFC51 RET_VAL error codes

Reading the Diagnostic Buffer (SSL 0x0092)

The diagnostic buffer is the most valuable runtime snapshot for post-incident analysis. It is a ring of up to 100 (CPU 315F-2PN/DP) or 200 (CPU 317 / 319) entries; each entry is 20 bytes:

• Bytes 0-7: 8-byte BCD timestamp (year/month/day/hour/minute/second/millisecond)
• Bytes 8-9: WORD event ID
• Bytes 10-11: WORD event class (OB number, error class, etc.)
• Bytes 12-15: DWORD event information 1 (e.g., logical address)
• Bytes 16-19: DWORD event information 2 (e.g., channel code)

Use SSL_ID = W#16#0092, INDEX = W#16#0001 for "all events of oldest first" or higher indexes for newer entries. RET_VAL indicates the number of bytes returned. Common event IDs that surface in production:

On a 315F-2PN/DP, the absence of an MMC card is reported as event 0x4A18 when the card is unreadable. Note that the operating system cannot fully load the project into work memory without a working MMC, so once the card fails the user code is not executing. Therefore polling for "MMC error" is mostly useful for capturing the last diagnostic-buffer entry before the CPU goes to STOP, or for early warning if the card begins to return intermittent read errors (visible as OB84 plus event 0x4A12 / 0x4A18).

Reading Scan Cycle Time

The current, minimum, and maximum scan time are available without any SFC call - they are exposed as local variables in OB 1 (the main cyclic OB):

// Inside OB 1
L    OB1_PREV_CYCLE        // Last cycle time, in milliseconds (DINT)
T    "dbStatus".currCycleMs

L    OB1_MIN_CYCLE         // Shortest since last STOP-RUN
T    "dbStatus".minCycleMs

L    OB1_MAX_CYCLE         // Longest since last STOP-RUN
T    "dbStatus".maxCycleMs

Step 7 / TIA Portal also reports the cycle time in the online > module information dialog. Programmatic extraction via OB1 is preferred when the value must be reported to a higher-level system, because the HMI/SCADA can read the value as a regular tag without needing the engineering tool.

Status Word (STW) and Bit-Level Status

The S7-300 / S7-400 status word is a 9-bit field accessible as bits in the local STW structure. It is read by the OB as it is entered, and it is the same field that drives the LED indicators for the conditional BR memory area:

The /ER (error) and VKE (RLO) bits are the legacy S7-200 / S7-300 names; in the 9-bit STW the equivalent encoding is at bits 5 (OV) and 1 (RLO). Sample read of OV at the end of a math block:

// At the end of a calculation block
A    OV                  // bit from STW: bit 5
JCN  NO_OV
S    "dbStatus".mathOverflow   // latched
L    0
T    "dbStatus".mathResult    // invalidate
NO_OV: NOP 0

LED Status Indicators on the CPU 315F-2PN/DP

The front of the CPU carries SF, BF, RUN, STOP, FRCE, and (on firmware V3.x) MSTR, REDF. The mapping between the live LED and the equivalent SSL_ID W#16#0019 byte is documented in the Siemens support PDF "Getting the Status for the CPU LED Indicators", entry ID 22727527 (S7-300), 9985721 (S7-400), and 24248266 (PROFINET IO extension). Each LED byte returns two sub-bytes (state, colour) that the HMI script can decode to the visual colour seen on the panel.

F-CPU Specific Status Information (315F-2PN/DP)

The 315F-2PN/DP runs the F-library blocks (F-CPU, F-Safety, F-I/O). The runtime status of the safety layer is exposed through:

1. F-host block FB 215 / FB 219 (F-runtime group). Inputs and outputs include a "PASS_ON" flag (passivation triggered), "QBAD" (substitute value active), "ACK_REQ" (operator acknowledgement required), and "IPAR_EN" (i-parameter assignment enabled).
2. F-channel data block. Each F-module exchanges process values plus a per-channel quality byte. Bits in the quality byte (0x00 = valid, 0x40 = substitute, 0x80 = passivated, 0xC0 = invalid) are mirrored to WinCC flexible tags.
3. Diagnostic events 0x4E10 and 0x4E11 in the diagnostic buffer. Capture them by SFC51 SSL 0x0092 and surface the F-event class to the SCADA.

The minimum and maximum PROFIsafe monitoring time must be respected. For the 315F-2PN/DP the default is 150 ms; reducing it below 50 ms risks spurious passivation on noisy networks, while raising it above 6000 ms delays fault detection. Siemens enforces a hard minimum of 1 ms and a hard maximum of 6000 ms for the F-monitoring time setting.

PROFINET IO and PROFIBUS DP Diagnostics

For per-channel diagnostics on a PROFINET device or PROFIBUS slave, the pattern is to call SFC 51 with SSL 0x00B2 (DP slave) or 0x00B4 (DP slave) for the diagnostic record, or to use the higher-level SFBs:

STL pattern for OB 82 to read PROFINET channel diagnostics using SFB 52:

// In OB 82
CALL SFB 52, DB52Inst
  REQ     := TRUE
  IOID     := OB82_IO_FLAG           // 0 = input, 1 = output, 2 = mixed (PN device)
  LADDR    := OB82_MDL_ADDR          // Logical base address of the device
  RECNUM   := B#16#00                // 0 = DS0 standard diagnostics
  RET_VAL  := MW210
  BUSY     := M211.0
  RDREC    := P#DB_DiagBuf.DBX0.0 BYTE 240
NOP 0

The complete DS0 record is six bytes (channel status flag byte, channel number byte, channel error byte, channel error info byte, interrupt status byte, sequence number byte). DS1 is the manufacturer-specific extended diagnostics. The decoding tables are in the manual for the relevant I/O module - search the article number (e.g., 6ES7321-1BH02-0AA0) in Siemens Industry Online Support and select "Diagnostics" in the product tree.

WinCC flexible and WinCC Integration

There are three common ways to display the runtime status on a WinCC flexible panel or in WinCC:

1. HMI tags connected to the status DB. Create a WinCC flexible tag list and link each bit/byte in dbStatus to an HMI tag with the standard acquisition cycle (default 1 s). The OB handlers in OB 80, 82, 84, 86 set the bits; WinCC flexible displays them. The reference entry is the FAQ "How can you have system error messages from a SIMATIC S7-300/400 displayed in WinCC flexible?" in Siemens support.
2. WinCC "Alarm Logging" via SFC 17/18 "ALARM_SQ" and "ALARM_DQ". These send a defined event text to the HMI alarm log. The user program passes the event ID and an associated value list; WinCC formats the message with the configured text. Use this for unbounded error texts that depend on the OB arguments.
3. Area pointer "Coordination" and "Job mailbox". The WinCC area pointer "Coordination" carries 1 byte that reflects the PLC life sign, mode selector, and connection state. The "Job mailbox" pointer is used for screen selection rather than status, but is often configured together with status tags.

Concrete recipe for "system error message to WinCC flexible":

1. Create a global FB "FB_DiagDispatcher" with input i_eventClass (BYTE) and i_eventID (WORD).
2. Inside the FB, call SFC 17 "ALARM_SQ" with EV_ID := 1, SD := local event data. The HMI will receive the alarm. The corresponding text in WinCC flexible / WinCC Alarm Logging references EV_ID 1 with up to 10 associated values.
3. Inside WinCC flexible, configure an alarm message "@Event Class 0x10 / 0x11" and map the associated values to the OB arguments (logical address, channel, error code).
4. On the HMI screen, place an AlarmView control bound to the alarm log. Configure the message classes so that unacknowledged alarms flash red and acknowledged alarms become steady.

Mapping the Status to a Plant SCADA

For integration with WinCC, PCS 7, TIA Portal HMI, or a third-party SCADA, the recommended pattern is a small "PLC status FB" that fills a fixed-layout status DB. The SCADA tag list is then generated from the status DB, and the HMI script decodes the fields. A typical layout:

Stamp the time using SFC 0 "SET_CLK" synchronisation, or read the time with SFC 1 "READ_CLK" for an 8-byte BCD and convert to DTL in the SCADA. The DTL structure was added in firmware V3.0 of the S7-300, and is the recommended field for any new project.

Comparison with Mitsubishi MELSEC Special Relays

Engineers coming from Mitsubishi will be used to a flat list of special relays (SM) and special registers (SD) that the CPU updates on its own. The Siemens approach is event-driven via OBs rather than polled via a memory map, but the information is comparable. The mapping is approximate:

Best Practices and Field-Proven Caveats

1. Load all OBs you might need - even empty OBs. An unprogrammed OB 82 keeps the CPU in RUN on a diagnostic interrupt; a missing OB 82 takes the CPU to STOP. The empty-OB pattern is standard on F-CPU installations.
2. Always capture the entire diagnostic array. Splicing OB82_DIAG to one byte destroys channel resolution and makes root-cause analysis impossible.
3. Use the diagnostic buffer as ground truth. When an error log from a third-party HMI disagrees with the SCADA, the buffer entry is the source of record. It survives power-cycles and is the official event log.
4. Set OB80 cycle time to 3-5x the typical scan. The default of 150 ms on the 315F-2PN/DP is conservative; on a fast 20 ms cycle, a 100 ms maximum still gives a 5x safety factor while preserving short fault response.
5. Don't poll SFC51 at 100 ms. SFC51 is not free; calling it on a 100 ms cycle adds 1-2% of CPU load. Use a 1 s scan or call on operator request.
6. Watch the F-monitoring time. Reduce it only if the network is clean; the PROFIsafe V2 protocol tolerates a worst-case jitter up to the F-monitoring time minus the F-WD-time of the module.
7. Mirror the LED bytes, not just the LED colour. A flashing yellow SF and a steady red SF have different states in SSL 0x0019; treat them as distinct alarms.
8. Document the SSL_IDs you use. Some IDs are CPU-family-specific (0x00A0 is S7-400 only). Use the SSL 0x0000 list at project start to discover which ones are supported.
9. Synchronise the clock to a network time source. The 315F-2PN/DP supports NTP via the "Time of Day" interface. Without sync, the diagnostic buffer timestamps are useless across shifts.
10. Force a STOP on critical F-events. When a safety-relevant event occurs (F-channel passivated, OB123 triggered), consider routing the application to a controlled stop using SFC 46 "STP" only after the safety group is in a defined state; do not stop mid F-cycle.

Troubleshooting Matrix

Frequently Asked Questions