Reducing SFB14 GET Error Detection Time on S7-400 to ET200S IM151-F Partners

An S7-400 CPU acting as the S7 communication initiator using SFB14 "GET" and SFB15 "PUT" to read/write the process image of distributed ET 200S IM151-F stations will typically report a partner failure within 8 to 12 seconds after the remote station is de-energized. For most process applications this is acceptable, but for safety-related shutdowns, high-speed interlocking, and machine tooling with hard stop times under one second, the 10 s default is unusable.

This reference explains the layered timeout stack that produces the 10 s delay, decodes the SFB14/SFB15 STATUS word, and provides four independent methods to reduce detection time down to 1 s or below. All methods can be applied independently or combined.

1. System Topology and Components

The standard configuration that produces the 10 s symptom is:

• Initiator: SIMATIC S7-400 (CPU 414, 416, 417, or 418), with firmware V5.x or V6.x. The CPU's integrated PROFINET interface or a CP 443-1 / CP 443-1 Advanced handles the Ethernet connection.
• Partner: ET 200S station with IM 151-1 STANDARD, IM 151-1 HF, or IM 151-F (fail-safe) interface module and an S7-CPU as the head of the station.
• Connection type: S7 connection (configured in NetPro or TIA Portal Devices & Networks), ISO-on-TCP (port 102, RFC1006) on Industrial Ethernet / PROFINET.
• Function blocks: SFB14 "GET" (read partner data) and SFB15 "PUT" (write partner data) called cyclically from OB1. Both blocks are part of the standard library and have been documented since STEP 7 V5.x. See the SFB14/FB14 GET function description in the Siemens Industry Online Support.

1.1 Why a powered-off partner is a special case

When the IM151-F is de-energized, the link does not go down gracefully. The station stops transmitting immediately, but the electrical link (port LEDs, switch fabric) on the partner side may remain lit for several seconds until the PHY detects loss of carrier. The TCP connection at the initiator's CP is therefore in an unconfirmed state, not a closed state. The initiator must use a timeout to declare the connection broken.

2. Root Cause: The 10 s Delay Is the TCP Retransmission Sequence

The 10 s is not a single timer; it is the sum of three layers:

The observed 10 s typically matches the TCP retransmission sequence. When the initiator CP sends an S7 PDU and receives no acknowledgment (because the partner is off), RFC 6298 governs the retransmission timer:

1. First retransmit after RTO = 1 s.
2. Second retransmit at 2 s.
3. Third retransmit at 4 s.
4. Fourth retransmit at 8 s.
5. TCP gives up after 4-5 retransmissions, connection declared broken.

The S7 protocol layer above TCP then sets the connection to DOWN, the CP clears the connection resources, and only then does the next call to SFB14 return ERROR=1 with a non-zero STATUS. The SFB itself does not contain an internal watchdog - it relies entirely on the underlying connection state.

3. SFB14 / SFB15 STATUS Word Decoding

When ERROR=1, the STATUS output is one of the values listed below. The first two bytes are the SFB-internal error class; the second two bytes identify the specific cause.

For the powered-off partner case, the dominant value is W#16#0001. Capture the lower byte sequence in OB82 (diagnostic interrupt) and OB87 (communication error) for full diagnostics. The Siemens Communication with S7-300/400 manual contains the full STATUS table including the sub-codes for transport-level errors.

4. Method 1 — Reduce the S7 Connection Monitoring Time

This is the simplest change and produces the largest improvement. The S7 connection itself supports a "monitoring time" (T_mon) parameter that is independent of the TCP retransmission. When T_mon elapses without any successful S7 PDU exchange, the S7 layer on the CP forcibly tears down the connection and signals the application.

4.1 STEP 7 V5.x (NetPro)

1. Open the S7 project in SIMATIC Manager.
2. Open NetPro (Options > Configure Network).
3. Select the S7 connection from the S7-400 CPU to the IM151-F CPU.
4. Open Properties > Special Connection Properties.
5. Under "Establishment and monitoring of the connection", set Monitoring time = 1 s (minimum is 1 s; below 1 s is not allowed by NetPro).
6. Save, compile, and download HW Config + NetPro to the S7-400 CPU.

4.2 TIA Portal

