Klient przysyła screenshot SIMATIC Diagnostics buffera: „PROFINET IO: communication error 16#80B1, slot 3 module 2". PLC odzyska komunikację po 200 ms, cykl tak-tak przejdzie, ale prediction-time liczby pogorszyły się, a OEE spadło o 4 % w porównaniu z poprzednim miesiącem. Pytanie: co jest źle?
Odpowiedź, którą dostanie od większości integratorów: „sprawdzić firmware PLC, ewentualnie wymienić moduł IO". To strategia, jak stracić 3 tygodnie i €4 000 w godzinach serwisowych bez znalezienia przyczyny. Prawdziwa diagnostyka Profinet nie robi się w TIA Portal — robi się w Wiresharku, w topology view (LLDP) i w switch management. Niniejszy artykuł to playbook, jak dostać się do przyczyny w 2–4 godzinach zamiast w 2–3 tygodniach.
Cztery warstwy, gdzie błąd może się ukryć
Przy problemach Profinet RT 95 % błędów tkwi w jednej z tych warstw:
1. **Warstwa fizyczna** — kabel, konektor, shield, EMC interference, długość segmentu 2. **Switch / topology layer** — QoS, priority, konfiguracja portu, conformance class 3. **Device layer** — moduł IO, wersja firmware, device name, konfiguracja IP 4. **Protocol layer** — RT class (1 / 2 / 3), update time, watchdog, GSDML mismatch
Klient patrzy tylko na 3. i 4. — TIA Portal powie mu, co widzi PLC. Prawdziwa diagnostyka zaczyna się na 1. i 2.
Krok 1 — Wireshark capture na segmencie Profinet
Bez Wireshark capture nie ma sensu zgadywać. Setup:
- **TAP (Test Access Point)** między PLC a switchem (Profitap ProfiShark 1G, Allegro Network NA10G, Garland Tech P1GMS) — pasywny tap, nigdy nie używaj mirror portu na production switchu, jitter zafałszuje się
- **Druga opcja:** jeśli nie mają Państwo TAP, port mirror na managed switchu (Cisco IE-4000, Hirschmann RSP, Siemens SCALANCE XR-528) — działa dla packet content analysis, **nie działa** dla precyzyjnej jitter analysis
- Wireshark 4.4+ z **dissectorem Profinet** (built-in od wersji 3.0)
- Capture filter: `vlan and eth.type == 0x8892` (Profinet EtherType) lub pełny capture i dissect post-hoc
Co mierzyć w Wireshark:
A) Cycle time consistency
Profinet IO RT zwykle ma update time 4 ms (default), 8 ms lub 16 ms. Capture 60 sekund komunikacji między PLC a problematycznym device. W Wireshark: `Statistics → I/O Graphs`, filter `pn_rt && ip.src == <PLC IP> && ip.dst == <device IP>`. Oczekiwany interwał między pakietami = update time ± 100 μs jitter.
Realny przykład z linii 2026-03 (klient w PL — automotive Tier 1): - Update time configured: 4 ms - Measured: 4 ms ± 200 μs base, ale **co 12-18 sekund spike 18-32 ms** trwający 1 pakiet - Watchdog: 3 × 4 ms = 12 ms → spike przekracza watchdog → IO error 16#80B1
B) Frame loss
Profinet RT jest UDP-like (no acknowledgement). Strata 1 frame = natychmiastowy jump cycle counter. Wireshark dissector wyświetli `cycle_counter` w każdym RT frame. Skok w counterze o więcej niż 1 = stracony frame.
Acceptable rate: < 1 lost frame per million (1e-6). Realny problem: > 1 / 100 000 (1e-5) — to widzimy jako „czasem pada komunikacja" dla operatora.
C) Alarm frames
Profinet ma separate alarm channel (acyclic, low-priority). W Wiresharku filter `pn_io.alarm_type` wyświetli device-generated alarms: temperature warnings, module diagnostics, diagnostic alarms. Wielu klientów je ignoruje, bo „PLC dotąd nie poskarżyło się" — ale zawierają ostrzeżenia, które poprzedzają awarię o godziny.
Krok 2 — SIEMENS PRONETA Basic (free tool, którego nikt nie używa)
PRONETA Basic jest do swobodnego pobrania (Siemens Support Portal, ID 67460624) i robi 80 % tego, co płatny SINEC NMS — za darmo. Trzy kluczowe funkcje:
- **Topology scan** przez LLDP — buduje rzeczywisty topology graph aktualnej sieci i porównuje go z planowaną topology z projektu TIA Portal. Cable miscount, wrong port assignment, unknown device (na przykład zapomniany notebook technika lub nieautoryzowany switch) odsłania się natychmiast.
- **IO Test** — podłącza się jako Profinet IO controller (emuluje PLC) i robi read/write test bezpośrednio na module IO bez PLC w drodze. Jeśli IO test działa, a PLC nie, problem tkwi w PLC config lub w drodze komunikacji PLC → device. Jeśli IO test nie działa, problem tkwi w device lub kablu do device.
- **Diagnostic readout** — odczytuje wersje firmware, konfigurację IP, device name i alarm history ze wszystkich dostępnych device naraz. 30 % „niedeterministycznych" problemów Profinet tkwi w duplikatach device name — przeskanują Państwo i zobaczą dwa moduły z taką samą nazwą w sieci.
Krok 3 — Jitter measurement (LLDP i TSN ready check)
Dla Profinet IRT (motion, sub-ms) jitter < 1 μs to wymóg. Dla Profinet RT (1–8 ms cycle) jitter < 100 μs jest acceptable. Pomiar:
- **PROFITap ProfiShark 1G** z precise timestamp (sub-microsecond)
- **Synesis InterMatch** lub **Allegro Network Multimeter** (dedicated industrial NTM)
- **Lightweight:** Linux box z PTP-aware NIC (Intel I210, I225) i `tcpdump -i eth0 -j adapter_unsynced` — timestamps z HW NIC clocka
Najczęstsza przyczyna wysokiego jittera (> 500 μs): unmanaged switch w drodze Profinet. Zwykły D-Link / TP-Link / Netgear switch nie ma QoS dla EtherType Profinet 0x8892 — RT frames stoją w kolejce za bulk traffic (firmware download, configuration upload, video feed z kamery).
Historia, która zdarzyła się naprawdę — 50 ms cycle → 200 ms cycle
Klient (zakład spożywczy, Warszawa, napełniarka linii ciśnieniowych, 5-line setup). Skarga: jedna linia z pięciu ma cycle time 200 ms zamiast designed 50 ms. PLC: Siemens S7-1517F. IO: ET 200SP z 6 modułami IO + 2 servoaxes przez Profinet IRT.
**Pierwsze 3 dni — fałszywe drogi:** - Diagnostyka TIA Portal: żadnych ERROR, ale `IO update time exceeded` warnings - Update firmware PLC + modułów IO: brak postępu - Wymiana modułu IO przypuszczalnie „wolnego": brak postępu
**4. dzień — Wireshark + PRONETA:**
PRONETA topology scan pokazał: - 4 linie mają topologię liniową: PLC → IO1 → IO2 → IO3 → IO4 (przez built-in 2-port switche w modułach IO) - **Piąta linia ma topologię STAR przez zewnętrzny switch** SCALANCE X-208 — artefakt historyczny z czasu, gdy linia miała dodatkowy workstation
Wireshark capture na piątej linii: - Update time 50 ms ± 80 ms (!) — masywny jitter - Frame loss: 4 / 10 000 (1e-3.4) — nieużywalne dla IRT motion - Bulk traffic: 200 Mbps RTSP video stream z kamery HMI przez ten sam switch
**Przyczyna:** SCALANCE X-208 miał **default QoS config** (FIFO, no priority for Profinet EtherType). Przy obciążeniu video stream RT frames Profinet czekały w kolejce. Operator wcześniej dopuścił video monitoring „tylko do testowania" — 6 miesięcy wcześniej.
**Rozwiązanie:** 30-minutowa zmiana w Web Based Management switcha: 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
**Wynik:** cycle time z powrotem na 50 ms ± 2 ms. Jitter < 80 μs. OEE linii wzrosła z 71 % na 88 % tydzień po fixie.
Ten konkretny problem PLC firmware update **nigdy by nie naprawił** — błąd był w konfiguracji switcha 3 hopy oddalonego od PLC. Bez Wireshark capture + PRONETA topology poszukiwanie przyczyny trwałoby kolejnych 2–4 tygodnie i utraciło dodatkowych €40–60k w utraconej produkcji.
Pięć miejsc, których nikt nie kontroluje
1. **Kabel poza PROFINET Type A/B/C** (ISO/IEC 11801). Zwykły office CAT-6 w hali z przemiennikami częstotliwości degraduje szybciej niż papier. Industrial Type C z double shield kosztuje €40–80 więcej per linka — inwestycja, która wraca przy pierwszym dropie. 2. **Shield zakończony na obu końcach** w różnych ground potential punktach → ground loop → induced voltage 5–50 V → corrupted frames. Shield Profinet idzie tylko na jednym końcu. 3. **Switch QoS misconfiguration** — default QoS na managed switchu często NIE jest właściwy dla Profinet EtherType 0x8892. Trzeba explicit enable Profinet QoS preset lub ręcznie skonfigurować VLAN + 802.1p priority class 6. 4. **Wrong Conformance Class.** Profinet ma trzy klasy (CC-A basic, CC-B device replacement + diagnostics, CC-C isochronous IRT). Dla IRT motion musi być **każdy** switch w drodze CC-C. Tańszy switch CC-B w drodze IRT = inconsistent cycle time. 5. **Device name duplicates.** Profinet identyfikuje device przez `device_name` (DNS-like), nie MAC. Zastępczy moduł IO z nieprzesłaną nazwą = duplicate w sieci = arbitralny frame routing = random failures.
Praktyczny playbook — 4 godziny na diagnostykę
Przy problemach Profinet:
1. **(30 min)** PRONETA Basic topology scan. Porównaj z projektem TIA Portal. Zidentyfikuj różnice. 2. **(45 min)** Wireshark capture 5 minut na problematycznym segmencie przez TAP lub mirror port. Filter `pn_rt`. Analiza cycle time consistency, frame loss, alarm frames. 3. **(30 min)** PRONETA IO Test na problematycznym device. Działa? Problem tkwi w PLC config. Nie działa? Problem tkwi w device lub drodze do niego. 4. **(60 min)** Switch management — sprawdź QoS, priority, conformance class wszystkich switchy w drodze. Sprawdź okablowanie (Type A/B/C), shield termination, środowisko EMC. 5. **(45 min)** Reproduce + verify. Po identyfikacji domniemanej przyczyny — zmienić, ponownie zmierzyć, porównać przed / po.
To doprowadzi Państwa do 90 % problemów Profinet. Dla pozostałych 10 % (TSN, advanced motion sync, multi-vendor inter-op) trzeba SIEMENS SINEC NMS (paid, €4 000–8 000 rocznie) lub vendor support — ale te 10 % opłaca się mieć z roboty zewnętrznego eksperta zamiast własnego zespołu.
---
*Wykonujemy diagnostykę Profinet, network auditing i migrację TSN dla linii produkcyjnych w PL/CZ/SK. Pierwsza konsultacja (90 min) na Państwa konkretnym problemie prawdopodobnie odsłoni Państwu 1–2 ze wspomnianych pięciu miejsc — lub przynajmniej powie, która z trzech warstw (cable / switch / device) zasługuje na dalsze badanie.*