Troubleshooting OB86 Stops on S7-300/400 Wireless Profibus

Problem Overview: PLC Enters STOP on Intermittent Wireless Profibus Drops

A machine built around a Siemens SIMATIC S7-300 or S7-400 master PLC communicating with three DP slaves over a wireless Profibus DP link (for example a SATEL radio modem pair) repeatedly transitions to STOP mode when the radio link drops for only a few seconds. The diagnostic buffer of the CPU shows OB 86 (Rack Failure) and OB 82 (I/O Point Fault) entries, and the operator screen reports a rack fault driven by a machine-level marker such as M 860.0. The plant engineer wants the PLC to ride through short, recoverable wireless dropouts (≤10 s) without halting the line.

This article documents the root cause, the correct way to delay a rack-fault reaction, and the verification steps needed to confirm the ride-through without losing real fault coverage. All references point to official Siemens documentation for STEP 7 V5.x and the S7-300/S7-400 system manuals.

Why the CPU Enters STOP: OB 86 and OB 82 Fundamentals

On S7-300 and S7-400 CPUs, asynchronous error organization blocks (OB 80 to OB 87) and the I/O access error OBs (OB 121, OB 122) are called automatically by the operating system when the corresponding event occurs. Per the official Siemens documentation for the Rack failure organization block (OB 86):

If OB 86 has not been programmed, the CPU changes to STOP mode when this type of error is detected. You can use the "DIS_IRT" instruction to disable the rack...

This is the central rule the field engineer must internalize. The PLC does not stop because of OB 86; it stops because OB 86 is missing and the operating system has no destination to vector to. The same logic applies to OB 82 (diagnostic interrupt), OB 85 (priority class error), and OB 121/122 (programming/IO access errors).

OB 86 is called twice for every rack event:

• Event class B#16#38 — the rack/station has failed (i.e., it went away or is no longer reachable).
• Event class B#16#39 — the rack/station is back (the failure has been resolved).

OB 82 is also called twice for every diagnostic event:

• Event class B#16#38 — diagnostic interrupt incoming.
• Event class B#16#39 — diagnostic interrupt outgoing.

The local variables of OB 86 expose the event class, the rack/station number, and the DP master system ID. The local variables of OB 82 expose the logical base address, the channel number, and the channel error type.

Root Cause: Machine Stop Is Not OB 86 — It Is the Code That Follows

The user's starter code already contains the pattern that appears to be a delay but is actually a one-shot transition that re-triggers immediately on the next OB 86 call:

OB86:
L     #OB86_EV_CLASS              // Leaving state
L     B#16#39
==I
JC    OK
L     #OB86_EV_CLASS              // Entering the state
L     B#16#38
<>I
JC    NWE
A     "M 860.0"
R     "M 860.0"
JU    NWE
OK:   AN    "M 860.0"
S     "M 860.0"
NWE:  NOP   0

When the radio link drops, the CPU calls OB 86 with EV_CLASS = 38h. The code jumps to NWE because the comparison <>I is true. The marker M 860.0 is not reset on the incoming event because the path through OK (the leave event) is never taken. As soon as the link recovers (sub-second re-association on a SATEL pair, or a one-second Profibus retry), the CPU calls OB 86 again with EV_CLASS = 39h, sets M 860.0, and OB 1 evaluates that marker as a stop condition. The line halts even though the PLC never went into STOP mode from OB 86 itself.

Required OB Inventory for a Healthy CPU

Before changing the timing logic, confirm that every asynchronous error OB is present in the offline project and downloaded to the CPU. The table below lists the OBs that must exist in the S7 program to keep the CPU in RUN even when a single event is missed.

The official Siemens list of organization blocks and the rules that govern STOP-on-missing are documented in the STEP 7 V5.x system manual. The Rack failure organization block (OB 86) page in the Siemens documentation cloud explicitly states the STOP behavior, and the same behavior applies to OB 82 through the corresponding I/O point fault (OB 82) page.

Why a Wireless DP Link Generates Frequent OB 86 / OB 82 Events

A wireless Profibus DP bridge (for example the SATEL radio modem often used as a serial-based DP repeater) introduces four failure modes that a hard-wired bus does not:

1. RSSI / fading margin loss — momentary fade of the radio path that exceeds the SATEL receiver sensitivity threshold, breaking the RS-485 / Profibus physical layer for 100 ms to several seconds.
2. Token re-acquisition delay — even if the physical layer recovers in milliseconds, the DP master must time out the slave at the configured T_slot interval before it raises a station failure. Typical values are 50 ms to 300 ms on a 1.5 Mbit/s bus.
3. Diagnostic interrupt bounce — each slave with diagnostic capability reports the channel fault on entry and again on exit. A short dropout therefore produces four OB 86 events and two OB 82 events per affected slave.
4. Repeater / OLM re-initialization — optical or radio-based repeaters may take 2 s to 5 s to re-associate, during which the master sees the downstream station as gone.

For a ten-second dropout on a 1.5 Mbit/s DP line with three slaves, the master can record 24+ rack events in the diagnostic buffer. The CPU executes OB 86 and OB 82 for every one of them, but the operating system itself does not stop the CPU as long as both OBs are present.

Implementing a 10-Second Ride-Through Delay

The objective is to assert the machine-level stop flag only if the DP station has been continuously failed for longer than the configured dropout tolerance. The pattern in the starter code is close, but it must be extended to (a) start a timer on the incoming event, (b) keep the marker clear while the timer is running, and (c) only set the alarm on the leaving event if the timer has elapsed.

