PCS 7 S7 CPU Memory Consumption: SFC 51 RDSYSST Guide

Overview: Reading CPU Memory Consumption in PCS 7 and SIMATIC S7

Plant operators running PCS 7 on SIMATIC S7-300, S7-400, S7-1500, or ET 200MP CPUs routinely need to monitor the live memory footprint of the controller: how much of the work memory is consumed by the user program, how much load memory is still available on the SIMATIC Memory Card, and how large the retentive memory segment has grown after years of recipe data. The TIA Portal online diagnostics and the SIMATIC Manager module information dialog both show a static snapshot, but neither is designed for cyclic reporting to WinCC, a historian, or a centralized asset monitoring tool. To expose those values as live tags you must read the System State Lists (SSL) directly from the CPU using SFC 51 RDSYSST with SSL partial list W#16#0113.

This reference covers the full engineering workflow: the underlying S7-1500/ET 200MP memory model, the parameter set of SFC 51, the exact data structure returned by SSL_ID 0113, ready-to-paste SCL and STL implementations, integration of the resulting tags into WinCC, the limits of the PCS 7 @CPU_RT block, and a troubleshooting matrix for the most common error codes returned by the function call.

Prerequisites

• SIMATIC PCS 7 V8.x or higher, or STEP 7 V5.5 / TIA Portal V15 or higher for S7-1500/ET 200MP engineering.
• Firmware requirements for using the PCS 7 driver wizard block @CPU_RT (only relevant if you choose that path):
  • Single (non-redundant) S7-400 CPU: firmware 5.0 or higher.
  • Redundant H-CPU (e.g. CPU 410-5H): firmware 4.5 or higher.
• The CPU must be in RUN or RUN-P mode to read SSL data.
• An OB1 (or any cyclic OB) in which to call SFC 51.
• A shared DB that buffers the returned memory values, or a tag group that is published to WinCC via the standard PCS 7 driver.
• For S7-1500 specifically, reference the manual collection at the Siemens docs portal for the memory model of your specific CPU order number (e.g. CPU 1515-2 PN, CPU 1518-4 PN/DP, CPU 1513-1 PN).

Memory Architecture of S7-1500/ET 200MP CPUs

Before you read SSL data you must understand what the controller actually stores and where. The S7-1500/ET 200MP system separates memory into the following areas, as documented in the S7-1500/ET 200MP Manual Collection — Memory Requirements and Memory Usage:

When SSL partial list W#16#0113 is read, the CPU returns a row for each of these areas with the total size, the amount currently used, and (depending on CPU generation) the free remainder. The exact coding of the memory type identifier in the returned data record is documented in the SSL reference of your CPU's function manual.

Method 1 — SFC 51 (RDSYSST) System State List Read

SFC 51 RDSYSST is the canonical way to read system state lists on every S7 CPU that supports the standard system function library. It is located in the Standard Library > System Function Blocks > DIAGNSTC folder of every STEP 7 and TIA Portal installation. The function is asynchronous on multi-read SSLs: you trigger the read, poll the BUSY output, and consume the data only after BUSY returns to FALSE with RET_VAL = 0.

Formal parameters of SFC 51

SSL_ID W#16#0113 — Module Memory Areas Partial List

SSL partial list W#16#0113 is the standardized request that returns the memory areas of the module. The xy in the official documentation form W#16#xy13 encodes whether the read should be performed synchronously or asynchronously, and whether the partial list should be re-read fully or incrementally — for cyclic monitoring use W#16#0113 (synchronous partial list read).

The SZL_HEADER tells you two things:

• LENTHDR — length of one data record in bytes (e.g. 28 bytes for a typical S7-1500 memory row).
• N_DR — number of data records actually returned. The S7-1500 typically returns 4 to 6 rows (one per memory area), older S7-400 firmware may return a different number.

Each returned data record contains, in this order on a typical S7-1500 CPU:

Implementation in Structured Text (SCL) for TIA Portal

The cleanest implementation is in SCL inside a function block (FB) that holds the asynchronous state. The FB is called once per cycle from OB1; the rising-edge detection on REQ prevents the SSL from being re-issued every cycle.

