Bridging Profibus DP Communication Errors in Siemens S7 Systems

Overview of Profibus DP Communication Error Behavior

Intermittent Profibus DP communication faults lasting 0.5-3 seconds are a recurring field issue on Siemens S7-300, S7-400, and ET200 distributed I/O systems. These transient faults differ fundamentally from persistent bus failures: the network re-establishes itself within a single scan, but the CPU and slave diagnostics already log a bus failure, which can propagate into the process as a momentary loss of outputs or freeze of inputs.

A communication error in this context is the deviation between the expected token-passing cycle (Profibus DP token rotation time T_TR) and the actual cycle as measured by the master and the slaves. Sources include marginal shield grounding, mixed baud-rate segments, EMI from VFD cables routed in parallel, oxidized connector pins, repeater timing drift, and PLC scan-time overrun during cold-start or online programming sessions.

Two complementary strategies address this:

1. Root-cause mitigation: reduce the physical-layer noise floor so the bus never faults.
2. Fault bridging: configure the PLC so that faults shorter than a defined tolerance are absorbed by the application without spurious actuator movement.

This reference focuses on the second strategy, with the constraint that both inputs (frozen or zeroed on failure) and outputs (reset to safe state on failure) must be bridged symmetrically so the process does not see a one-cycle disturbance.

Slave-Side Watchdog Mechanism

Every Profibus DP slave (per IEC 61158 / IEC 61784) implements an internal watchdog timer. If the master fails to address the slave within the configured watchdog window, the slave autonomously forces its outputs to a safe state (zero/fail-safe) and raises the diagnostic bit station_non_existent = 1.

Siemens ET200S, ET200M, ET200pro, ET200iSP, and third-party DP slaves expose the watchdog time as the parameter "Watchdog" (units = 10 ms increments) in the slave's GSD file. The default value depends on the device:

Increasing the slave watchdog to 2000-3000 ms is the first lever: it prevents the slave from zeroing its outputs during a 1-second disturbance. Configure via HW Config → slave properties → DP-Slave Properties → Parameter Assignment → Watchdog (ms), or programmatically through SFC13 (DP_SRM_DG / DPWRREC) / SFC14 (DPRD_DAT) on a parameter-write slot.

Master-Side Error Handling via Diagnostic OBs

The S7 CPU reacts to a Profibus DP fault by calling one or more of the following organization blocks. Understanding which OB fires — and when — is the foundation of any bridging logic.

For transient Profibus faults, OB86 is the primary handler: it fires when a configured DP slave disappears from the bus and again when it returns. The startup information contains:

• OB86_FLT_ID: fault class (e.g. W#16#0C3A for DP-slave failure)
• OB86_RESERVED_1: logical base address of the affected DP slave
• OB86_RESERVED_2: diagnostics frame length
• OB86_RESERVED_3: identification (DP master system ID)
• OB86_MDL_ADDR: module logical address

If OB86 is not loaded into the CPU and the slave disappears, the S7-300/400 by default goes to STOP with SF LED lit and diagnostic buffer entry "OB86 not loaded". The first step of any bridging strategy is to load OB86 (and OB82/85/122) as empty or minimal OBs in the S7 program so the CPU stays in RUN during the transient.

Implementation: Watchdog Time + Diagnostic OB Bridging

The recommended two-layer approach for a 1-2 second disturbance is:

1. Set DP master bus parameters and slave watchdog to 2000-3000 ms so neither side forces the outputs to zero within the disturbance window.
2. Add application-level time-stamping on OB86 entry/exit so the process logic ignores the fault for a configurable bridging time (typically 2 × the worst observed disturbance).

Step 1 — Configure DP Master Bus Parameters

In HW Config select the DP master interface (e.g. CPU 315-2 DP / CPU 416-3 DP) and open Properties → DP Master System → Bus Parameters. The relevant fields:

The DP master watchdog is implicit in the bus-parameter calculation: T_WD = 10 × Watchdog parameter (in 10 ms units). A setting of 200 yields 2000 ms, meaning the slave tolerates up to 2 seconds of bus silence before forcing outputs to zero.

Step 2 — Load Diagnostic OBs

Create empty (or minimal-logic) versions of the four OBs in the S7 project:

• OB82 — leave empty or write a flag that latches a diagnostic pending state.
• OB85 — leave empty.
• OB86 — write the bridging timer logic shown below.
• OB122 — leave empty.

Programming: Bridging Timer Logic in S7

The bridge is a TON (on-delay timer) or an SFB3 instance, started on OB86 entry (slave gone) and held true for the bridging duration. During that window, the application reads last good input values and holds the last written output values.

STL Example — OB86 with Bridging Timer

// OB86 - Rack Failure OB
// Called when DP slave disappears (FLT_ID = W#16#0C3A)
// or returns (FLT_ID = W#16#0C34)
//
// Local OB86 variables are accessed via the temp area:
//   OB86_EV_CLASS    (BYTE)   - B#16#38 = incoming, B#16#39 = outgoing
//   OB86_FLT_ID      (BYTE)   - W#16#0C3A = DP slave failure
//   OB86_MDL_ADDR    (WORD)   - logical base address of failed slave

      L     #OB86_EV_CLASS
      L     B#16#38                  // incoming event
      ==I
      JC    COMS                    // jump if fault entered

      L     #OB86_EV_CLASS
      L     B#16#39                  // outgoing event
      ==I
      JC    COMS_CLEAR              // jump if fault cleared

      BEU                            // unknown event - exit

COMS: SET
      S     "Coms_Fault_Pending"     // flag indicates bus is in fault
      S     "Coms_Fault_Active"      // latched for logic
      JU    COMS_END

COMS_CLEAR: SET
      R     "Coms_Fault_Active"
      // reset only after bridging window expires (handled in OB1)

COMS_END: BEU

SCL Example — Input Latching

// OB1 cyclic logic - input latching with bridging
FUNCTION_BLOCK FB_ComsBridge
VAR
    tHold : TON;                    // IEC on-delay timer
    tHoldTime : TIME := T#3S;       // 3-second bridge
    bBridgeActive : BOOL;
END_VAR
BEGIN
    // Start timer on every OB86 incoming event
    // (set from OB86: bFaultPending := TRUE)
    tHold(IN := bFaultPending, PT := tHoldTime);

    // Bridge active while timer is running OR pending set
    bBridgeActive := tHold.Q OR bFaultPending;

    // Latch last good input values
    IF NOT bBridgeActive THEN
        iMotorSpeedLatched := iMotorSpeedRaw;
        iPressureLatched   := iPressureRaw;
        bFaultPending      := FALSE;   // clear pending only after bridge
    END_IF;
END_FUNCTION_BLOCK

The output side is handled identically: while bBridgeActive is true, the program writes the previously held output pattern to the process image of outputs (PIQ). After the bridging timer elapses and no new OB86 has fired, the program resumes writing the live output values.

Reading Slave Diagnostics with SFC13

For diagnostic logging, use SFC13 "DP_SRM_DG" (DP_SRM_DIAG) to read 6 bytes of standard DP diagnostic information from a slave. This helps confirm whether the disturbance is at the slave level or master level.

      CALL "DP_SRM_DG"
           REQ     := TRUE                  // read once
           LADDR   := W#16#3FF              // DP master logical address (318-2 DP)
           RET_VAL := MW 100                // return code
           BUSY    := M 102.0
           RECORD  := P#DB100.DBX0.0 BYTE 6 // destination: 6 bytes
           LEN     := MW 104                // bytes read

Standard diagnostic bytes returned by SFC13:

If bit7 of byte1 = 1 (PrmFault) the disturbance is a parameter mismatch, usually caused by a slave being replaced with a different GSD revision. If bit2 of byte0 = 1 (SlaveNotReady) and bit4 of byte0 = 1 (NoSlaveResponse), the disturbance is a true bus-physical-layer problem and the bridging logic is masking, not solving, a hardware fault.

Diagnostic Buffer Analysis

Open STEP 7 → PLC → Diagnostic/Setting → Diagnostic Buffer. Filter for "Bus fault" or "DP" entries. Typical entries for a 1-second transient:

• 0x8301 — "Distributed I/O: station failure" (OB86 entry)
• 0x8302 — "Distributed I/O: station return" (OB86 exit)
• 0x8304 — "Distributed I/O: diagnostics interrupt" (OB82)
• 0x8305 — "Distributed I/O: invalid configuration"
• 0x8311 — "Master system: bus error (timeout)"

The time between 0x8301 and 0x8302 is the actual disturbance duration. If it consistently sits at 800-1200 ms, the bridging timer must be set to at least 1500-2000 ms to provide safety margin. If the interval grows beyond the bridging window, the application must react (alarm, controlled shutdown).

Verifying the Bridge on a Running System

1. Download the modified HW Config with the new watchdog (2000 ms) and the project with the four diagnostic OBs loaded.
2. Place the CPU in RUN-P; do not go to STOP.
3. Insert a deliberate fault: pull a Profibus connector briefly (≤ 2 s) and reinsert.
4. Observe: Coms_Fault_Pending becomes TRUE in VAT; outputs held at last good value; diagnostic buffer records both 0x8301 and 0x8302; no SF or BF LED lit on the master.
5. Repeat with a longer pull (> 4 s) and confirm: outputs fall to safe state after the bridging window expires, alarm is raised, CPU remains in RUN.
6. Capture a Profibus trace with SINAUT Scout / Amprolyzer / ProfiTrace to confirm token rotation recovers.

Comparison: Three Approaches to Bus-Fault Bridging

Root-Cause Checklist Before Relying on Bridging

Bridging is a safety net, not a fix. The following checks must be completed during commissioning to confirm whether the underlying network is healthy enough to absorb a watchdog extension:

1. Terminating resistors: ON only at the two physical ends of the segment; OFF on every other node.
2. Cable type: Profibus cable (violet) with characteristic impedance 150 Ω; verify no substitution with standard RS-485 cable.
3. Shield bonding: 360° EMC glands at every cabinet entry, bonded to a common ground bar.
4. Distance budget: ≤ 1000 m per segment at 1.5 Mbit/s; ≤ 200 m at 12 Mbit/s. Repeaters segment properly.
5. Baud rate: All nodes (including slaves and diagnostic repeaters) at the same rate.
6. Connector pin assignment: Pin 3 (B), Pin 5 (DGND), Pin 6 (VP), Pin 8 (A). Verify no swapped A/B lines.
7. EMC segregation: ≥ 200 mm clearance from VFD power cables; crossings at 90°.
8. Master loading: T_TR should be < 50% of token rotation; if higher, reduce baud rate or split segment.
9. Diagnostic buffer trend: 30-day baseline; transient count must be < 1 per 24 h on a healthy bus.

Standards & Reference Documents

All Profibus DP timing constants derive from IEC 61158-6 (Application Layer) and IEC 61784 (Profiles). The watchdog mechanism is specified in IEC 61158-3 (Physical Layer) and IEC 61158-5 (Application Layer Services). Engineering must verify the version of these standards applicable to your jurisdiction and plant.

For general communication-error definition and taxonomy, refer to Communication Error — ScienceDirect Topics.

Siemens official documentation for the procedures above:

• SIMATIC S7-300 CPU 31xC and CPU 31x — Manual (Entry ID 1097516)
• SIMATIC S7-400 Automation System — Installation Manual (Entry ID 1117740)
• SIMATIC NET — PROFIBUS DP — System Description (Entry ID 8859629)
• SFC13 DP_SRM_DG — Reference (Entry ID 15243326)
• OB86 — Rack Failure — Reference (Entry ID 13316782)

Field Commissioning Notes

When commissioning a bridging strategy on an existing site, document the following in the Functional Safety / Functional Specification file:

• Maximum allowed disturbance duration (e.g. ≤ 2 s).
• Bridging window (typically 2× max disturbance, min 1.5 s).
• Output behavior outside the bridging window: safe-state value, alarm destination.
• Diagnostic buffer review frequency (daily / shift / weekly).
• Acceptance criterion: zero OB86 entries during cold-run acceptance test of 8 h minimum.