SFC21 FILL: Resetting S7-300 Memory Markers and Data Blocks

Overview

The Siemens SIMATIC S7-300 does not provide a single keystroke or operator action that zeros the entire flag (M) memory and all data block (DB) memory while the CPU is in RUN. A 'clear all' can be performed during a cold restart or factory reset, but at runtime the engineer must execute a block that overwrites the memory range with a defined pattern. The standard system function for this job is SFC21 "FILL" from the Standard Library, which copies the contents of a short source area (the pattern) into a destination area repeatedly until the destination is full. When the source pattern is a single byte or word with value 16#00, SFC21 effectively zeros the destination.

This reference covers the practical implementation of SFC21 on a CPU 314C-2 DP running STEP 7 V5.x, with attention to:

• Correct declaration of the BLK ANY pointer that targets M and DB ranges
• Time-out behaviour when the destination block exceeds a few hundred bytes
• Use of SFC20 (BLKMOV) and SFC81 (UBLKMOV) as alternatives
• Operator-triggered execution from the program (input edge, HMI button)
• Verification of the cleared memory via VAT and online watch

Prerequisites

Confirm SFC21 availability in the project offline view: Program blocks → System blocks → SFC21 'FILL'. If the block is shown as '---' or missing, recompile the system data via PLC → Compile and Download Objects and download the HW Config.

SFC21 'FILL' Technical Details

SFC21 belongs to the IEC 61131-3 group of 'fill' or 'initialize' operations. The S7-300/400 operating system supplies the function block in the Standard Library, and it is callable from any priority class (OB1, OB35, OB82, OB100, etc.) without licensing.

Formal interface

The block copies the BVAL content into BLK byte-by-byte (or word-by-word depending on the BVAL declaration) until the BLK length is exhausted. SFC21 does not stop at a DB boundary; the BLK ANY pointer may span multiple DBs only if the underlying data is contiguous in the work memory of the CPU. For S7-300, the maximum BLK length per call is 16 384 bytes (16 KB). Larger targets must be split across multiple SFC21 calls.

RET_VAL error codes

The complete error list is documented in the S7-300/400 System and Standard Functions reference manual, sections describing SFC20, SFC21, SFC81.

Memory Layout on the S7-300

Before writing the SFC21 call, the engineer must know the absolute address ranges that need to be zeroed. For an S7-300, the M area starts at byte 0 and extends to the configured M byte count (default 256 bytes; configurable up to 8192 bytes on most CPU 31xC). Data blocks are addressed by DB number; the default project may have DB1 (or DB2) plus user-created blocks.

The CPU 314C-2 DP supports 64 KB code / 64 KB data work memory on later firmware (FW V3.x); FW V2.x has 32 KB code / 16 KB data. Clearing memory does not change program size but releases the process-image representation. Retentive M or DB variables must be identified before clearing: the S7-300 retains the configured retentive range across POWER OFF / POWER ON, so a runtime SFC21 clear sets those locations to zero only until the next STOP-RUN transition, when retentivity restores the saved values.

Step-by-Step: Clearing M and DB Memory with SFC21

Step 1 – Define the trigger condition

Open OB1 (or a dedicated FC/FB) and declare a local or global bit, e.g. "Clear_Memory_REQ" : BOOL. Drive it from an HMI button or a digital input processed with positive-edge detection:

// STL — edge-detected request from a button
A  "DI_Reset_Button"        // raw input
FP "Edge_Reset_Trigger"     // flag bit, edge memory (BOOL)
S  "Clear_Memory_REQ"

For a one-shot automatic clear on warm restart, set Clear_Memory_REQ in OB100 (startup OB):

// OB100 STL
SET
S  "Clear_Memory_REQ"

Step 2 – Call SFC21 for the M area

Insert SFC21 'FILL' from the Standard Library. The pattern is a temporary local variable declared as BYTE initialised with B#16#00:

// Declaration in OB1 / FC1 / FB1 TEMP section
VAR
   FillByte : BYTE;   // value 16#00 used as the pattern
END_VAR

// STL call — clear 256 bytes of M
A  "Clear_Memory_REQ"
JCN END_FILL
L  B#16#00
T  #FillByte
CALL "FILL"  (   // SFC21
   BVAL    := #FillByte,
   RET_VAL := "Fill_RET_M",
   BLK     := P#M 0.0 BYTE 256
);
END_FILL: NOP 0

The ANY pointer P#M 0.0 BYTE 256 clears MB0 through MB255. Increase the length to match the configured M area. Keep the length under 16 384 bytes per call.

Step 3 – Call SFC21 for each DB

Each DB must be cleared individually. The engineer can use a loop with a STAT variable for the DB number, or hard-code each DB. Example with three data blocks (DB10, DB11, DB20):

