Resolving Bumpless Communication Issues in S7-400H Redundants

Problem Definition: RCV_BO Blinking in S7-400H Redundant Setups

Engineers deploying Siemens S7-400H fault-tolerant stations with CP 443-5 Extended PROFIBUS interfaces and CP 443-1 Industrial Ethernet interfaces routinely report intermittent "blink" conditions on the received data areas (RCV_BO, F_RCVBO) when the redundant optical ring is disturbed. The symptom is triggered by a single physical event: disconnecting one fiber connector at an OLM (Optical Link Module), powering down a remote DP slave, or breaking one strand of a redundant Ethernet link. The blink appears on both standard S7 communication (BSEND / BRECV, FB 12 / FB 13) and on PROFIsafe safety communication (F_SENDBO / F_RCVBO, FB 13 / FB 14), and forces the F-CPU into a fail-safe state that stops the machine until the failure is acknowledged.

The blink is not a hardware fault of the CP modules. It is a telegram loss during the redundancy switchover window. The H-system does not buffer application-layer telegrams of every protocol family across the takeover; for protocols that are not explicitly released for H-redundancy, the user program must handle the gap explicitly.

Affected Hardware and Software Components

The configuration discussed in field reports uses the following Siemens components. Verify the order number and firmware version against the Siemens Industry Online Support manuals that match the exact device in your plant.

• H-CPU 417-4H (typical 6ES7 417-4HT14-0AB0 or later) in a fault-tolerant rack with two synchronized CPUs.
• CP 443-5 Extended (typical 6GK7 443-5DX04-0XE0 or 6GK7 443-5DX05-0XE0) for PROFIBUS DP master on each H-side.
• CP 443-1 (typical 6GK7 443-1EX20-0XE0 or 6GK7 443-1EX30-0XE0) for Industrial Ethernet on each H-side.
• OLM (Optical Link Module, e.g. 6GK1 502-3CB00 or 6GK1 503-3CB00) for redundant optical ring with two fiber strands.
• STEP 7 V5.5 or STEP 7 Professional 2010 / 2017 with the S7-H option pack for H-station configuration.
• Distributed Safety V5.4 SP5 or F-Failsafe option package for PROFIsafe programming with F_SENDBO / F_RCVBO.
• S7-300 / S7-400 F-CPUs (CPU 315F-2 DP, CPU 317F-2 PN/DP, CPU 416F-3 PN/DP) on the remote side terminating the PROFIsafe relationship.

Root Cause: Telegram Loss During Redundancy Switchover

An H-station performs a link-up / link-down event when a fiber strand is broken or a remote station drops. The active H-side continues to run, the standby H-side resynchronizes, and the application context is preserved at the CPU level. However, the CPs are network-interface devices, not stateful application-layer proxies. A telegram that was in flight on the failed link is dropped at the MAC layer; it is not re-transmitted by the CP, and it is not buffered for the F-runtime group.

Two distinct paths produce the blink:

1. Ethernet path (CP 443-1): Industrial Ethernet uses TCP, but BSEND / BRECV and the PROFIsafe F-services sit on top of S7-communication or PROFINET IO. The transport layer buffers within an open connection, but during a switchover of the H-master the connection is briefly torn down and re-established. The F-block sees RCV_BO = 0 or stale data for one cycle and signals an error to the F-runtime group.
2. PROFIBUS path (CP 443-5): PROFIBUS is a token-passing bus. If the active master is holding the token at the moment a slave is disconnected, the token is destroyed. The remaining masters time out (typically T_slot = 1,011 bit-times for DP-V1 at 1.5 Mbit/s, ≈ 0.67 ms per master × number of masters) and re-issue the token. During that gap, DP telegrams — including PROFIsafe F-telegrams — are lost.

The single most damaging scenario is the single shared PROFIBUS network with one master and several slaves. If the master loses the token because a slave on the same segment was de-energized or a stub was unplugged, the entire segment goes dark for the gap time, and the F-CPU registers a communication failure. The blink is therefore systematic in a single shared network; it cannot be eliminated by re-tuning T_slot alone.