1. Open Devices & Networks.
2. Select the S7 connection in the network view.
3. Open Properties > General > Connection mechanisms (or Keep-alive function on newer TIA versions).
4. Set Monitoring time = 1000 ms.
5. Compile and download.

5. Method 2 — TCP Keep-Alive Interval Tuning

The TCP keep-alive mechanism is a separate, optional timer. It is normally disabled for S7 communication because Siemens designed the S7 monitoring time to handle the failure case. If you enable it with a short interval, the CP will send an empty TCP ACK probe every N seconds. If no response is received, TCP declares the connection broken after a small number of probes and frees the socket.

5.1 CP 443-1 Advanced Configuration (STEP 7 V5.x)

1. Open HW Config for the S7-400 station.
2. Open the CP 443-1 properties > Options tab > Keep-alive.
3. Set Send keep-alive packets every = 5 s and Maximum number of retries = 3.
4. This produces worst-case detection in 5 + 5 + 5 = 15 s, which is actually slower than the default. For a faster result, set 2 s / 2 retries = 4-6 s detection. Below 2 s the CP rejects the value.

5.2 Why TCP keep-alive is usually the wrong tool

TCP keep-alive adds extra traffic and does not speed detection much because the timeouts are conservative. Use it only when the S7 monitoring time cannot be shortened (e.g. legacy connection that other systems depend on) and the keep-alive packets can be tolerated on the network.

6. Method 3 — Application-Level Watchdog on SFB14

This is the most flexible approach and the only one that gives sub-second detection. The watchdog tracks the timestamp of the last successful SFB14 call; if the elapsed time exceeds a configurable threshold, the watchdog declares the partner unreachable regardless of what the SFB says.

6.1 SCL implementation (TIA Portal / S7-400)

FUNCTION_BLOCK "FB_PartnerWatchdog"
{ S7_Optimized_Access := 'FALSE' }
VERSION : 0.1
   VAR_INPUT
      i_Enable       : BOOL;    // TRUE while SFB14 is being called
      i_SFB14_Done   : BOOL;    // NDR from SFB14
      i_SFB14_Error  : BOOL;    // ERROR from SFB14
      i_StatusOK     : WORD;    // STATUS = W#16#0000 (success)
      i_Timeout      : TIME;    // e.g. T#1s
      i_CycleTime    : TIME;    // OB1 cycle, e.g. T#50ms
   END_VAR
   VAR_OUTPUT
      q_PartnerOK    : BOOL;    // TRUE if partner has answered within i_Timeout
      q_TimeoutFlag  : BOOL;    // TRUE one cycle after timeout
      q_Elapsed      : TIME;    // time since last successful response
   END_VAR
   VAR
      s_Elapsed      : TIME;
      s_TOF          : BOOL;
   END_VAR
