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.*