Detecting S7-300 PLC Program Changes Using SFC51 and FB26

Overview and Engineering Context

Backing up PLC software is the easy part. Proving that the backup you took last Tuesday still matches the program actually running on the controller this Friday is the hard part. In Siemens SIMATIC S7-300 and S7-400 systems, there is no single "modified since last backup" flag exposed on the front of the CPU. The information exists inside the system, however, in the System Status List (SSL) and in the diagnostic buffer. The job of a program-change indicator is to read that information at runtime, latch it into a bit that an electrician or technician can see on a panel light or HMI, and then clear that bit only when a deliberate reset action is performed.

This article documents the SFC51-based pattern used for S7-300 controllers. The same architecture applies to S7-400, but the SSL IDs and parameter widths are different and must be retuned. The pattern also adapts cleanly to S7-1200 and S7-1500 using the modern RD_SINFO, RDSYSST, and Trace-based change logs, but those platforms are out of scope here.

Prerequisites

• STEP 7 V5.x (or compatible) installed and licensed for the target CPU family.
• CPU firmware compatible with SFC51 (standard on every S7-300 from 314 onward; on S7-400 SFC51 is supported but with different SSL list boundaries).
• A free digital output or HMI tag wired as the Program-Modified indicator.
• A momentary pushbutton wired to a digital input for the 5-second reset action.
• The Siemens Application Note FAQ entry 51577288 "Detecting program changes in S7-300/400" and the attached 51577287_PROG_CHECK_en.pdf.

SFC51 Fundamentals: Reading the System Status List

SFC51 (RDSYSST - Read System Status List) is the CPU firmware function block that lets user code read partial SSL snapshots. The block signature in STEP 7:

CALL "RDSYSST" // SFC51
REQ    := TRUE             // Start the read
SZL_ID  := W#16#0019       // SSL list selector
INDEX   := W#16#0000       // Sub-index within the list
RET_VAL := MW100           // Return code
BUSY    := M101.0          // Operation in progress
SZL_HEADER := DB20.DBX0.0 // 32-byte header (length, count)
DR      := P#DB21.DBX0.0 BYTE 240  // Destination area for the SSL record