S7-H Communication Architecture: What Is Released for Fault-Tolerant Systems

Siemens officially releases only the following communication types for use across the H-system's redundant link:

• S7 Communication with S7-H Connections (fault-tolerant S7 connections). Both partners know the redundant path and can survive a single link loss transparently. Used by PUT / GET (FB 14 / FB 15) and by BSEND / BRECV (FB 12 / FB 13) when the connection is configured as an S7-H connection in NetPro.
• PROFIBUS DP with the CP 443-5 acting as DP master on each H-side. The DP slave does not need to be aware of the H-redundancy; the redundant master pair is transparent at the DP layer.
• PROFINET IO with the CP 443-1 EX30 (or later) acting as PROFINET IO controller, with MRP (Media Redundancy Protocol) configured on the ring.

The following protocols are not released for transparent H-redundancy and require application-level handling of telegram loss:

• PROFIBUS FMS
• PROFIBUS FDL with SEND/RECV (AG_SEND / AG_RECV, FC 5 / FC 6)
• Industrial Ethernet Send/Receive with AG_SEND / AG_RECV (FC 5 / FC 6) on the ISO-on-TCP or TCP transport

For these non-released protocols, the application program must handle telegram loss explicitly. A typical pattern is to read the STATUS output of the send/receive block, detect W#16#0001 (no data) or W#16#8085 (timeout), and discard the cycle as invalid rather than acting on the stale buffer. Verify the released-protocol list against the current S7-400H fault-tolerant systems manual on Siemens Industry Online Support.

PROFIBUS Token Behavior and Single-Network Fragility

The PROFIBUS MAC layer is governed by IEC 61158 / IEC 61784. A master only relinquishes the token after transmitting its quota of high- and low-priority messages, and after a configurable idle time (T_id1, T_id2). If a slave that the master has just polled disappears, the master's gap time-out (T_slot) is exceeded, the master discards its token, and all remaining masters on the segment must wait for their time-out before re-issuing the token. The gap can be tens of milliseconds for a 1.5 Mbit/s segment with the default T_slot = 1,011 bit-times, and grows with the number of masters and the configured retries.

In a 417H system, both H-sides are PROFIBUS masters and therefore token holders. If one side loses the token because of a slave drop, the other side times out and the segment is briefly quiet. Any F-telegram in that window is lost. The blink is systematic in a single shared network; it cannot be eliminated by re-tuning T_slot alone, because the root cause is the destruction of the token itself, not a slow recovery.

To make the issue reproducible in a controlled test, power down a single DP slave on a single-segment network. Within 100 ms – 2 s (segment-size dependent), the F-CPU will report F-channel error on the affected PROFIsafe slot and passivate the corresponding F-I/O.

Application-Level Telegram Loss Handling for Non-Released Protocols

When a non-released protocol is in use, the F-program (or standard S7 program) must implement a state machine that treats each telegram as untrusted until proven otherwise. The minimum pattern is:

1. Call the receive block (F_RCVBO FB 14 or BRECV FB 13) with the safety or data DB as the receive area.
2. Evaluate the block's NDR (new data received), ERROR, and STATUS outputs.
3. If NDR = TRUE and STATUS = W#16#0000, commit the received values to the F-I/O DB and pulse a "valid" flag.
4. If ERROR = TRUE or STATUS <> W#16#0000 (notably W#16#0001 "No data yet" after a switchover window), hold the last good values for one extra cycle, then declare the relationship failed and passivate the F-I/O.
5. Acknowledge the failure with F_ACK (FB 186) only after the underlying CP link has recovered and two consecutive telegrams have been received with STATUS = W#16#0000.

Sample call of F_RCVBO in STL for a single PROFIsafe relationship:

CALL "F_RCVBO", "F_RDB_HMI"
  ID            := W#16#0001
  LADDR         := W#16#0000
  DB_F_RCV      := "F_RDB_HMI"
  DB_F_SEND     := "F_SDB_HMI"
  RECV_DATA     := "F_RCV_BO_1"
  SUBS_ON       := "F_SUBS_ON_1"
  SUBS_OFF      := "F_SUBS_OFF_1"
  ACK_REQ       := "F_ACK_REQ_1"
  ERROR         := "F_ERROR_1"
  STATUS        := "F_STATUS_1"

