Configuring Direct Data Exchange S7-400 to IM151-7 PROFIBUS

Overview: Direct Data Exchange Between S7-400 and IM151-7

Direct Data Exchange (often labeled DX, internode communication, or cross-traffic) is a PROFIBUS-DP operating mode in which a DP slave publishes selected input/output slots to a peer DP master without the master having to read them through a separate service. The mechanism is defined in the PROFIBUS-DP specification (EN 50170 / IEC 61158) and is implemented in SIMATIC controllers as the "Publish/Subscribe" or "Direct Data Exchange" link type in HW Config / TIA Portal.

In the typical configuration described in field practice, a SIMATIC S7-400 (e.g. CPU 414-3, CPU 416-3, CPU 417-4) acts as the PROFIBUS-DP master class 1 and the ET 200S CPU IM151-7 (6ES7151-7AA20-0AB0 or 6ES7151-7AB00-0AB0, depending on firmware level) acts as an I-slave that both consumes and publishes data with the S7-400. The two CPUs exchange alarms, status, interlock bits, and process data such as counters and analog values.

The question raised by integrators working with this topology is sharp and field-relevant: when the PROFIBUS segment between the S7-400 and the IM151-7 fails (cable break, connector pulled, slave powered down, master STOP/HOLD), what happens to the data that has been exchanged? The answer is not a single behavior; it depends on the slot configuration, the CPU operating mode, and the substitute-value strategy selected in STEP 7 or TIA Portal.

Hardware and Firmware Compatibility

Direct Data Exchange is supported only by SIMATIC modules that can act as DP slave (I-slave) and that expose the published slots to peer masters. The Siemens Support entry 17660809 lists every compatible module. The relevant subset for an S7-400 ↔ IM151-7 link is:

The IM151-7 must be configured as a DP slave with I-slave capability; the standard IM151-1 head module cannot publish. The S7-400 must be on PROFIBUS-DP master class 1 mode; S7-300 masters of class 2 cannot subscribe to the IM151-7 publication in this link.

For new projects, Siemens recommends moving to PROFINET IO with IRT, where the equivalent function is configured as Direct Data Exchange between S7-1500 CPUs in TIA Portal V16 or higher. The PROFIBUS path described here is the supported option for S7-400 + IM151-7 pairings and for migration projects where an installed bus already exists.

Configuring Direct Data Exchange in STEP 7 V5.x

For S7-400 paired with IM151-7 the typical engineering tool is STEP 7 V5.5 SP4 / SP5 (or STEP 7 Professional 2017 with the S7-400 add-on). TIA Portal V20 documents the same mechanism in Configuring direct data exchange (S7-300, S7-400, S7-1500), but field practice in brownfield sites still relies on HW Config. The required steps are:

1. In HW Config, insert the IM151-7 as a DP slave on the S7-400 PROFIBUS subnet. Open the IM151-7 object properties and enable DP-Slave mode and check "Activate direct data exchange" (German: "Querverkehr", English: "Direct Data Exchange").
2. Define the transfer areas on the IM151-7 side. Each area specifies a slot (input or output), a length (bytes), a consistency setting, and a slot name. Typical widths: 1 byte for status/interlocks, 4 bytes for a 32-bit counter, 8 bytes for two REAL analog values.
3. For each transfer area that is to be published to the S7-400, set the direction to Input on the IM151-7 and enable the option "Slave-to-slave communication" in the area properties. The area becomes visible to the S7-400 master as a published slot.
4. For each transfer area that the S7-400 master will subscribe from, the S7-400 station must insert the IM151-7 as a peer and add a matching input area whose source points to the IM151-7 transfer area. STEP 7 automatically creates a DB or an I/O address range on the S7-400.
5. Compile and download to the S7-400 first, then to the IM151-7. On startup the master reads the DX configuration and establishes the publisher/subscriber links.

Fail-State Behavior of the Exchanged Data

The crucial question — do exchanged inputs and outputs hold their last value, substitute a configured value, or fall to 0 — is governed by three independent configuration switches. The behavior is not a property of the wire or the protocol; it is a property of how each CPU manages the slots during a DP station failure.

Inputs on the S7-400 (data published by the IM151-7)

When the PROFIBUS link to the IM151-7 fails, the S7-400 stops receiving updated telegrams. The I/O area mapped to the published slots will:

• Freeze the last valid value in the process image (PII) if the slots are accessed as peripheral inputs and the S7-400 CPU is configured for OB85 behavior = ignore and the S7-400 remains in RUN.
• Be re-initialized to 0 at the moment the slave is removed from the bus if OB85 is enabled (default in newer CPU firmware) and the PII is read directly via L PIB / L PID without SFC14/SFC15.
• Be filled with the configured substitute value (any byte pattern) if the slot is read with SFC14 ("DPRD_DAT") and the call is wrapped in a wrapper block that supervises the return code.

The S7-400 does not automatically zero published inputs on link loss. Holding the last value is the default for process image reads; zeroing only happens when the application reads the slot directly through SFC14 and the SFC returns a fault.

Outputs on the IM151-7 (data written by the S7-400)

The IM151-7 behavior is configured in HW Config on the IM151-7 object, tab "DP-Slave Properties" → "Operating Mode". Three options exist:

The fail-safe window is set in the DP slave properties of the IM151-7, default 100 ms, range 10 ms to 650 s. If the IM151-7 does not receive a new I/O telegram from the S7-400 within that window, the configured substitute behavior activates.

Outputs to the S7-400 (data published back from the S7-400 to the IM151-7)

The reverse direction behaves symmetrically. The IM151-7 side will see the S7-400's published outputs freeze at the last value or zero depending on the IM151-7's DP-slave configuration.

Diagnostic Organization Blocks for Link Supervision

Knowing the configured behavior is necessary but not sufficient. The application must observe the link state to interpret the data correctly. STEP 7 provides four OBs that fire on PROFIBUS events. All four are required to build a complete picture of link health.