SFC51 is asynchronous. The first call with REQ=TRUE starts the read; subsequent calls must keep REQ=TRUE until BUSY=FALSE and then evaluate RET_VAL. A non-zero return in RET_VAL on a non-busy call is the error code (e.g. W#16#80A1, W#16#80B1, W#16#80C3, W#16#80C4) - full mapping is in the STEP 7 online help under SFC51.

Key SSL IDs for Change Detection

The full catalog of SSLs is in the STEP 7 Online Help under "System Status Lists (SSL)" and in the S7-300 CPU 31xC and 31x: System Manual. Note that not all SZL-IDs are valid on all CPUs: the list is firmware-dependent. Always test the read with a temporary program before committing the design.

FB26: The Program-Status Block

The block published under Siemens FAQ 51577288 is FB26 (sometimes labeled "CPU_STATUS_FB" or similar). Its job is to periodically poll several SSLs, extract the bits that matter, and expose them on a small data block interface so OB1 (or OB35) can use them as boolean conditions.

FB26 Interface

Internally, FB26 maintains a static-instance data block that holds the previous SSL contents. On each cycle, it reads the current SSL, XORs the relevant fields with the snapshot, and sets PROG_MODIFIED if any monitored field differs.

Step-by-Step: Building the Program-Modified Indicator

Step 1 - Import the FB26 source

1. Download the FAQ attachment from entry 51577288.
2. Open your STEP 7 project and select File > Retrieve to restore the attached archive.
3. Drag the FB26 source into the Blocks container of your S7 program.
4. Right-click FB26 > Check Block Consistency and compile.

Step 2 - Create the instance DB

1. Right-click FB26 > Insert SDB / Instance DB.
2. Assign DB number (e.g. DB260) and name "Prog_Change_DB".
3. Open DB260 and confirm the instance interface matches the table above.

Step 3 - Call FB26 from OB1 (or OB35 for cyclic)

// OB1 STL - call FB26 every scan
CALL "Program_Status" , "Prog_Change_DB"
  SZL_ID_1  := W#16#0019
  SZL_IDX_1 := W#16#0000
  SZL_ID_2  := W#16#0111
  SZL_IDX_2 := W#16#0000
  CYCLE_TIME:= T#500MS
  CPU_RUN   := M200.0
  CPU_STOP  := M200.1
  CPU_HALT  := M200.2
  PROG_MODIFIED := M201.0     // <-- the bit you want
  HARDWARE_MOD := M201.1
  FORCE_ACTIVE := M201.2
  LED_RUN   := M202.0
  LED_STOP  := M202.1
  LED_FAULT := M202.2
  KEY_SWITCH:= MB203
  ERROR     := M204.0
  STATUS    := MW205

If you call from OB35 (100 ms default), debounce the rising edge of PROG_MODIFIED with a one-shot to avoid latching on a single glitch during a long-running SFC51 read.

Step 4 - Latch the change bit

The raw PROG_MODIFIED from FB26 toggles whenever the SSL differs from the snapshot at FB26 startup. If you call FB26 cold on every CPU restart, the snapshot rebuilds from whatever program is now resident and the bit will not latch a real change. Two design options solve this:

• Remanent snapshot DB. Store the captured SSL bytes in a remanent DB (set Retain = true on the DB properties) so the comparison survives a power cycle.
• Two-stage latching. In OB1, write the bit into a remanent flag, e.g. M201.0, and only clear it through the 5-second reset. FB26's internal flag becomes a "raw change detected this scan" pulse.

// Two-stage latch (OB1 STL)
AN    M 207.0               // Reset_PB edge
A     DB260.DBX...".PROG_MODIFIED // raw change
S     M 208.0               // Program_Changed_Latched (remanent)

A     M 207.1               // Reset_PB pressed >= 5s
R     M 208.0

Step 5 - Reset pushbutton with 5-second hold

// Reset logic using IEC timer (OB1 STL)
A     I 0.0                  // Reset pushbutton NC/NO contact
AN    M 207.0                // one-shot edge memory
L     S5T#5S                 // 5 second preset
SD    T 50                   // pulse timer, on-delay
NOP   0
NOP   0
NOP   0
A     T 50
=     M 207.1                // PB held >= 5s
=     M 207.0                // raw PB state for next cycle edge

Alternative: use a counter that increments each OB1 cycle the button is held, and resets when released. When the counter reaches the value corresponding to 5 s at the OB1 scan rate (e.g. 250 cycles at 20 ms), set the reset flag. This avoids tying up an S7 timer resource.

Step 6 - Wire the indicator output

Drive any free digital output with M208.0. Most plants use a yellow or amber pilot lamp on the cabinet door labeled "PROGRAM CHANGED - BACKUP REQUIRED". For HMI visibility, expose M208.0 and the reset button on a WinCC flexible / TIA Portal faceplate.

S7-400 Adaptation

SFC51 is available on S7-400 as well, but with caveats:

• SSL_ID W#16#0019 is supported on S7-400 with an extended data record length (28 bytes vs. 14 on S7-300). Allocate a larger destination buffer.
• SSL_ID W#16#0111 is not valid on every S7-400 CPU. Use W#16#0011 with INDEX=1 instead, which is the canonical module identification list on S7-400.
• FB26 as published is targeted at S7-300. The internal data record lengths and the offset of individual status bits differ. Recompile from the F-SCL source provided in the FAQ and re-validate against the S7-400 System and Operating Manual before deploying.
• On S7-400H (redundant), call FB26 only from the active CPU; the standby CPU returns W#16#80C3 in RET_VAL when SSLs are queried outside its leadership.

Verification and Commissioning

1. Baseline test. Power the CPU, wait for RUN, confirm M208.0 = 0.
2. Trigger test. Connect STEP 7, perform PLC > Download User Program to Memory Card with a single bit toggled in OB1. Confirm M208.0 latches ON.
3. Reset test. Hold the reset pushbutton for 5 s. Confirm M208.0 returns to OFF.
4. Power-cycle test. Power off the PLC and power back on. Confirm M208.0 remains OFF (snapshot DB is remanent) but the LED indicators still report correct CPU state.
5. Diagnostic buffer check. In STEP 7, open PLC > Diagnostic/Setting > Diagnostic Buffer. The event "Download of user program" with event ID W#16#4502 should be the topmost entry after each download.

Troubleshooting Matrix

Program Change Backup Workflow

The indicator is only as useful as the procedure around it. Recommended workflow per cell:

1. Maintenance confirms the yellow "Program Changed" lamp is ON.
2. Technician opens STEP 7, archives the project to the versioned backup path (e.g. \\fileserv\PLC\Line_07\YYYY-MM-DD.zip).
3. Technician performs an offline block comparison: Blocks > Compare Blocks (Online > Offline). Any delta must be reviewed and signed off by the engineer of record.
4. Technician presses the cabinet-door reset button for 5 s; the yellow lamp extinguishes.
5. The release of the reset is logged in the CMMS ticket.

If the workflow is supervised from an HMI / SCADA layer, replicate the bit onto the supervisory tag using OPC / OPC UA so that the change event can be time-stamped and archived alongside other production events.

Adjacent Use Case: Drive-Side Change Indication

The same engineering pattern (latch a "modified" bit, expose on the cabinet, reset with a held button) applies to variable-frequency drives. On AutomationDirect DURApulse GS20(X) drives, the PLC-Quick-Start demo in the official DURApulse GS20(X) VFD Quick Start Part 2 video walks through the drive-side state indicator concept: the drive remembers its power-on state separately from the PLC, and a parameter write from the keypad or digital input changes that state. If you are wiring an end-to-line change-detection scheme (PLC + drive), mirror the PLC change bit onto a drive parameter read (e.g. GS20 parameter 00-04 = "Drive status") so the cabinet lamp can reflect changes on either side.

FAQ