FUNCTION_BLOCK "FB_MemMon"
VAR
    bStart          : BOOL;          // rising-edge trigger
    bBusy           : BOOL;
    iRetVal         : INT;
    szlHeader       : STRUCT
        LENTHDR     : WORD;          // length of one DR in bytes
        N_DR        : WORD;          // number of DRs returned
    END_STRUCT;
    aDr             : ARRAY[0..15] OF DWORD;  // raw DR buffer (16 DWORD = 64 bytes)
    iDrLen          : INT;
    iDrCount        : INT;
    drWorkTotal     : DWORD;
    drWorkUsed      : DWORD;
    drLoadTotal     : DWORD;
    drLoadUsed      : DWORD;
    drRetainTotal   : DWORD;
    drRetainUsed    : DWORD;
    drSystemTotal   : DWORD;
    drSystemUsed    : DWORD;
END_VAR

BEGIN
    // Trigger a new read every 5 seconds (prescaler in OB1)
    IF bStart AND NOT bBusy THEN
        RDSYSST(
            REQ        := TRUE,
            SZL_ID     := W#16#0113,
            INDEX      := W#16#0000,
            RET_VAL    := iRetVal,
            BUSY       := bBusy,
            SZL_HEADER := szlHeader,
            DR         := aDr
        );
    ELSIF bBusy THEN
        // Poll the asynchronous read
        RDSYSST(
            REQ        := FALSE,
            SZL_ID     := W#16#0113,
            INDEX      := W#16#0000,
            RET_VAL    := iRetVal,
            BUSY       := bBusy,
            SZL_HEADER := szlHeader,
            DR         := aDr
        );
        IF NOT bBusy AND iRetVal = 0 THEN
            // Parse N_DR records of LENTHDR bytes each
            iDrCount := WORD_TO_INT(szlHeader.N_DR);
            // Application-specific parsing: walk aDr[] based on LENTHDR
            // and dispatch on Memory type code to the right output WORD.
        END_IF;
    END_IF;
END_FUNCTION_BLOCK

Implementation in STL (Statement List) for STEP 7 V5.x and PCS 7

For classic PCS 7 stations on S7-400 the same logic in STL is typically embedded in a small FB inside the master data library. The pattern is identical: fire REQ on a rising edge, poll BUSY, copy the DR to a global DB when BUSY = 0.

// In OB1, calling FB100 "FB_MemoryMonitor" once per cycle
CALL  FB100, DB100
      bStart := "tag_5s_tick"
      bBusy  := DB100.bBusy
      iRetVal:= DB100.iRetVal
      szlHdr := DB100.szlHdr
      aDR    := DB100.aDR
      // ...

// Inside FB100, network 1: rising edge + asynchronous call
A     #bStart
AN    #bBusy
JC    _DO
// BUSY poll path
CALL  SFC 51
      REQ    :=FALSE
      SZL_ID :=W#16#0113
      INDEX  :=W#16#0000
      RET_VAL:=#iRetVal
      BUSY   :=#bBusy
      SZL_HEADER:=#szlHdr
      DR     :=#aDR
      BE

_DO:  CALL  SFC 51
      REQ    :=TRUE
      SZL_ID :=W#16#0113
      INDEX  :=W#16#0000
      RET_VAL:=#iRetVal
      BUSY   :=#bBusy
      SZL_HEADER:=#szlHdr
      DR     :=#aDR
      BE

@CPU_RT Block in PCS 7 — What It Does and Does Not Provide

From PCS 7 V7.0 onward the driver wizard automatically inserts the APL block @CPU_RT into the AS program. It exposes runtime statistics of the CPU: OB cycle times (OB1, OB35, OB82, …), the current and average runtimes of the priority classes, and the communication load contributed by the five most active partners. Many engineers expect @CPU_RT to also report work and load memory — it does not. @CPU_RT is built on SFC 78 / SFC 79 and on SFB 52 (diagnostic data record read), not on SFC 51.

To expose memory statistics to WinCC in PCS 7, the recommended architecture is therefore:

1. Create a small FB (e.g. FB100) that calls SFC 51 with W#16#0113, parses the data records, and writes the result to a dedicated DB (e.g. DB100) in the AS.
2. Run the driver wizard so the DB100 tags appear in the WinCC tag list as "Memory.WorkUsed", "Memory.WorkTotal", "Memory.LoadUsed", "Memory.LoadTotal", "Memory.RetainUsed", "Memory.RetainTotal".
3. Add the tags to a WinCC picture with a bar graph or a numeric I/O field; archive them with a 1-minute tag logging cycle if you need long-term trending.

