Resolving SFB 14/15 Multi-Instance Calling Failures in Siemens S7-300/400

When an SFB 14 (GET) or SFB 15 (PUT) call is encapsulated inside a user Function Block (FB) and that FB is invoked more than once in OB1, engineers frequently encounter silent data corruption, stuck REQ flags, or RET_VAL error codes such as W#16#80C3 and W#16#80D0. The root cause is rarely the SFB itself; it is the surrounding FB's instance-data model and the configured S7 connection count in NetPro. This reference explains the underlying mechanics, separates the three independent failure modes, and provides a verified working pattern for production code.

1. Problem Description

Typical symptom report from the field:

• One PUT call in OB1 writes data correctly to the partner PLC.
• Two GET calls in OB1 (read from two different partners or two different data areas) deliver only the first area; the second call copies stale bytes or zero bytes.
• When the engineer creates two separate FBs (e.g., FB 100 and FB 401) — each containing its own copy of SFB 14 — both GET calls work simultaneously.
• STATUS output of the second SFB 14 returns W#16#80C3 (resource problem – no free connection resource) or the block never sets NDR/ERROR after REQ.

Encapsulation inside a user FB is the recommended pattern because it hides the ANY-pointer construction, the ID parameter, and the handshake bits behind a clean function-call interface. The same FB is meant to be re-used with different ADDR, SD and connection parameters at each call site. The failure pattern is therefore logical: a single FB re-used twice is a multi-instance problem, not a code-bug problem.

2. Root Cause Analysis – Three Independent Failure Modes

Three distinct issues must be addressed independently. Conflating them is the most common reason engineers spend hours debugging.

2.1 Failure Mode A – Single Instance DB Used by Both Calls

If the user FB is declared with its own Instance DB (e.g., DB 100) and the FB is called twice in OB1, STEP 7 only allocates one set of static variables unless multi-instance capability is enabled. Both calls write to the same ADDR_TMP, SD_TMP, REQ and ID locations. The second call therefore overwrites the first call's parameters before SFB 14 has completed its handshake, and the SFB reads corrupted ANY pointers when the cyclic OB1 tick returns.

The symptom is intermittent because it depends on OB1 scan time versus the SFB 14/15 background execution window (SFB 14/15 are asynchronous system blocks; they do not complete in one OB1 cycle). See the S7-300/400 System and Standard Functions manual: Siemens – System Software for S7-300/400 System and Standard Functions.

2.2 Failure Mode B – Mixed STL and LAD/FBD in the Same FB

When an ANY-pointer is constructed in STL inside an FB, the editor may bind the ADDR ANY to the local bit L 0.0. Because the TEMP area is shared with the editor's own ADDR_TMP scratch, the SFB 14 call's ADDR input can be partially overwritten when subsequent networks in the same FB run. Once the FB is re-opened and the view is changed back to LAD/FBD, the SFB 14/15 call is rendered in STL because the symbol it refers to is no longer resolvable in the graphical view.

This is a STEP 7 editor binding bug, not a CPU fault. The fix is structural: rebuild the network in LAD or FBD from scratch after any STL-only network has been removed.

2.3 Failure Mode C – Only One Configured S7 Connection per GET/PUT Pair