The relevant output bits for the application state machine are:

• SUBS_ON — TRUE when the F-CPU is in passivation; outputs are held at the safe value.
• SUBS_OFF — TRUE when the F-CPU has been reintegrated; outputs follow the process.
• ACK_REQ — TRUE when the F-CPU requires the operator to acknowledge the failure before reintegration.
• ERROR / STATUS — diagnostics; the STATUS word contains the F-error code from the PROFIsafe profile (e.g. W#16#0045 "CRC error", W#16#0060 "Watchdog timeout").

Solution 1: Two Physically Separate PROFIBUS Networks

The field-proven remedy for the single-network fragility is to build two physically separate PROFIBUS DP segments, one for each H-side of each PLC. The benefits are:

• If a cable is unplugged or a slave is de-energized on segment A, segment B continues to operate normally.
• The F-program on the H-station reads from both segments and selects the valid value with a 1-out-of-2 voter.
• The F-telegram loss is bounded to a single segment, and the H-station can suppress the passivation of the F-CPU on the affected side while the other side keeps the process running.

Wiring topology for the dual-segment approach:

• CP 443-5 (H-side 0, slot X) → segment A → DP slaves on rack A1, A2, A3.
• CP 443-5 (H-side 1, slot X) → segment B → the same DP slaves with their second PROFIBUS interface (redundant slave) on rack A1, A2, A3.
• Each DP slave is configured twice in HW Config (once on segment A, once on segment B) and its F-I/O is mapped into the same F-DB. The F-program decides which value to trust based on the SUBS_ON / SUBS_OFF status of each PROFIsafe relationship.

For DP slaves without a redundant interface (e.g. older ET 200S or third-party devices), use a redundant-slave Y-coupler or a Y-link to connect the slave to both segments. Siemens ET 200M stations with two IM 153-2 modules, and ET 200SP stations with two IM 155-6 DP HF modules, are typical examples that support this topology out of the box.

Solution 2: Fault-Tolerant S7 Connections (S7-H Connections)

For non-safety communication, configure the BSEND / BRECV blocks to use an S7-H connection (also called an S7 fault-tolerant connection). In NetPro, right-click the partner connection, choose Object Properties → Connection, and select S7 connection, fault-tolerant as the connection type. Both H-sides are entered, and STEP 7 generates the connection DB (CBD) automatically.

When the link on the active H-side fails, the connection is re-established through the standby H-side within the configured monitor time (default 30 s; reduce to 3 s for fast switchover). The user program sees no break in the BSEND / BRECV stream, provided both telegrams complete inside one monitor-time window. The monitor time must be greater than the H-system switchover time (≤ 200 ms for CPU 417-4H) plus the worst-case network reconfiguration time.

For PROFINET IO on the CP 443-1 EX30, enable MRP (Media Redundancy Protocol) on the ring. One CP is configured as the MRP manager; the other is the MRP client. Reconfiguration time on a 100 Mbit/s copper ring is typically ≤ 200 ms with default MRP parameters, and a brief loss of PROFINET IO is tolerated by the IO devices within their own watchdog time (configured per device, typically 3 × update time).

Configuration Steps in STEP 7 / HW Config

1. Insert the H-station in HW Config with two racks, one CPU 417-4H per rack, and a CP 443-1 plus a CP 443-5 in each rack.
2. In H-Parameters → Redundant CPs, enable Redundant CP 443-1 and Redundant CP 443-5 so the H-firmware monitors both links and the standby CP takes over within the configured monitor time.
3. For each CP, in Properties → Operating Mode, enable Activate CP for redundant operation and assign a unique CP index (0 for the primary, 1 for the standby).
4. Build two PROFIBUS subnets, not one. In NetPro, insert a second PROFIBUS subnet, assign the CP 443-5 of H-side 0 to subnet A and the CP 443-5 of H-side 1 to subnet B.
5. Insert the DP slaves on both subnets. For a redundant slave (e.g. ET 200M with two IM 153-2), use the GSD file that declares the redundant interface, and configure the slave's PROFIsafe destination address on both subnets.
6. Configure the F-I/O mapping in the F-CPU: each F-slot points to a PROFIsafe slot, and STEP 7 generates a separate PROFIsafe relationship for each segment. The two F-RDBs are independent; the user program must vote on the two received values.
7. Build the F-program with F_SENDBO / F_RCVBO (FB 13 / FB 14) and the passivation logic described above. Insert F_ACK (FB 186) in OB 100 or OB 1 to acknowledge the failure after recovery.
8. For non-safety communication, configure the S7 connections in NetPro as S7 connection, fault-tolerant. Compile and download the connection DBs.
9. Download the HW Config and the S7 program to both H-sides. Run H-Configuration → Download to synchronize the redundancy configuration.
10. Enable the MRP role on the CP 443-1 ring in PROFINET IO topology editor; designate one CP as MRP manager and the rest as MRP client.

Verification and Diagnostics

After commissioning, exercise the following failure modes and verify the behavior with the online diagnostics.

Open CP Diagnostics in STEP 7 (reachable via PLC → Module Information → Diagnostics Buffer) to read the link-up / link-down events. The CP 443-5 Extended writes F1 / F2 fault codes with timestamps; correlate them with the H-system event log (SF, CPU redundancy status) to identify the failing segment. Common CP 443-5 Extended diagnostic codes include:

• F1 = 0x00 / F2 = 0x01 — short circuit / open circuit on the bus segment.
• F1 = 0x0A / F2 = 0x02 — token error; another master is failing.
• F1 = 0x12 / F2 = 0x05 — slave failure or removed slave.

For a quantified passivation test, pull the fiber on segment A and observe F_RDB (the F-runtime group data block). The expected sequence is:

1. SUBS_ON rises to TRUE within 1 s of the disconnect.
2. The F-I/O DB QBAD bit rises to TRUE.
3. SUBS_OFF stays FALSE (the other side is still healthy).
4. The F-CPU remains in RUN; the process continues with the values from segment B.

For the Ethernet path, enable the S7-H connection monitor time and verify that BSEND / BRECV return W#16#0000 on both sides during a forced CP switchover. A 30 s default monitor time is too long for a fast process; reduce to 3 s and re-test the worst-case switchover.

Specifications, Limits, and Timing

The following values are derived from the S7-400H system family and the CP 443-1 / CP 443-5 Extended module manuals. Verify against the Siemens Industry Online Support manuals that match the order number and firmware version installed in your plant; the values below are typical, not guaranteed.

For broader Ethernet-redundancy context, see the ABB SA056 paper on bumpless Ethernet redundancy for IEC 61850 substations. The paper quantifies redundancy check intervals (under one minute for the full network) and discusses the role of the station operator / gateway in supervising the redundancy. The conceptual model — one active device supervising the redundant paths and a fast switchover to the standby — is the same pattern that the active H-CPU plays in a 417H system. For substation-grade bumpless behavior, the IEC 61850 approach uses PRP (Parallel Redundancy Protocol, IEC 62439-3) with two physically separate LANs, which is structurally identical to the dual-PROFIBUS approach recommended above for PROFIsafe.

Migration Note: S7-1500R/H as a Modern Alternative

For new projects, the S7-1500R/H family (CPU 1515R, CPU 1517H, CPU 1518HF) replaces the S7-400H with similar fault-tolerant behavior. The redundancy model is built into the CPU, and PROFINET IO with MRP is the primary redundant path. The CP 443-1 / CP 443-5 are replaced by the PROFINET interfaces on the CPU; an external CP 1543-1 can be added for additional S7 connections. The same engineering pattern applies: configure two PROFINET rings with MRP, use F_SEND / F_RCV (FB 15 / FB 16 in the S7-1500 F-library) for PROFIsafe, and acknowledge passivations with F_ACK (FB 186) after the link has recovered. The blink-on-switchover behavior is identical, but the reconfiguration time is typically shorter (≤ 200 ms with MRP) than the S7-400H PROFIBUS token recovery time.

FAQ