Resolving Intermittent PROFINET Disconnects Triggering OB86 on Siemens S7 PLCs

Intermittent PROFINET communication drops in a multi-PLC installation are among the most time-consuming faults in modern discrete and process automation. The classic symptom pattern is unmistakable: one or more PROFINET IO controllers spontaneously report OB86 rack or IO system failure, downstream HMI tags display ##### (substitution value or process value invalid), drives and field devices fault on bus loss, and the CPU remains unreachable from TIA Portal until a power cycle is performed. This reference details a structured, evidence-based diagnostic path for isolating the root cause, restoring deterministic PROFINET behavior, and preventing recurrence.

1. Problem Description and Failure Signature

The reported failure has the following consistent signature across affected CPUs (referenced here as X1, X2, X3, X4, X7 in a multi-PLC topology):

• Multiple CPUs in independent cabinets enter PROFINET IO system-down state at unpredictable intervals, never simultaneously.
• The CPU's diagnostic buffer records OB86 events with text variants such as "PROFINET IO system failure", "IO device failure", or "Distributed I/O: station failure".
• Connected SINAMICS drives (e.g., G120, S120, V90) report F08501 (PROFINET communication fault) or F08502 (sign-of-life failure).
• WinCC Unified or WinCC Comfort panels show ##### in tag fields, indicating the HMI cannot refresh the process value within the configured acquisition cycle.
• The CPU remains accessible only briefly after the fault, often refusing TIA Portal "Go Online" attempts with 0xE0EB or connection-timeout errors.
• A power cycle on the affected cabinet restores the network, suggesting a non-persistent latched condition (watchdog, link state, or firmware hold).

Each symptom is a clue. The fact that multiple cabinets and multiple CPU types fail in the same way within a one-year operating window is a strong indicator that the cause is environmental (power, grounding, or cable plant) rather than device-specific. A device-specific fault would not migrate randomly across cabinets.

2. Understanding OB86 and the Diagnostic Buffer

OB86 is the Siemens S7 organization block executed when a fault occurs in the distributed I/O (DP) or PROFINET IO system. It distinguishes two event classes via the OB86_EV_CLASS and OB86_FLT_ID temporary tags:

FLT_ID (B#16#)	Meaning	OB86_IO_STATE

B#16#01 Inserted/removed module (not relevant to PROFINET) 0 / 1 B#16#02 PROFINET IO system failure / return 0 = failure, 1 = return B#16#03 PROFINET IO device failure / return 0 = failure, 1 = return B#16#04 PROFINET IO device rack/station mismatch (with record set 0x802A) 0 / 1 B#16#05 PROFINET IO device return (after being removed) 1 B#16#06 Neighbor station failure (topology editor mismatch) 0 B#16#07 PROFINET IO system: redundant IO failure/return 0 / 1 B#16#08 PROFINET IO device: multiple-bit error in slot 0 / 1

The fault contains the following additional start information in the OB86 temp area:

• OB86_MDL_ADDR – logical base address of the affected PROFINET IO device or IO system.
• OB86_IO_STATE – 0 (incoming failure) or 1 (outgoing return).
• OB86_Z23 through OB86_Z28 – slot, submodule, and channel diagnostics pointers.
• OB86_Z33 – IO device number, useful for cross-referencing the device configuration in TIA Portal.

To extract the diagnostic record set programmatically, the standard call inside OB86 is:

// S7-1500 / S7-1200, TIA Portal SCL
#retCode := RDREC(SRCBLK  := "PROFINET_Device_DB".IO_Device_HwId,
                RECORD  := #diagRecord,
                LEN     := 256,
                BUSY    := #busyFlag);

#bytesRead := BLKINFO.DIAGLENGTH; // length returned by record 0x00F1 or 0x802A

Reading record 0x802A (PROFINET IO diagnosis data record) provides the manufacturer-specific channel diagnostics. Standard ChannelErrorType codes frequently seen in this fault class are:

ChannelErrorType (hex)	Meaning	Likely Root Cause
0x0001	Short circuit	Sensor/wiring fault, output module overload
0x0002	Undervoltage at the load voltage (L+)	Power supply dip, missing jumper
0x0003	Overvoltage	Inductive kickback, wrong supply
0x0006	Wire break	Broken conductor, loose terminal
0x001E	Watchdog timeout / sign-of-life failure	PROFINET link interruption
0x001F	Module removed during operation	Mechanical disturbance, EMI
0x002A	Configuration mismatch	Slot not assigned or wrong submodule

3. Root Cause Categories

Across the installed base, the following six root-cause families account for the overwhelming majority of intermittent PROFINET IO dropouts. Use this matrix to triage before opening tooling.

#	Family	Indicators	Affected	Probability
1	Power supply / PE bonding	Multiple cabinets, multiple CPUs, no fixed time pattern, coincident with mains events	All on the same grounding scheme	High (40%)
2	Unmanaged switch / daisy-chain	Single switch or cable section, devices beyond a node drop simultaneously	Devices on that segment	High (20%)
3	EMI / cable routing near VFDs	Drops correlate with VFD start/stop; V90 / S120 reports F08501	Nearby devices	High (15%)
4	Watchdog / update time mismatch	Drives with fast update times, multicast filtering issues	Drives, only the affected IO device	Medium (10%)
5	IP / device name collision	Only one CPU affected, replaced hardware	Single station	Medium (8%)
6	Firmware bug / I&M mismatch	One device family, only since firmware update	One device family	Low (5%)

The fact that the system ran for one year before exhibiting the fault is a strong signal against root causes 2, 4, and 5 (these tend to fail at first commissioning). It is consistent with root causes 1, 3, and 6 (degradation of grounding bonds, terminal oxidation, aging EMI filters, and firmware drift after a recent update).

4. Hardware Inspection Procedure

Begin with a physical layer audit. The order below is not arbitrary; it follows the path that a single disturbance takes when it propagates through the system.

1. Verify cabinet PE bonding. Measure between the cabinet ground bar and the building ground with a four-wire milliohm meter (e.g., Megger DLRO10). Target value: <1 Ω for each cabinet; <0.1 Ω for the entire bonding run. Look specifically for painted or anodized surfaces between busbars and the cabinet frame; these must be scraped clean to bare metal before re-torquing.
2. Check the PROFINET cable screen termination. Each PROFINET FC RJ45 plug (e.g., 6GK1 901-1BB10-2AA3) must be installed with the braided screen making 360° contact to the connector shell. Loose crimps or partial screen coverage are a leading cause of CMRR degradation. Replace any field-assembled plug showing visible strain on the cable.
3. Verify load-voltage (L+) presence on the PROFINET switches and the field devices. A momentary undervoltage will not always clear the CPU's link state machine; it is sometimes latched until a reset.
4. Inspect the daisy chain. PROFINET is specified for line, star, or ring topology, but daisy chaining through unmanaged switches (e.g., generic 100 Mbit consumer switches) is the single most common cause of non-deterministic behavior. Replace with a SCALANCE XC208 (6GK5 208-0BA10-2AB3) or XB208 (6GK5 208-0BA10-2AB2) managed switch, or redesign the topology as a star.
5. Measure the link quality with a PROFINET cable tester. The Softing PROFINET Tester (BC-700-PB) reports cable length, attenuation, NEXT, and signal-to-noise ratio. A cable that passes DC continuity can still fail at 100 Mbit due to excessive return loss.
6. Confirm cable type. PROFINET Type C is rated for 45 m fixed installation, Type B for 65 m. Mixing categories, or substituting Cat 5e cable for the heavier 2-pair FC cable (6XV1 840-2AH10), reduces immunity to VFD common-mode noise.

5. Power Supply and Grounding Best Practice

The Siemens PROFINET Installation Guide (PROFINET installation guidelines) requires the following grounding topology, which differs from PROFIBUS practice and is a frequent source of confusion:

• Each cabinet contains a single ground busbar bonded to the cabinet frame, the PE terminal of the incoming supply, and the building ground electrode via the shortest possible path.
• All PROFINET cable screens are bonded to this busbar at both ends.
• If multiple cabinets are interconnected, the ground busbars of all cabinets must be bonded together with a low-impedance cable (cross-section ≥6 mm² Cu for each cabinet, but the actual sizing should be verified against local code).
• The 24 VDC load return (0 V / M) at each device should be referenced to the same ground reference, but the negative terminals of the supplies are not the appropriate bonding point. Bond only at the cabinet ground bar.

Regarding the question of "combining the negative terminals of all power supplies": doing so is acceptable only if all 24 V supplies share a common, single-point ground reference. In practice, this is rarely advisable because it creates a return path through the building steel for any leakage current. The correct path is to bond the protective earth terminals at the cabinet ground bars, not to tie the 0 V rails together. The 0 V rail is a functional return, not a safety ground.

6. Network Infrastructure: Managed Switches and Topology

An unmanaged switch will forward PROFINET RT frames, but it has no awareness of update times, multicast filtering, or priorities. A single broadcast storm or a duplicate MAC address on a misconfigured device will propagate to every port. Siemens PROFINET conformance requires that:

• All switches in the path are managed (SCALANCE, Cisco IE, Stratix, or equivalent) and have IGMP snooping enabled for multicast filtering.
• The PROFINET RT frames use VLAN priority 6 (CC-A) or VLAN priority 5 with the LLDP priority tag. Check the switch port configuration: untagged PROFINET frames will not be prioritized.
• Port-based storm control thresholds are set so that a runaway device cannot saturate the entire segment.
• The PROFINET device's send cycle is set to a multiple of the bus cycle, typically 1 ms for drives, 2-4 ms for distributed I/O, 8-16 ms for HMI/HSC. Misaligned send cycles are a frequent cause of sign-of-life failure diagnostics.

If a ring topology is in use, ensure that the media redundancy protocol (MRP) is configured on every switch and that the ring manager is unique. MRP reconfiguration takes ≤200 ms; if the affected link reconfiguration exceeds the PROFINET watchdog time, OB86 will fire. A typical S7-1500 default watchdog of 3 × 1 ms = 3 ms can be violated easily by a misconfigured MRP network. Increase the watchdog to 3 × the slowest send cycle on the device, with a minimum 3 ms.

7. PROFINET Configuration Parameters to Review

Open the device properties in TIA Portal under "PROFINET interface → Advanced options → Real-time settings" and verify the following parameters against the OEM recommendations:

Parameter	S7 default	Recommended for drives	Recommended for DI/DO
Send clock (ms)	1.000	1.000	2.000
Reduction ratio	1	1	4 (→ 2 ms)
Update time (effective)	1 ms	1 ms	8 ms
Watchdog time (ms)	3	3	24
Substitute value behavior	0 (zero)	0 (zero)	0 or "Keep last value"

Watchdog time should be at least 3 × the update time, but the Siemens recommendation is to keep the watchdog conservative (e.g., 9 ms for a 1 ms update) to absorb transient cable and switch latency. A watchdog of 3 ms is theoretically correct but leaves no margin for switch reconfiguration or a single missed frame.

8. Diagnostic Methodology

8.1 Read the full diagnostic buffer

In TIA Portal: Online & Diagnostics → Diagnostics → Diagnostic buffer. Save it as a TXT file. The buffer must be read on the same CPU that generated the OB86 event, because OB86 is a self-localized event. If the buffer is empty (which can occur on S7-1200 with firmware <4.2 when the buffer has wrapped), trigger a controlled fault during a maintenance window by disconnecting one PROFINET device and confirm the buffer is being written.

8.2 Use the Web server of the S7-1500 / S7-1200

With the Web server enabled, navigate to https://<cpu-ip>/index.html, log in, and view the Diagnostic Buffer and Module Information pages. This can be done from any browser, including from a service laptop that does not have TIA Portal installed. It is often faster than starting a TIA session for a single CPU.

8.3 Use PRONETA

Siemens PRONETA (current version 3.x) is a free network-analysis tool that scans the entire PROFINET segment, lists every device, its name, IP, MAC, firmware, and module configuration, and validates the topology. Run a "Network Analysis" pass and look for devices marked in red (configuration mismatch) or yellow (slow link / partial match). PRONETA can also read the topology from each device's LLDP frames and compare to the engineering project to detect physical vs. logical port mismatches.

8.4 Use Wireshark with the PROFINET dissector

For intermittent faults that cannot be reproduced at will, a 24-hour Wireshark capture (using a managed mirror port on the affected switch) is the most reliable evidence. Filter on pn_rt and look for:

• DCP identify.req storms – indicates a device is repeatedly being asked for its name.
• Missing pn_io RTC (Real-Time Cyclic) frames – the device has stopped sending.
• pn_dcp.identify-resp with a name conflict – duplicate PROFINET name.

8.5 SINEC NMS

For installations with more than 30 PROFINET devices, Siemens SINEC NMS (Network Management System) provides SNMP-based polling, topology visualization, and a configurable alarm engine that can push OB86-style events to a central operator station. It is the recommended upgrade path for the described system as the cabinet count grows.

9. Step-by-Step Resolution Procedure

1. Capture the diagnostic buffer from the next CPU that exhibits the fault. Save it as a TXT and confirm the OB86 FLT_ID (use the table in Section 2).
2. Run PRONETA network analysis across all cabinets. Export the device list. Compare to the engineering project in TIA Portal (Device View → "Compare offline/online").
3. Inspect grounding of each cabinet as described in Section 4. Photograph the ground bar; if more than one cabinet is involved, confirm the inter-cabinet bond.
4. Replace any unmanaged switch in the path with a managed SCALANCE device.
5. Increase the PROFINET watchdog on every IO device to at least 9 ms for 1 ms update, 24 ms for 2 ms update, etc. Document the new value in the project and on the cabinet door.
6. Update firmware on the affected CPUs and drives to the latest released version on the Siemens Service Pack list. Reference the most recent S7-1500 firmware release notes and the corresponding SINAMICS G120/V90 firmware release notes.
7. Re-test under load by running the machine through a full production cycle for 8 hours while PRONETA is set to "Continuous scan". The scan period is configurable in 100 ms increments; for fault hunting, set it to 100 ms.
8. Document the resolution in the system logbook, including cabinet name, the cable that was replaced, the firmware versions before and after, and the OB86 event count delta over a one-week window.

10. Verification

Verification is a quantitative step, not a subjective one. Use the following checklist before closing the incident:

• Diagnostic buffer is clean for 168 hours (one production week). Confirm by downloading the buffer from each CPU and visually scanning for OB86 entries.
• PRONETA scan shows 0 red or yellow devices in 24 hours of continuous monitoring at 100 ms scan period.
• Wireshark capture (24 h) contains zero pn_dcp.name-collision, zero pn_io.RTC.missed, and zero pn_rt.RTA.retransmit events.
• Sinamics fault log (parameter r0947 for the active fault buffer) shows no F08501 / F08502 entries for 168 hours.
• HMI substitution value count (read via WinCC tag statistics) is zero for all PROFINET tags.
• PROFINET QoS counters on the SCALANCE switches (e.g., the Discarded Frames OID in SNMP) remain flat over the verification window.

11. Preventive Maintenance Schedule

Add the following to the site's annual maintenance plan:

• Quarterly: Run PRONETA "Topology check" and compare to engineering. Resolve any drift within 30 days.
• Semi-annually: Re-torque all PROFINET connector strain reliefs to the manufacturer's spec (typically 0.4 Nm for the 6GK1 901-1BB10 series). Inspect for screen-bond integrity.
• Annually: Perform an insulation resistance test on the PROFINET cable plant (500 VDC, ≥100 MΩ per segment). Document trend.
• Annually: Update firmware on all S7-1500 CPUs and SCALANCE switches to the latest Service Pack. The release notes on the Siemens support portal are the authoritative reference; a typical maintenance release is published every 6-9 months.
• After any cabinet work: Re-run PRONETA network analysis. Do not rely on a single power-cycle test.

12. Common Pitfalls When Scaling from a Single PLC to Multi-PLC Installations

The described installation is a multi-CPU topology in which each CPU is its own PROFINET IO controller and its own subnet. This is the right architecture for separating responsibility between cabinets, but it has three consequences that the field engineer must internalize:

1. OB86 is not global. A fault on the X1 PLC's PROFINET subnet is not visible in the X2 PLC's diagnostic buffer. The HMI must be configured to poll each CPU's diagnostic status individually (e.g., via the RD_SINFO SFC or the DeviceStates SFB). The ##### in the HMI is therefore a symptom, not a cause; the actual fault must be found on the corresponding CPU.
2. Routing between CPUs is not automatic. If the HMI is on the X1 cabinet's subnet, it cannot see the X2 CPU directly without an IP router or a PROFINET router interface on each CPU. The 6GK7 243-1BX30-0XE0 (CP 1243-1) or 6GK7 543-1AX00-0XE0 (CP 1543-1) is the standard S7-1200/1500 communications processor for IP routing.
3. Bonding the 0 V rails between cabinets is not the same as bonding the PE bars. The 0 V rail is a functional return; the PE bar is the safety and EMC reference. Bonding only the 0 V rails without a low-impedance PE bond will create a ground loop and make the PROFINET errors worse, not better.

13. Escalation Path

If all of the above steps have been completed and the OB86 events continue at the same rate, escalate with the following evidence package:

• Diagnostic buffer TXT from three separate OB86 events (one per affected CPU).
• PRONETA network analysis export (CSV).
• Wireshark capture covering at least one OB86 event (time-stamped).
• Cabinet grounding photograph set.
• Cable plant As-Built drawing, including lengths and routing relative to VFD cables.

Submit through the official Siemens Industry Online Support portal with the full project backup (TIA Portal V<version>, "Compress project to ZIP"). The Siemens support engineers can correlate the OB86 timestamps with the SIMATIC Automation Tool's audit log and any SINEC NMS events to pinpoint the offending device or cable.