The corrected OB 86 below uses two IEC timers — one per logical station — and a single machine-OK aggregation marker. Adjust the station count to match the actual DP topology (three slaves in the user's case).

// =============================================================
//  OB86 - Rack / DP station failure - ride-through logic
//  Siemens S7-300 / S7-400, STEP 7 V5.x, STL
// =============================================================

      L     #OB86_EV_CLASS          // 38h = incoming, 39h = outgoing
      L     B#16#38
      ==I
      JC    FAIL                    // jump if station has just failed

      L     #OB86_EV_CLASS
      L     B#16#39
      ==I
      JC    OK                      // jump if station has just recovered

      BE                            // any other event class: ignore

// ----- Station FAILED (event class 38h) ----------------------
FAIL: L     #OB86_MDL_ADDR          // DP station number / address
      L     L#0
      <>I
      JC    MISC
      L     #OB86_MDL_ADDR
      L     L#1
      ==I                           // slave #1 failed ?
      JC    FAIL1
      L     #OB86_MDL_ADDR
      L     L#2
      ==I                           // slave #2 failed ?
      JC    FAIL2
      L     #OB86_MDL_ADDR
      L     L#3
      ==I                           // slave #3 failed ?
      JC    FAIL3
      JU    MISC

FAIL1:AN    M      860.1            // re-trigger on every bounce
      L     S5T#10S                 // 10 second tolerance
      SD    T      11
      JU    AGG

FAIL2:AN    M      860.2
      L     S5T#10S
      SD    T      12
      JU    AGG

FAIL3:AN    M      860.3
      L     S5T#10S
      SD    T      13
      JU    AGG

MISC:  BE                            // unknown station: do nothing

// ----- Station RECOVERED (event class 39h) -------------------
OK:   L     #OB86_MDL_ADDR
      L     L#1
      ==I
      JC    OK1
      L     #OB86_MDL_ADDR
      L     L#2
      ==I
      JC    OK2
      L     #OB86_MDL_ADDR
      L     L#3
      ==I
      JC    OK3
      BE

OK1:  R     M      860.1
      R     T      11
      JU    AGG
OK2:  R     M      860.2
      R     T      12
      JU    AGG
OK3:  R     M      860.3
      R     T      13
      JU    AGG

// ----- Aggregate machine-level alarm -------------------------
AGG:  A     M      860.1
      A     M      860.2
      A     M      860.3
      =     M      859.7            // Machine OK only if ALL slaves OK

      O     T      11               // any slave timed out?
      O     T      12
      O     T      13
      =     M      860.0            // Machine NOT OK (delayed)
      BE

The corresponding OB 82 logic follows the same template. The marker M 860.0 is the "machine NOT OK, delayed" alarm that the HMI alarm log is currently using, so the existing alarm and screen behavior is preserved — only its timing changes.

Timer Selection: S5T#10S vs IEC SFB 3 / SFB 4 / SFB 5

The example uses the legacy S5 timer (SD — on-delay, retentive) for two reasons:

1. It is re-triggerable as long as the enable input is true; the on-delay simply restarts.
2. It runs in the OB 86 execution context and the elapsed time is independent of OB 1 cycle time.

If a different timing source is preferred, the IEC SFB 3 (TP — pulse), SFB 4 (TON — on-delay), or SFB 5 (TOF — off-delay) blocks may be used. For a 10-second window the S5 form is sufficient and avoids instance-DB management overhead. The S5 time format is S5T#<value><unit> where the unit may be MS, S, M, or H, and the base value is 16-bit unsigned. A 10-second S5 time is internally encoded as 10 × 100 = 1000 in 10 ms ticks, so the maximum range is approximately S5T#2H46M30S.

Alternative: Disable the Interrupt with DIS_IRT

For applications that do not need the diagnostic information at all, the OB 86 documentation also documents the DIS_IRT (disable interrupt) and EN_IRT (enable interrupt) SFC calls. By calling SFC 39 "DIS_IRT" with OB 86 as the OB number argument, the CPU suppresses all OB 86 calls for a given DP station and never updates the operating-system station-state bits. This is a "blind" ride-through and should be used only when the application truly does not need to know the station is gone.

Step-by-Step Implementation Procedure

1. Back up the project. In STEP 7 (SIMATIC Manager), select the S7 program, choose File → Archive, and save a complete project archive (.zip or .arc) before any change.
2. Verify OB inventory. Open the Blocks container and confirm OB 80, 81, 82, 83, 84, 85, 86, 87, 100, 101 (S7-400 only), 102, 121, 122 are present. If any are missing, insert an empty OB for each, download the program, and verify the CPU no longer goes to STOP on the next dropout.
3. Replace OB 86 and OB 82 with the delayed versions above, or import them as new sources. Recompile the program; STEP 7 will warn if the OB temporary (LOCAL) variables are missing — the temporary declaration for OB 86 must include OB86_EV_CLASS, OB86_MDL_ADDR, OB86_RACKS_FLTD, and the standard fault-info word.
4. Download the program in STOP mode, then perform a warm restart via the CPU operator panel or the online menu. Do not use a cold restart — it will clear non-retentive M and T state.
5. Open the diagnostic buffer (PLC → Diagnostic/Setting → Diagnostic Buffer in STEP 7) and confirm the new OB 86 entries appear with event class 38 and 39 alternating as the link drops and recovers.
6. Trigger a controlled dropout by switching off the SATEL radio power for 5 s, then 15 s. The HMI alarm "Rack Fault / M 860.0" must remain clear for the 5-second test and must assert for the 15-second test.
7. Log the diagnostic buffer for each test and attach to the commissioning report.

Verification: How to Prove the Ride-Through Works

Use the following test matrix to validate the change in controlled conditions before authorizing production operation. The test duration column indicates how long the wireless link must be broken to reach the corresponding verdict.

To capture the timing precisely, monitor the timer word of T 11, T 12, and T 13 in a VAT table. The elapsed time at the moment the link recovers is the measured ride-through value and must be less than 10 s for the configuration to behave as designed.

Troubleshooting Matrix: Common Symptoms and Fixes

Profibus Timing Parameters to Tune for Wireless Links

Beyond the OB-level delay, the Profibus parameters in HW Config directly influence how often OB 86 fires. For a wireless link, Siemens recommends extending the retry and slot time values so the master waits longer before declaring a station failure. The relevant parameters and their typical wired vs. wireless values are listed below.

The default Profibus watchdog of 1 s is the most common cause of "phantom" OB 86 events on wireless links: a single missed token triggers the watchdog before the master can re-poll. Raising the watchdog to 5 s and the retry limit to 3 reduces OB 86 traffic by an order of magnitude, complementing the OB-level delay in this article.

Safety Considerations

A ride-through on communication faults is a process-control decision, not a safety decision. The user must confirm that:

• No SIL-rated emergency stop is implemented in the DP slaves being ride-throughed. E-stop must be wired hard-wired to the F-CPU or to a safety relay, not to a Profibus message.
• The machine's risk assessment accepts continued operation while the slaves are unreachable. If the controlled process cannot tolerate lost I/O for 10 s, the ride-through must be shorter or removed.
• The OB 86 delay does not mask a real physical fault. A persistent dropout will still assert the alarm at t=10 s, and the diagnostic buffer retains the original OB 86 38h event with full timestamp and station number.

FAQ