// STL — clear DB10 (200 bytes), DB11 (50 bytes), DB20 (400 bytes)
CALL "FILL"  (
   BVAL    := #FillByte,
   RET_VAL := "Fill_RET_DB10",
   BLK     := P#DB10.DBX 0.0 BYTE 200
);
CALL "FILL"  (
   BVAL    := #FillByte,
   RET_VAL := "Fill_RET_DB11",
   BLK     := P#DB11.DBX 0.0 BYTE 50
);
CALL "FILL"  (
   BVAL    := #FillByte,
   RET_VAL := "Fill_RET_DB20",
   BLK     := P#DB20.DBX 0.0 BYTE 400
);

Use a single #FillByte instance for all calls; SFC21 reads it once and repeats the pattern internally.

Step 4 – Limit the call to one cycle (avoid time-outs)

On CPU 314C-2 DP, OB1 runs at the configured cycle time (default 150 ms). A single SFC21 call clearing 16 KB can exceed the OB1 cycle, causing a priority class 26 'OB1 cycle time exceeded' diagnostic event if the cyclic OB has a short watch-dog. Mitigations:

• Run the clear in OB100 (startup) where the cycle watchdog is suspended
• Split the clear into slices processed in OB35 (cyclic interrupt)
• Temporarily extend the OB1 maximum cycle time in HW Config → CPU properties → Cycle / Clock Memory
• Trigger the clear only on operator command and gate with a 'Clear in progress' bit to avoid repeating the fill every scan

Step 5 – Reset the request

Reset Clear_Memory_REQ when the last SFC21 call returns W#16#0000:

// STL
A   "Clear_Memory_REQ"
JCN NO_RESET_REQ
L   "Fill_RET_DB20"           // return of the last SFC21 call
L   W#16#0
<>I
JC  NO_RESET_REQ              // wait until all calls return 0
CLR
S   "Clear_Memory_DONE"       // completion flag for HMI
R   "Clear_Memory_REQ"
NO_RESET_REQ: NOP 0

Ladder Logic Equivalent