BEGIN
   IF i_Enable THEN
      // Reset on successful response
      IF i_SFB14_Done AND (i_StatusOK = W#16#0000) THEN
         s_Elapsed := T#0s;
         s_TOF     := FALSE;
      ELSE
         s_Elapsed := s_Elapsed + i_CycleTime;
      END_IF;

      // Timeout detection with TOF for one-cycle pulse
      q_Elapsed     := s_Elapsed;
      q_TimeoutFlag := s_Elapsed > i_Timeout;
      q_PartnerOK   := (s_Elapsed <= i_Timeout) AND (NOT i_SFB14_Error);
   ELSE
      q_PartnerOK   := FALSE;
      q_TimeoutFlag := FALSE;
      q_Elapsed     := T#0s;
      s_Elapsed     := T#0s;
   END_IF;
END_FUNCTION_BLOCK;

6.2 STL equivalent (STEP 7 V5.x)

// Instance DB must contain s_Elapsed as TIME and s_TOF as BOOL
      L     #i_Enable
      JC    WDON
      // Disable branch
      T     #q_PartnerOK     // FALSE
      R     #q_TimeoutFlag
      L     #t#0s
      T     #s_Elapsed
      JU    WDEND
WDON: L     #i_SFB14_Done
      L     #i_StatusOK
      <>I                      // SUCCESS = DONE and STATUS=0
      JCN   WDEL
      L     #t#0s              // reset on success
      T     #s_Elapsed
      R     #s_TOF
      JU    WDCHK
WDEL: L     #s_Elapsed
      L     #i_CycleTime
      +D
      T     #s_Elapsed
WDCHK:L     #s_Elapsed
      L     #i_Timeout
      >D
      =     #q_TimeoutFlag
      NOT
      AN    #i_SFB14_Error
      =     #q_PartnerOK
WDEND: NOP   0

6.3 Wiring in OB1

CALL  SFB14, DB14   // GET - existing call
 REQ  := TRUE
 ID   := W#16#1     // connection ID from NetPro
 LEN  := 20
 DONE := NDR14
 BUSY := BUSY14
 ERROR:= ERR14
 STATUS:= STAT14
 RD_I  := P#DB20.DBX0.0 BYTE 20

// Watchdog instance
CALL  FB_PartnerWatchdog, DB100
 i_Enable      := TRUE
 i_SFB14_Done  := NDR14
 i_SFB14_Error := ERR14
 i_StatusOK    := STAT14
 i_Timeout     := T#1s
 i_CycleTime   := T#50ms
 q_PartnerOK   := "DB_Auto".PartnerOK
 q_TimeoutFlag := "DB_Auto".PartnerLostPulse
 q_Elapsed     := "DB_Auto".Elapsed

With the watchdog set to 1 s and OB1 at 50 ms, the application will declare the IM151-F unreachable after approximately 20 OB1 cycles have passed without a successful SFB14 NDR. The detection is bounded by i_Timeout, independent of the TCP retransmission sequence.

7. Method 4 — Replace SFB14/15 with SFB12 BSEND / SFB13 BRCV

The SFB12 "BSEND" and SFB13 "BRCV" blocks perform a different kind of S7 communication: they send and receive segmented, acknowledged data blocks. Crucially, the application can configure the send/receive timeout independently of the S7 monitoring time.

BSEND/BRCV require a partner program on the IM151-F CPU and do not access its process image directly, so they are not a drop-in replacement. They are useful when the S7 monitoring time is the limiting factor and you need detection faster than 1 s.

8. Choosing a Method

9. Verification — Confirm the New Detection Time

After applying the changes, verify the new detection time on a live system with a controlled power-off of the IM151-F.

1. Connect STEP 7 / TIA to the S7-400 online.
2. Open the SFB14 instance DB in the watch table (VAT) and add columns for NDR, ERROR, STATUS, and a sweep timestamp.
3. Set the watch table trigger to Continuous and 200 ms update.
4. Add the watchdog instance outputs to the same table.
5. Press record (Start Logging).
6. Power off the IM151-F station at the 24 V supply (do not unplug the PROFINET cable; that tests a different fault).
7. Note the wall-clock time between power-off and the first cycle where q_TimeoutFlag rises (or, without the watchdog, the first cycle where ERROR=1 with STATUS=W#16#0001).
8. Repeat three times and average. Target detection time should be at or below the chosen i_Timeout value (or 1 s if only Method 1 was applied).

9.1 Test cases to include in the same session

• Power-off IM151-F with 24 V removed. Tests the original symptom.
• Pull the PROFINET cable from the IM151-F port. Tests link-down detection only (typically 2-3 s, faster than power-off).
• Stop the IM151-F CPU (MRES or STOP switch). Tests graceful shutdown - detection is much faster, ~50-200 ms, because the CPU sends a STOP announcement.
• Disconnect the Ethernet switch upstream of the S7-400 CP. Tests network partition - SFB14 detection will be similar to power-off, ~10 s without the watchdog.

10. Troubleshooting Matrix

11. Safety Considerations for IM151-F Stations

If the partner is an IM 151-F with F-CPU functionality, the 10 s SFB14 detection is not the safety-relevant detection path. The fail-safe PROFIsafe communication runs on a separate channel with its own watchdog, typically 100-500 ms. SFB14 over the S7 connection is a non-safety read path. Do not replace PROFIsafe with S7 GET, even with sub-second detection. The SFB14 watchdog should be used for process interlocks, not for SIL-rated safety functions.

12. Document References

• SIMATIC S7-400 Automation System System Manual
• SFB14 / FB14 GET function description
• Communication with SIMATIC S7-300/400
• ET 200S Distributed I/O System Manual
• SFB12 BSEND / SFB13 BRCV description