WinCC Integration of Memory Tags

Once the parsed memory values are written to the AS-side DB, the rest is standard PCS 7 / WinCC engineering:

1. In SIMATIC Manager, open the S7 program and add the DB (e.g. DB100) to the symbol table with the type DB_Memory.
2. Re-run the PCS 7 driver wizard (Component View > AS > Driver Wizard > Compile OS). The wizard generates the WinCC tag structures for the OS server.
3. In WinCC Explorer, add the new structure tags to your faceplate. Use a horizontal bar with two thresholds (yellow at 75 % used, red at 90 % used) for each memory area.
4. For S7-1500 with WinCC Professional / TIA Portal HMI, the equivalent path is Project tree > PLC > Program blocks > DB100 > HMI tag synchronization. Tick the HMI-visible flags on the data blocks whose values you want to expose.

A common panel template is a single faceplate with six bar graphs (work used, work free, load used, load free, retentive used, retentive free), each bound to one DWORD. The raw DWORD is the byte count; divide by 1024 to display in KiB, or by (1024*1024) for MiB. The conversion is purely cosmetic; the raw value is what the SSL reports.

Alternative Methods: Web Server, TIA Diagnostics, and RD_DINFO

SFC 51 is not the only path. The following alternatives are useful when the SFC is unavailable (e.g. on a non-standard CPU type) or when you need richer diagnostics than SSL 0113 provides.

S7-1500 web server

Every S7-1500 / ET 200MP CPU ships with an integrated web server. Activate it in CPU Properties > Web Server and grant the user group read access to diagnostics. The Diagnostics > Memory page renders the same values as SFC 51 W#16#0113 in human-readable form, refreshed every 5 s by the CPU firmware. You can scrape that page with a small Python or PowerShell script for asset monitoring, but the SFC remains the better path for cyclic WinCC integration because the web server does not expose the data as a tag.

RD_DINFO / RD_DIAG data record read

For S7-1500 in TIA Portal, the Get_Memory_Usage data record (diagnostics index 0x0011) can be read with the standard RD_DINFO or RD_DIAG instruction. This is a different encoding than SFC 51 SSL 0113 — it returns the same logical information but as a self-describing JSON-like structure inside the diagnostics buffer. Use this path if you want a structured payload that already separates work, load, and retentive usage into named fields.

Online diagnostics in TIA Portal

The Online > Diagnostics > Memory view in TIA Portal is a manual read of the same data; it is not scriptable and not visible to WinCC. Useful for commissioning, not for production reporting.

Verification and Field Commissioning

After the FB is compiled and downloaded, verify the implementation in five steps:

1. Place the CPU in RUN and force the trigger tag (bStart) to TRUE. In a watch table, observe iRetVal; it must read W#16#0000 after one read cycle.
2. Read szlHeader.LENTHDR and szlHeader.N_DR. For an S7-1500 CPU 1515-2 PN with firmware 2.9, expect LENTHDR = 28 and N_DR ≥ 4.
3. Walk the data records with a watch table and a SCL debug snippet that prints Memory type code — Total — Used — Free in human-readable form. Cross-check the totals against the CPU's online diagnostics page.
4. Confirm that the WinCC tag group populates by opening WinCC Explorer and inspecting the tag list; if the tags are missing, the driver wizard has not been re-compiled.
5. Run the system under load (force a high communication load and a large DB) and confirm the values move within two OB cycles of the trigger.

Sanity checks

• For any memory area, Used + Free should equal Total within one DWORD. If it does not, the CPU is in the middle of a memory re-organization (e.g. online block delete) — wait one cycle and re-read.
• The work memory total must match the value printed on the CPU's front label (e.g. 500 KB for CPU 1515-2 PN, 3 MB for CPU 1518-4 PN/DP). If it does not, you are reading the wrong partial list or the wrong CPU type.
• Load memory total must be ≤ the size of the SIMATIC Memory Card. If it is greater, the firmware is reporting the logical size of the project, not the card size.

Troubleshooting Matrix