SFB 14/15 execute over a configured S7 connection in NetPro (or the connection table in the CPU's hardware configuration). A single configured connection supports exactly one SFB 14 or one SFB 15 at a time per CPU. To run two concurrent GET calls to different partners, or two GET calls to the same partner on different data areas, you must configure two S7 connections in NetPro and pass the matching ID to each FB call.

The CPU has its own limits. For an S7-300 CPU the number of S7 connections for communication is documented in the FAQ "How many connections and communication jobs do SIMATIC S7-300 and S7-400 support simultaneously?" (see Siemens KB 15364475). Typical values: S7-300 supports up to 16 S7 connections total (with PG/OP/HMI consuming some); S7-400 supports up to 64.

3. Architectural Decision – Multi-Instance vs. Separate Instance DBs

There are two valid patterns for invoking an FB containing SFB 14/15 more than once:

Multi-instance is the canonical Siemens pattern: SFB 14/15 themselves support multi-instance calls per the System and Standard Functions reference manual. The SFBs were designed to be embedded as multi-instances; the user FB that wraps them inherits the same capability.

4. Step-by-Step Solution

4.1 Prerequisites

1. STEP 7 V5.5 SP2 or later (or compatible TIA Portal project, but SFB 14/15 are STEP 7 V5.x constructs).
2. CPU with firmware that includes SFB 14/15: S7-300 CPU 31x ≥ V2.0, all S7-400 CPUs, WinAC RTX.
3. NetPro open with the S7-300 station and at least one S7 connection configured to the partner CPU.

4.2 Configure Two S7 Connections in NetPro

1. Open SIMATIC Manager → Options → NetPro.
2. Select the local S7-300 station in the network view.
3. Right-click the CPU → Insert New Connection.
4. Choose partner CPU and connection type "S7 connection".
5. Repeat to create a second connection. Note the local ID of each (e.g., W#16#0001 and W#16#0002).
6. Compile and download the connection configuration (NetPro → PLC → Download → Connection Configuration).

4.3 Rebuild the Wrapping FB in LAD/FBD Only

1. Open the FB that wraps SFB 14/15 (e.g., FB 100).
2. Delete the SFB call entirely.
3. Switch the view to LAD or FBD (do not mix STL in this FB).
4. Declare the FB interface with the following IN parameters: REQ (BOOL), ID (WORD), ADDR_1 (ANY in IN_OUT), RD_1 (ANY in IN_OUT), plus the data-width and offset values required to build the ANY pointer if you are not using symbolic ANY.
5. Add the SFB 14/15 call from the library; bind the ID input to the FB's ID IN parameter (do not hard-code).
6. Compile the FB. The editor will now create proper TEMP variables (ADDR_TMP, RD_TMP) that do not overlap the bit-addressable L-stack.

4.4 Declare the FB as Multi-Instance Capable

1. Open the FB's properties → Attributes tab.
2. Check Multi-instance capable (Standard: "MCFM" – Multi-instance Capable Function Module).
3. Save and close.

Reference: Siemens – Multi-Instances in STEP 7.

4.5 Invoke the FB Multiple Times

Pattern A – calls in OB1 (top-level):

// OB1 – Network 4
CALL "S7_GET_PUT"), DB100   // First SFB 14 call
   REQ   := M 10.0
   ID    := W#16#1           // Connection 1
   ADDR_1:= P#DB20.DBX 0.0 BYTE 100
   RD_1  := P#DB30.DBX 0.0 BYTE 100
   NDR   := M 10.1
   ERROR := M 10.2
   STATUS:= MW 12
   RET_VAL:= MW 14

// OB1 – Network 5
CALL "S7_GET_PUT", DB101   // Second SFB 14 call – own IDB
   REQ   := M 20.0
   ID    := W#16#2           // Connection 2 (different NetPro connection)
   ADDR_1:= P#DB21.DBX 0.0 BYTE 50
   RD_1  := P#DB31.DBX 0.0 BYTE 50
   NDR   := M 20.1
   ERROR := M 20.2
   STATUS:= MW 22
   RET_VAL:= MW 24

Pattern B – calls in a parent FB as multi-instances:

// FB 9000 – STAT section
   STAT
      GET_1 : "S7_GET_PUT";   // First instance
      GET_2 : "S7_GET_PUT";   // Second instance

// FB 9000 – NW 4
   CALL GET_1
      REQ   := M 10.0
      ID    := W#16#1
      ADDR_1:= P#DB20.DBX 0.0 BYTE 100
      RD_1  := P#DB30.DBX 0.0 BYTE 100
      NDR   := M 10.1
      ERROR := M 10.2
      STATUS:= MW 12
      RET_VAL:= MW 14

// FB 9000 – NW 5
   CALL GET_2
      REQ   := M 20.0
      ID    := W#16#2
      ADDR_1:= P#DB21.DBX 0.0 BYTE 50
      RD_1  := P#DB31.DBX 0.0 BYTE 50
      NDR   := M 20.1
      ERROR := M 20.2
      STATUS:= MW 22
      RET_VAL:= MW 24

5. Common SFB 14/15 RET_VAL and STATUS Codes

Full code list: Siemens KB 26483647 – SFB14/15 GET/PUT error codes.

6. Verification Procedure

1. Download the FB, the new IDB(s), and the updated NetPro connection configuration to the CPU. Run the CPU in RUN-P.
2. Open Monitor/Modify on the SFB 14 instance. Trigger REQ with a one-shot rising edge (e.g., from a positive-edge flag or a one-second clock bit).
3. Confirm STATUS transitions from W#16#7000 to W#16#7001 to W#16#0000 within 1–3 OB1 cycles (the SFB 14 background runs on the CPU's communication scheduler, not synchronously with OB1).
4. Confirm NDR = TRUE for one cycle after completion; verify the destination DB contains the expected bytes.
5. Repeat for the second SFB 14 instance. Verify both NDR flags rise independently and the destination areas receive distinct data.
6. Disconnect the partner (pull the Profinet cable or stop the partner CPU) and observe ERROR = TRUE with RET_VAL = W#16#80D0 or W#16#80D4 within the configured retry time.
7. Restore the connection and confirm the next valid REQ produces NDR and zero RET_VAL.

7. Troubleshooting Matrix

8. Performance and Limits

SFB 14/15 are not real-time deterministic on Profinet/Profibus S7 connections. Typical observed throughput is 8–16 KB/s on a Profinet S7 connection and 4–8 KB/s on Profibus, depending on partner scan time and OB1 priority. For high-throughput or deterministic data exchange use the following alternatives:

• BSEND/BRCV (SFB 12/13) – up to 64 KB per call, requires partner to also use BSEND/BRCV.
• PUT/GET on S7-1200/1500 – modern equivalent; uses the open communication instructions in TIA Portal.
• Profinet I-Device or Profibus Slave I/O – for cyclic data exchange with hard real-time guarantees.

See the Communication Functions manual: Siemens – System Software for S7-300/400 System and Standard Functions.

9. Migration Notes for S7-1200/1500

On S7-1200/1500 the SFB 14/15 are replaced by the GET and PUT instructions found in the Instructions → Communication → S7 Communication palette. The same single-connection-per-call constraint applies: each GET/PUT block is bound to a connection in the device configuration, and one connection supports one active call. The connection is configured in Properties → Connection on each block, not in NetPro. The multi-instance pattern is the same: call the same FB multiple times in OB1 only if the FB is multi-instance capable and each call has its own static data area.

For projects migrating from STEP 7 V5.x to TIA Portal, the wrapped FB pattern is portable; the FB's interface stays the same, but the internal SFB 14/15 calls must be replaced with the TIA Portal equivalents. The error codes and handshake semantics are similar but not identical – re-test all STATUS decoding.

10. Field-Commissioning Checklist

1. Confirm the wrapping FB has Multi-instance capable set.
2. Confirm each call site has a unique ID parameter that maps to an existing NetPro S7 connection.
3. Confirm the count of concurrent SFB 14/15 calls does not exceed the CPU's communication-job limit (consult CPU datasheet).
4. Confirm REQ is edge-triggered, not level-triggered.
5. Confirm each SFB 14/15 call's destination/source length matches the partner's configured length exactly.
6. Confirm the partner DBs are not optimized (on S7-300/400, SFB 14/15 only work with standard (not optimized) DBs).
7. Confirm both stations' connection configuration is downloaded and the connection is established (LED or STATUS check in NetPro online view).
8. Run the verification procedure in Section 6; document baseline STATUS/RET_VAL values for trend monitoring.