A minimal but effective supervisor is OB86. Inside OB86, the event entry OB86_EV_CLASS, OB86_FLT_ID, and OB86_DP_FAULT_ID identify whether the failure is on entering (B#16#39) or leaving (B#16#38) and whether the failure affects a DP slave (B#16#C4) or a PROFINET station. The following STL snippet, valid for S7-400 with classic STEP 7, demonstrates a counter that the IM151-7 can read to confirm link presence:

// OB86 in the S7-400
// Local flags
DATA_BLOCK DB100
  STRUCT
    link_ok : BOOL;     // TRUE while IM151-7 is reachable
    lost_count : DWORD; // increments on each OB86 enter event
  END_STRUCT
END_DATA_BLOCK

FUNCTION_BLOCK FB100 "LinkSupervisor"
VAR
  cntLost : DWORD;
  cntBack : DWORD;
END_VAR
BEGIN
  // called from OB1 each cycle
  // heartbeat logic here
END_FUNCTION_BLOCK

// OB86 (rising event)
L     B#16#39                    // entering event
L     #OB86_EV_CLASS
==I
JC    _lost
L     B#16#38                    // leaving event
L     #OB86_EV_CLASS
==I
JC    _back
BE

_lost:
  L     #OB86_DP_FAULT_ID
  L     W#16#C4                  // DP-Slave failure
  ==I
  JC    _lostSlave
  BE
_lostSlave:
  L     #OB86_RESERVED_1         // contains DP station number
  T     MW 200
  SET
  R     DB100.DBX0.0             // link_ok = FALSE
  L     DB100.DBD2
  +     1
  T     DB100.DBD2               // lost_count++
  BE

_back:
  L     #OB86_RESERVED_1
  T     MW 202
  SET
  S     DB100.DBX0.0             // link_ok = TRUE
  L     DB100.DBD6
  +     1
  T     DB100.DBD6               // back_count++
END_ORGANIZATION_BLOCK

The same DB100 symbol can be added to the published transfer area from the S7-400 to the IM151-7. The IM151-7 reads the counter, and a counter that has stopped incrementing is direct evidence of link loss, exactly the technique field-proven in the original case.

Implementing Substitute Value Strategies

Choosing between hold last value, substitute 0, and configured replacement is a design decision driven by the controlled process. The two following patterns are the ones most commonly used in plants that combine S7-400 master and IM151-7.

Pattern A — Hold Last Value (Fail-Safe Freeze)

Use this for interlocking bits and analog setpoints that drive slowly-moving equipment (heaters, conveyors, level control). The system continues in the last commanded state. In HW Config on the IM151-7 object, set Output substitute value = last value. Pair the slot with OB86 in the S7-400 to avoid STOP, and add a watchdog in the S7-400 that writes a "heartbeat" pattern to a reserved byte of the published area. If the S7-400 itself enters STOP, the IM151-7 will see no new heartbeat and force the substitute value within the fail-safe window.

Pattern B — Forced Safe State (Go-Home)

Use this for safety-class actuators (valves, brakes, robot enable) that must move to a defined state on any loss of communication. Configure the IM151-7 with Output substitute value = 0 or a configured replacement pattern. The fail-safe window should be tightened to the smallest acceptable value (typically 20–50 ms) so the actuator moves quickly. Add a periodic confirmation to the S7-400 that the link is alive; if the confirmation fails for three cycles, treat the data as invalid regardless of the held value.

Pattern C — Application-Level Substitution

Use SFC14 ("DPRD_DAT") and SFC15 ("DPWR_DAT") on the S7-400 side to read/write the published areas with explicit consistency. The return code RET_VAL is 0 on success and a W#16#80xx error on failure. The application can then drive the consumer variables with a substitute value computed from local context (e.g. last good value, filtered average, or ramped target). This pattern is the most flexible and the one recommended for any new project using TIA Portal V16+:

// S7-400 SCL, TIA Portal V20, reading 4 bytes from IM151-7 publication
// Input area: I100..I103 (published by IM151-7)
// Output area: Q200..Q203 (subscribed by IM151-7)

FUNCTION "dxBlock" : VOID
VAR
  retValRead : WORD;
  retValWrite : WORD;
  publishedInput : DWORD;     // status, counter, etc.
  outputToSlave : DWORD;      // command, setpoint, etc.
  linkOk : BOOL;
END_VAR
BEGIN
  // Read the published input with consistency check
  retValRead := DPRD_DAT(LADDR := W#16#64, RECORD := publishedInput);
  // LADDR = 100 decimal = 0x64
  
  IF retValRead = W#16#0 THEN
    linkOk := TRUE;
  ELSE
    linkOk := FALSE;
    publishedInput := 16#DEADBEEF;  // sentinel value
  END_IF;
  
  // Write to the IM151-7 if link OK, otherwise force substitute
  IF linkOk THEN
    retValWrite := DPWR_DAT(LADDR := W#16#C8, RECORD := outputToSlave);
  ELSE
    outputToSlave := 16#00000000;   // safe state
    retValWrite := DPWR_DAT(LADDR := W#16#C8, RECORD := outputToSlave);
  END_IF;
END_FUNCTION

Counter-Based Link Supervision on the IM151-7

The IM151-7 itself can be configured to publish an internal counter to the S7-400 and to subscribe to a counter published by the S7-400. The supervision principle is straightforward: an incrementing counter proves both the publisher and the consumer are alive and the data path is intact. field reports used this technique to detect breaks from both ends.

Implementation steps:

1. Declare a 32-bit counter cnt_local in a DB on each CPU.
2. Add the counter to the transfer area published by the IM151-7 to the S7-400 (4 bytes, consistency "Total length").
3. Add a separate counter published by the S7-400 to the IM151-7 in the reverse transfer area.
4. In OB1 of each CPU, increment the local counter by 1 each cycle, wrap on overflow.
5. On the consumer side, run a check that the subscribed counter changes within a time window (e.g. 5 OB1 cycles). If it does not change, set a link_fail flag and trigger the substitute value logic.

The counter approach is preferred over relying on OB86 alone because OB86 reports the bus state from the master's view only, while a frozen counter proves end-to-end data freshness.

Verification and Commissioning Tests

Before declaring the link production-ready, perform the following checks. Each test is designed to expose one of the three failure modes described above.

Document the observed timing in the FAT/SAT protocol. The fail-safe window of 100 ms is the S7 default but is configurable to as low as 10 ms in HW Config when the application demands faster reaction.

Common Pitfalls and Field-Proven Caveats

Migrating to PROFINET IRT Direct Data Exchange

For new designs Siemens now recommends PROFINET IO with IRT and the equivalent "Direct Data Exchange" mechanism. The configuration in TIA Portal V20 for S7-1500 requires STEP 7 V16 or higher, but the conceptual model — publisher, subscriber, transfer areas with consistency settings, substitute values, and OB82/OB86 diagnostics — is identical to the PROFIBUS version described above. The TIA Portal direct data exchange configuration guide documents the procedure in detail. Existing S7-400 + IM151-7 sites can be migrated by replacing the IM151-7 with an IM151-7 PN (6ES7151-7BA00-0AB0) and configuring the publisher/subscriber relation as a PN IO device relation.