The client sends a screenshot of the SIMATIC Diagnostics buffer: "PROFINET IO: communication error 16#80B1, slot 3 module 2". The PLC recovers communication after 200 ms, the cycle just barely passes, but prediction-time numbers have got worse and OEE has dropped 4% against last month. Question: what's wrong?
The answer most integrators give: "check the PLC firmware, possibly replace the IO module." This is the strategy for losing 3 weeks and €4,000 in service hours without finding the cause. Real Profinet diagnostics isn't done in TIA Portal — it's done in Wireshark, in the topology view (LLDP) and in switch management. This article is a playbook for getting to the root cause in 2–4 hours instead of 2–3 weeks.
Four layers where the fault can hide
For Profinet RT problems, 95% of faults sit in one of these layers:
1. **Physical layer** — cable, connector, shield, EMC interference, segment length 2. **Switch / topology layer** — QoS, priority, port configuration, conformance class 3. **Device layer** — IO module, firmware version, device name, IP configuration 4. **Protocol layer** — RT class (1 / 2 / 3), update time, watchdog, GSDML mismatch
The client only looks at 3 and 4 — TIA Portal tells them what the PLC sees. Real diagnostics starts at 1 and 2.
Step 1 — Wireshark capture on the Profinet segment
Without a Wireshark capture there's no point guessing. Setup:
- **TAP (Test Access Point)** between the PLC and the switch (Profitap ProfiShark 1G, Allegro Network NA10G, Garland Tech P1GMS) — passive tap, never use a mirror port on a production switch, jitter gets distorted
- **Second choice:** if you don't have a TAP, a port mirror on a managed switch (Cisco IE-4000, Hirschmann RSP, Siemens SCALANCE XR-528) — works for packet content analysis, **doesn't work** for accurate jitter analysis
- Wireshark 4.4+ with the **Profinet dissector** (built-in since version 3.0)
- Capture filter: `vlan and eth.type == 0x8892` (Profinet EtherType) or full capture and dissect post-hoc
What to measure in Wireshark:
A) Cycle time consistency
Profinet IO RT commonly has an update time of 4 ms (default), 8 ms, or 16 ms. Capture 60 seconds of communication between the PLC and the problem device. In Wireshark: `Statistics → I/O Graphs`, filter `pn_rt && ip.src == <PLC IP> && ip.dst == <device IP>`. Expected interval between packets = update time ± 100 μs jitter.
A real example from a line 2026-03 (Slovak client — automotive Tier 1): - Update time configured: 4 ms - Measured: 4 ms ± 200 μs base, but **every 12–18 seconds a spike of 18–32 ms** lasting 1 packet - Watchdog: 3 × 4 ms = 12 ms → the spike exceeds watchdog → IO error 16#80B1
B) Frame loss
Profinet RT is UDP-like (no acknowledgement). One lost frame = an immediate jump in the cycle counter. The Wireshark dissector shows `cycle_counter` in every RT frame. A jump in the counter by more than 1 = lost frame.
Acceptable rate: < 1 lost frame per million (1e-6). Real problem: > 1 / 100,000 (1e-5) — that's what we see as "the communication occasionally drops" to the operator.
C) Alarm frames
Profinet has a separate alarm channel (acyclic, low-priority). In Wireshark the filter `pn_io.alarm_type` shows device-generated alarms: temperature warnings, module diagnostics, diagnostic alarms. Many clients ignore these because "the PLC hasn't complained yet" — but they contain warnings that precede an outage by hours.
Step 2 — SIEMENS PRONETA Basic (the free tool nobody uses)
PRONETA Basic is freely downloadable (Siemens Support Portal, ID 67460624) and does 80% of what paid SINEC NMS does — for free. Three key functions:
- **Topology scan** over LLDP — builds the actual topology graph of the current network and compares it with the planned topology from the TIA Portal project. Cable miscount, wrong port assignment, unknown device (for example a forgotten technician laptop or an unauthorised switch) shows up instantly.
- **IO Test** — attaches itself as a Profinet IO controller (emulates the PLC) and runs a read/write test directly on the IO module without the PLC in the path. If the IO test works and the PLC doesn't, the problem is in PLC config or in the PLC → device communication path. If the IO test doesn't work, the problem is in the device or the cable to the device.
- **Diagnostic readout** — reads firmware versions, IP configuration, device name and alarm history from all reachable devices at once. 30% of "non-deterministic" Profinet problems are duplicate device names — scan and you'll see two modules with the same name on the network.
Step 3 — Jitter measurement (LLDP and TSN ready check)
For Profinet IRT (motion, sub-ms) jitter < 1 μs is the requirement. For Profinet RT (1–8 ms cycle) jitter < 100 μs is acceptable. Measurement:
- **PROFITap ProfiShark 1G** with precise timestamp (sub-microsecond)
- **Synesis InterMatch** or **Allegro Network Multimeter** (dedicated industrial NTM)
- **Lightweight:** Linux box with a PTP-aware NIC (Intel I210, I225) and `tcpdump -i eth0 -j adapter_unsynced` — timestamps from the HW NIC clock
The most common cause of high jitter (> 500 μs): an unmanaged switch in the Profinet path. A common D-Link / TP-Link / Netgear switch has no QoS for the Profinet EtherType 0x8892 — RT frames sit in queue behind bulk traffic (firmware download, configuration upload, video feed from a camera).
A story that actually happened — 50 ms cycle → 200 ms cycle
Client (food plant, Bratislava, pressurised filling lines, 5-line setup). Complaint: one of the five lines has a cycle time of 200 ms instead of the designed 50 ms. PLC: Siemens S7-1517F. IO: ET 200SP with 6 IO modules + 2 servo-axes via Profinet IRT.
**First 3 days — wrong paths:** - TIA Portal diagnostics: no ERROR, but `IO update time exceeded` warnings - Firmware update PLC + IO modules: no shift - Replacement of the IO module presumed "slow": no shift
**Day 4 — Wireshark + PRONETA:**
PRONETA topology scan showed: - 4 lines have a line topology: PLC → IO1 → IO2 → IO3 → IO4 (via the built-in 2-port switches in the IO modules) - **The fifth line has a STAR topology via an external switch** SCALANCE X-208 — a historical artefact from when the line had an extra workstation
Wireshark capture on the fifth line: - Update time 50 ms ± 80 ms (!) — massive jitter - Frame loss: 4 / 10,000 (1e-3.4) — unusable for IRT motion - Bulk traffic: 200 Mbps RTSP video stream from an HMI camera through the same switch
**Cause:** the SCALANCE X-208 had **default QoS config** (FIFO, no priority for the Profinet EtherType). Under video stream load, Profinet RT frames waited in the queue. The operator had enabled video monitoring "just for testing" — 6 months earlier.
**Fix:** a 30-minute change in the switch's Web Based Management: 1. Enable Profinet QoS preset (`Configuration → QoS → Profinet`) 2. Set EtherType 0x8892 priority class 6 (best effort = 0, voice = 5, Profinet = 6, network control = 7) 3. Apply, commit, save startup config
**Result:** cycle time back to 50 ms ± 2 ms. Jitter < 80 μs. Line OEE rose from 71% to 88% the week after the fix.
This specific problem **would never have been fixed by a PLC firmware update** — the fault was in a switch configuration 3 hops away from the PLC. Without Wireshark capture + PRONETA topology the root-cause hunt would have taken another 2–4 weeks and lost another €40–60k in missed production.
Five places nobody checks
1. **Cable outside PROFINET Type A/B/C** (ISO/IEC 11801). A standard office CAT-6 in a hall with variable-frequency drives degrades faster than paper. Industrial Type C with double shield costs €40–80 extra per line — an investment that returns on the first drop. 2. **Shield terminated at both ends** at different ground potential points → ground loop → induced voltage 5–50 V → corrupted frames. The Profinet shield goes on only one end. 3. **Switch QoS misconfiguration** — default QoS on a managed switch is often NOT correct for the Profinet EtherType 0x8892. You must explicitly enable the Profinet QoS preset, or manually configure VLAN + 802.1p priority class 6. 4. **Wrong Conformance Class.** Profinet has three classes (CC-A basic, CC-B device replacement + diagnostics, CC-C isochronous IRT). For IRT motion **every** switch in the path must be CC-C. A cheaper CC-B switch in the IRT path = inconsistent cycle time. 5. **Device name duplicates.** Profinet identifies a device by `device_name` (DNS-like), not MAC. A replacement IO module with an unconfigured name = duplicate on the network = arbitrary frame routing = random failures.
A practical playbook — 4 hours of diagnostics
On Profinet problems:
1. **(30 min)** PRONETA Basic topology scan. Compare with the TIA Portal project. Identify differences. 2. **(45 min)** Wireshark capture for 5 minutes on the problem segment via TAP or mirror port. Filter `pn_rt`. Analyse cycle time consistency, frame loss, alarm frames. 3. **(30 min)** PRONETA IO Test on the problem device. Working? The problem is in PLC config. Not working? The problem is in the device or the path to it. 4. **(60 min)** Switch management — check QoS, priority, conformance class on all switches in the path. Check cabling (Type A/B/C), shield termination, EMC environment. 5. **(45 min)** Reproduce + verify. After identifying the suspected cause — change it, measure again, compare before / after.
This gets you to 90% of Profinet problems. For the remaining 10% (TSN, advanced motion sync, multi-vendor inter-op) you need SIEMENS SINEC NMS (paid, €4,000–8,000 per year) or vendor support — but that 10% is worth bringing in an external expert for rather than tying up your own team.
---
*We perform Profinet diagnostics, network auditing and TSN migration for production lines in SR/CZ/PL. The first consultation (90 min) on your specific problem will likely surface 1–2 of the five places above — or at least tell you which of the three layers (cable / switch / device) deserves further investigation.*