Fixing SFC Not Loaded Error with READ_DBL and WRIT_DBL on S7-400

Problem Overview

When executing READ_DBL (SFC83) and WRIT_DBL (SFC84) on a SIMATIC S7-400 CPU 416-2 equipped with a 2 MB Memory Card (MC), the CPU returns an "SFC not loaded" diagnostic and refuses to perform the read/write operation. The application context is a recipe backup/restore between the HMI and the controller's work memory, with the MC flash card acting as the long-term storage area. The behavior is observed on STEP 7 V5.5 Service Pack 2 (revision V5.5.0.0) with the standard S7-400 system blocks.

The error is reproducible: every call to either block places the CPU into STOP or generates a synchronous OB121 error with W#16#8085 ("SFC not loaded") / W#16#8082 ("SFC does not exist") depending on the diagnostic configuration. Because the SFCs in question are part of the S7-400 operating system, the failure normally points to a configuration or call-level issue rather than a missing firmware component.

System Context and Hardware

Target platform used in the field case:

• CPU: S7-400 CPU 416-2, 6ES7 416-2-series (typical MLFB 6ES7 416-2XK02-0AB0 / 6ES7 416-2XN05-0AB0)
• Work memory: 2.8 MB code / 2.8 MB data (the "2 MB" referenced in the source corresponds to the MC card capacity or a project-specific work memory partition)
• Load memory: 2 MB MC flash card inserted in the memory card slot
• Engineering: STEP 7 V5.5, revision V5.5.0.0
• HMI: WinCC flexible / TIA Portal HMI acting as the recipe backup client

Root Cause Analysis

Three root causes are typical for the "SFC not loaded" symptom when the controller, firmware, and project are otherwise compatible.

1. The Destination/Source DB Has the UNLINKED Attribute

READ_DBL and WRIT_DBL cannot operate on a DB that was generated with the UNLINKED attribute. An UNLINKED DB exists only in load memory and is not copied into work memory. Because the SFC must move the block to/from work memory to satisfy the operation, the CPU returns W#16#8082 ("SFC does not exist") or rejects the call with W#16#80B1 / W#16#80B2 depending on the parameter that violates the rule. The fix is to create a normal (linked) DB; reserve the UNLINKED attribute for diagnostics-only data that is never read or written through the operating system.

2. The SFC Block Number Is Not Resolved in the Project

Although SFC83 and SFC84 are part of the CPU 416-2 firmware, the project must still reference them symbolically or by absolute number. If the SFC was overwritten with a user-defined FB/FC of the same number, or if a renamed copy in the program blocks folder shadows the system call, the compiler resolves the wrong block. STEP 7 then downloads the shadowed FC/FB and the CPU cannot find the genuine system SFC. The fix is to ensure the call uses SFC83 / SFC84 from the Standard Library → System Function Blocks folder, and to delete any user block that collides with the number.

3. REQ Is Not Held Until the Operation Completes

The SFC83 / SFC84 call uses a level-triggered REQ. The input must stay TRUE until the SFC sets BUSY. Releasing REQ before the load-memory cycle starts leaves the SFC in an undefined state and the CPU raises W#16#8085. In the field case, the program drove REQ with a one-shot pulse from a positive edge of a flag; the call therefore completed before the flash write could latch.

SFC83 (READ_DBL) and SFC84 (WRIT_DBL) Reference

The S7-400 implementation of these SFCs is documented in the SIMATIC S7-400 SFCs reference manual. The S7-1200 / S7-1500 instruction manual that is sometimes cited in the search results (READ_DBL and WRIT_DBL for S7-1200) is a different instruction set and must not be substituted.

Companion blocks that are often useful in the same recipe flow:

• SFC82 CREA_DBL - creates a DB in load memory (MC) and is required when the destination does not yet exist on the card.
• SFC85 CREA_DB - creates a DB in work memory; called from within OB100/OB101 to allocate the work-memory shadow at startup.
• SFC22 CREAT_DB - legacy alternative for SFC85.

Memory Architecture on the S7-400

Understanding the S7-400 memory model is essential before commissioning a recipe flow:

1. Work memory - integrated, battery-backed (or capacitor-backed) RAM. Holds the code, the linked DBs that the user program is actively reading/writing, and all instance DBs.
2. Load memory - the MC flash card in the slot on the front of the CPU. Non-volatile. Holds the project image, all linked DBs, and any UNLINKED DBs.
3. Retentive memory - the subset of work memory that survives a power cycle (configured in the CPU properties, "Retentive Memory").

A recipe backup with WRIT_DBL therefore writes the current work-memory DB to the MC. A recipe restore with READ_DBL copies a previously saved DB from the MC back into work memory, after which the user program can access the freshly loaded values through the same symbolic name.

Step-by-Step Solution

Step 1 - Remove the UNLINKED Attribute

1. Open the SIMATIC Manager project.
2. Right-click dbSEQUENCE_STEP in the program blocks.
3. Select Properties → Attributes.
4. Clear the UNLINKED checkbox. Save and close.

Step 2 - Re-Insert the SFC Calls from the Standard Library

1. Open the Standard Library → System Function Blocks catalog.
2. Drag SFC83 READ_DBL and SFC84 WRIT_DBL into the FC/FB/OB that performs the recipe I/O.
3. Confirm that the program block editor resolves the call to SFC83 / SFC84 and not to a user block with the same number.

Step 3 - Drive REQ as a Set/Reset Latch

Replace the positive-edge one-shot on REQ with a set/reset pattern keyed on BUSY and DONE:

// Write trigger latch
A     "bWriteOneShot"
S     "bWriteActive"      // holds REQ TRUE
// Reset when BUSY is set, indicating the SFC has accepted the job
ON    "bBusy"
ON    "iErrorDB".WRIT_DBL_ERR  // any error from the previous call
ON    "bDoneDB".WRIT_DBL_DONE  // operation complete
R     "bWriteActive"

Step 4 - Add the DONE and ERROR Handling

Monitor BUSY, RET_VAL, and a manually derived DONE signal. The SFC does not return a separate DONE output, so derive it as NOT BUSY AND NOT REQ on the trailing edge of the call.

Step 5 - Recompile and Re-Download the Project

1. PLC → Compile and Download Objects → confirm the SFC folder is in the download set.
2. Perform a full download (not delta) so the system blocks are re-resolved.
3. Cold restart (OB100) the CPU to clear any in-flight jobs.

Sample STL Code

FB that handles one recipe-DB read and one write. Designed to be called by the HMI recipe view:

FUNCTION_BLOCK FB_RECIPE_IO
VAR
    bWriteReq    : BOOL;
    bReadReq     : BOOL;
    bBusyW       : BOOL;
    bBusyR       : BOOL;
    iErrW        : INT;
    iErrR        : INT;
    bDoneW       : BOOL;
    bDoneR       : BOOL;
END_VAR
BEGIN

// ---- WRIT_DBL: work memory -> MC card ----
CALL    "WRIT_DBL"   // SFC84
REQ     := bWriteReq,
SRCBLK  := "dbSEQUENCE_STEP",
RET_VAL := iErrW,
BUSY    := bBusyW,
DSTBLK  := "dbSEQUENCE_STEP";

IF bBusyW THEN
    // Job accepted, latch release
    bWriteReq := TRUE;
    bDoneW    := FALSE;
ELSIF iErrW = 0 THEN
    bDoneW := TRUE;
ELSE
    bDoneW := FALSE;
END_IF;

// ---- READ_DBL: MC card -> work memory ----
CALL    "READ_DBL"   // SFC83
REQ     := bReadReq,
SRCBLK  := "dbSEQUENCE_STEP",
RET_VAL := iErrR,
BUSY    := bBusyR,
DSTBLK  := "dbSEQUENCE_STEP";

IF bBusyR THEN
    bReadReq := TRUE;
    bDoneR   := FALSE;
ELSIF iErrR = 0 THEN
    bDoneR := TRUE;
ELSE
    bDoneR := FALSE;
END_IF;

END_FUNCTION_BLOCK

SFC83 / SFC84 Return Values

The RET_VAL output returns a W#16#80xx code on parameter errors and a W#16#8xxx code on job-level errors. The codes most often seen in the recipe backup flow are:

Diagnostics Procedure

1. Open PLC → Monitor/Modify and place the SFC in the monitored area. The online view will display the exact RET_VAL.
2. Open the CPU diagnostic buffer (PLC → Diagnostic Buffer) and capture the event that lines up with the failure. A W#16#8085 event confirms the SFC is not being recognized.
3. Open PLC → Accessible Nodes and read the CPU order number and firmware version. Verify that SFC83/SFC84 are part of that firmware (CPU 416-2 firmware V4.0 and later include both).
4. Insert a temporary OB121 / OB122 to capture the synchronous error block type and number. If OB121 reports SFC83/SFC84, the project is calling the wrong number.

Verification

1. From the HMI, trigger a recipe save. The CPU sets BUSY, the call drops BUSY after one or two scans, and RET_VAL is 0.
2. Open PLC → Online → Accessible Nodes → File System and confirm the recipe DB appears in the MC file list.
3. Power-cycle the CPU. The recipe DB on the MC is reloaded into work memory automatically because the project contains a linked DB with the same number.
4. From the HMI, trigger a recipe restore. READ_DBL returns 0, the work-memory DB contains the saved values, and the HMI displays the restored recipe.
5. Check SF, BF, and BATF LEDs on the CPU. All three must remain off.

Companion Blocks for a Complete Recipe Backup

A production-grade recipe flow on the S7-400 also uses the following SFCs:

• SFC82 CREA_DBL - create the destination DB on the MC card before the first write.
• SFC83 READ_DBL - read a recipe from MC card into work memory.
• SFC84 WRIT_DBL - write the current recipe from work memory to MC card.
• SFC85 CREA_DB - allocate the work-memory DB at startup so that the ANY pointer can resolve.
• SFC20 BLKMOV - copy a recipe between two work-memory DBs in a single scan without disturbing the load memory.

Common Pitfalls

• Using the S7-1200/1500 READ_DBL / WRIT_DBL extended instructions on the S7-400. The TIA Portal instruction is a different block with different parameters. The S7-400 implementation is the SFC83/SFC84 pair from the standard library.
• Calling SFC84 in OB1 with a 50 ms cycle. A single flash write can take 200 ms to 2 s. Use the BUSY feedback to gate the next request.
• Forgetting the MC card. If the MC is removed or unformatted, the CPU returns W#16#80C0 - W#16#80C4. The CPU does not stop, but every save fails silently.
• Overwriting a UNLINKED DB. A UNLINKED DB cannot be loaded into work memory. The READ_DBL returns W#16#80B1.
• Confusing work memory, load memory, and retentive memory. Retentive memory preserves DB values through a power cycle only if the same DB instance remains. A recipe that has been written with WRIT_DBL is preserved by the MC; a recipe that has not been written is lost.

FAQ