For engineers maintaining FBD/LAD code, the same logic is built as a network with a normally-open contact on Clear_Memory_REQ driving the SFC21 block. The BVAL input is wired to a memory byte initialised with 0; the BLK input is entered directly as the ANY pointer (e.g. P#M 0.0 BYTE 256). LAD supports SFC/SFB boxes directly; FBD uses a standard block instance. The DB blocks in the network should be placed in the same network so the execution order is deterministic; avoid interleaving FILL calls with logic that depends on the DB content mid-clear.

Alternative Methods

SFC20 'BLKMOV' (block move)

SFC20 copies a contiguous source area to a destination of identical length. To zero memory with BLKMOV, declare a temporary WORD holding W#16#0000 and use BLKMOV with that WORD as source and the M/DB region as destination. BLKMOV also respects the 16 KB limit per call. Use BLKMOV if you also need to copy non-zero patterns (e.g. preset a recipe from a saved block).

SFC81 'UBLKMOV' (uncoordinated block move)

SFC81 performs the same copy as SFC20 but without coordinating updates to the process image. UBLKMOV is preferred when the destination is a peripheral output (PAA) that should not cause an intermediate 'all outputs high' glitch when the source is shorter than the destination. SFC81 has the same ANY restrictions as SFC20/SFC21.

Data block re-initialisation

If the goal is to restore a DB to its initial (load) values, STEP 7 provides a 'Initialise Data Block' command (right-click DB in SIMATIC Manager → 'Initialise Data Block'). This re-loads the values defined in the offline program. This is faster than byte-wise zeroing for very large blocks but requires the offline project to be in the correct state and briefly stops the data block while the initial values are written.

1. Open SIMATIC Manager → S7 Program → Blocks
2. Right-click the DB → 'Initialise Data Block'
3. Confirm the prompt (this writes the current offline values to the CPU)
4. Alternative: download the entire S7 program (CPU STOP required)

CPU 314C-2 DP Specific Notes

The CPU 314C-2 DP supports the same SFC21 call interface as any other S7-300 CPU. Specific considerations:

• Work memory 64 KB code / 64 KB data on later firmware (FW V3.x); earlier FW V2.x has 32/16 KB. Plan the use of temporary variables accordingly and avoid 16 KB ANY in FB instances that already use significant static data.
• The integrated DP interface and onboard I/O occupy M areas; consult HW Config → CPU → Addresses to see the exact M bytes used by the onboard digital and analogue I/O. Avoid clearing bytes that map to live inputs or onboard outputs that feed actuators.
• Onboard counters and timers map to their own SFBs (SFB36..SFB39 for IEC counters; SFB40..SFB43 for IEC timers). SFC21 must not be used to clear the C/T area; it does not address it, but the engineer should be aware of the address gap and the system-side M bytes reserved by the CPU firmware.

Refer to the S7-300 CPU 31xC and 31x Operating Instructions for cycle-time, retentivity, and integrated I/O behaviour.

Verification

1. Trigger the clear. Set the input or HMI button. Confirm that the OB enters the SFC21 call path using STEP 7 online → 'Monitor/Modify' on the request bit.
2. Watch RET_VAL. All return values should reach W#16#0000 within one cycle (for a 256-byte M area and small DBs) or several cycles (for a multi-kilobyte DB).
3. Inspect the memory. Open a Variable Table (VAT) with the M and DB addresses of interest. Force 'Monitor' mode; every entry should read 0.
4. Check the HMI acknowledgement. The 'Clear_Memory_DONE' bit should latch on, providing operator feedback.
5. Review the diagnostic buffer. CPU → Diagnostic buffer. There should be no 'OB1 cycle time exceeded' event during the clear. If there is, apply one of the mitigations from Step 4 above.
6. Confirm retentivity state. On a STOP-RUN transition, observe whether previously retentive M bytes or DB variables return to non-zero values. If so, the retentive range must be reduced in HW Config or in the DB properties.

Troubleshooting Matrix

Retention and Restart Behaviour

After SFC21 clears the M area and the DBs, the values remain zero only as long as the CPU stays in RUN. On the next STOP / RUN transition:

• Retentive M bytes (defined in HW Config → CPU → 'Retentivity' → M area from byte .. to byte ..) are restored from the retentive memory.
• Non-retentive DB variables are initialised from the DB's initial values (not necessarily zero unless the offline initial value is zero).
• Retentive DB variables are restored from the retentive memory.

If the application requires that the cleared zero state persist across restarts, set every M byte and every DB variable as non-retentive, or clear the retentive range in OB102 (cold restart) before user code runs. Note that OB102 is only executed on a cold restart (CRST); after a warm restart (WRST) or hot restart (HRST, only on S7-400) the retentive range is automatically restored before the user OBs run.

Performance Numbers (typical, CPU 314C-2 DP FW V3.x)

These are order-of-magnitude figures; actual times depend on scan load, communication (PG/OP, S7 communication, DP cycle), and OB1 priority assignment. Always verify with the on-line 'Cycle time' statistics after commissioning and check that the maximum OB1 cycle remains within the configured watch-dog.

Field-Proven Patterns

Pattern A — Operator-triggered one-shot

Most common. Edge-detected HMI button, runs SFC21 once, latches the 'Clear_Memory_DONE' flag, and is suppressed by the operator until the next event. Watch the request bit to ensure it is not set on every scan.

Pattern B — Mode-change clear

Clear M and DB ranges when the machine transitions from RUN-AUTO to RUN-MANUAL, or from a recipe change. Gate the SFC21 call with a 'Mode changed' edge bit. The advantage: deterministic — it runs only when the operator initiates a mode change, not on every restart.

Pattern C — Sliced clear in OB35

For DBs larger than 16 KB, call SFC21 repeatedly in OB35 with a different BLK slice each time (e.g. 4 KB per call, 4 calls for a 16 KB block). A counter in STAT tracks the next slice. The cyclic interrupt OB35 runs independently of OB1, so OB1 cycle time is preserved.

// OB35 STL — sliced clear of a 16 KB DB using 4 slices of 4 KB
L   "Clear_DB_Slice_Counter"     // INT, 0..3
JL   END_SLICE
JU   SL0
JU   SL1
JU   SL2
JU   SL3
SL0: CALL "FILL" (BVAL := #FillByte, RET_VAL := "Fill_RET_SL0", BLK := P#DB100.DBX 0    .0 BYTE 4096);
     JU  INC_SLICE
SL1: CALL "FILL" (BVAL := #FillByte, RET_VAL := "Fill_RET_SL1", BLK := P#DB100.DBX 4096 .0 BYTE 4096);
     JU  INC_SLICE
SL2: CALL "FILL" (BVAL := #FillByte, RET_VAL := "Fill_RET_SL2", BLK := P#DB100.DBX 8192 .0 BYTE 4096);
     JU  INC_SLICE
SL3: CALL "FILL" (BVAL := #FillByte, RET_VAL := "Fill_RET_SL3", BLK := P#DB100.DBX 12288.0 BYTE 4096);
     L  0
     T  "Clear_DB_Slice_Counter"
     S  "Clear_Memory_DONE"
     JU  END_SLICE
INC_SLICE: L   "Clear_DB_Slice_Counter"
           +  1
           T   "Clear_DB_Slice_Counter"
END_SLICE: NOP 0