Klient pošle screenshot SIMATIC Diagnostics buffera: „PROFINET IO: communication error 16#80B1, slot 3 module 2". PLC obnoví komunikáciu po 200 ms, cyklus tak-tak prejde, ale prediction-time čísla sa zhoršili a OEE klesla o 4 % oproti minulému mesiacu. Otázka: čo je zle?
Odpoveď, ktorú dostane od väčšiny integrátorov: „skontrolovať PLC firmvér, prípadne vymeniť IO modul." Toto je strategia, ako stratiť 3 týždne a €4 000 v servisných hodinách bez nájdenia príčiny. Skutočná Profinet diagnostika sa nerobí v TIA Portal — robí sa v Wiresharku, v topology view (LLDP) a v switch managemente. Tento článok je playbook, ako sa dostať k príčine v 2–4 hodinách namiesto v 2–3 týždňoch.
Štyri vrstvy, kde sa chyba môže schovať
Pri Profinet RT problémoch je 95 % chýb v jednej z týchto vrstiev:
1. **Fyzická vrstva** — kábel, konektor, shield, EMC interference, dĺžka segmentu 2. **Switch / topology layer** — QoS, priority, port konfigurácia, conformance class 3. **Device layer** — IO modul, firmware verzia, device name, IP konfigurácia 4. **Protocol layer** — RT class (1 / 2 / 3), update time, watchdog, GSDML mismatch
Klient sa pozerá iba na 3. a 4. — TIA Portal mu povie čo PLC vidí. Skutočná diagnostika začína na 1. a 2.
Krok 1 — Wireshark capture na Profinet segmente
Bez Wireshark capture nemá zmysel hádať. Setup:
- **TAP (Test Access Point)** medzi PLC a switch (Profitap ProfiShark 1G, Allegro Network NA10G, Garland Tech P1GMS) — pasívne tap, nikdy nepoužívaj mirror port na production switchi, jitter sa skreslí
- **Druhá voľba:** ak nemáte TAP, port mirror na managed switchi (Cisco IE-4000, Hirschmann RSP, Siemens SCALANCE XR-528) — funguje pre packet content analysis, **nefunguje** pre presnú jitter analysis
- Wireshark 4.4+ s **Profinet dissectorom** (built-in od verzie 3.0)
- Capture filter: `vlan and eth.type == 0x8892` (Profinet EtherType) alebo plný capture a dissect post-hoc
Čo merať v Wireshark:
A) Cycle time consistency
Profinet IO RT bežne má update time 4 ms (default), 8 ms, alebo 16 ms. Capture 60 sekúnd komunikácie medzi PLC a problémovým device. V Wireshark: `Statistics → I/O Graphs`, filter `pn_rt && ip.src == <PLC IP> && ip.dst == <device IP>`. Očakávaný interval medzi paketmi = update time ± 100 μs jitter.
Reálny príklad z linky 2026-03 (klient v SR — automotive Tier 1): - Update time configured: 4 ms - Measured: 4 ms ± 200 μs base, ale **každých 12-18 sekúnd spike 18-32 ms** trvajúci 1 paket - Watchdog: 3 × 4 ms = 12 ms → spike presahuje watchdog → IO error 16#80B1
B) Frame loss
Profinet RT je UDP-like (no acknowledgement). Strata 1 framu = okamžitý jump cycle counter. Wireshark dissector zobrazí `cycle_counter` v každom RT frame. Skoč v counter-i o viac ako 1 = stratený frame.
Acceptable rate: < 1 lost frame per million (1e-6). Reálny problém: > 1 / 100 000 (1e-5) — to vidíme ako „občas padne komunikácia" pre operátora.
C) Alarm frames
Profinet má separate alarm channel (acyclic, low-priority). V Wireshark filter `pn_io.alarm_type` zobrazí device-generated alarms: temperature warnings, module diagnostics, diagnostic alarms. Týmito veľa klientov ignoruje, lebo „PLC sa zatiaľ neposťažovalo" — ale obsahujú varovania, ktoré predchádzajú výpadku o hodiny.
Krok 2 — SIEMENS PRONETA Basic (free tool, ktorý nikto nepoužíva)
PRONETA Basic je voľne stiahnuteľný (Siemens Support Portal, ID 67460624) a robí 80 % toho, čo platený SINEC NMS — zadarmo. Tri kľúčové funkcie:
- **Topology scan** cez LLDP — postaví skutočný topology graph aktuálnej siete a porovná ho s plánovanou topology z TIA Portal projektu. Cable miscount, wrong port assignment, unknown device (napríklad zabudnutý notebook technika alebo neautorizovaný switch) sa odhalí okamžite.
- **IO Test** — pripojí sa ako Profinet IO controller (emuluje PLC) a urobí read/write test priamo na IO modul bez PLC v ceste. Ak IO test funguje a PLC nie, problém je v PLC config alebo v komunikačnej ceste PLC → device. Ak IO test nefunguje, problém je v device alebo kábli k device.
- **Diagnostic readout** — vyčíta firmware verzie, IP konfiguráciu, device name a alarm history zo všetkých dostupných device naraz. 30 % „nedeterministických" Profinet problémov je v duplikátoch device name — skenujte a uvidíte dva moduly s rovnakým menom v sieti.
Krok 3 — Jitter measurement (LLDP a TSN ready check)
Pre Profinet IRT (motion, sub-ms) je jitter < 1 μs požiadavka. Pre Profinet RT (1–8 ms cycle) je jitter < 100 μs acceptable. Mierenie:
- **PROFITap ProfiShark 1G** s precise timestamp (sub-microsecond)
- **Synesis InterMatch** alebo **Allegro Network Multimeter** (dedicated industrial NTM)
- **Lightweight:** Linux box s PTP-aware NIC (Intel I210, I225) a `tcpdump -i eth0 -j adapter_unsynced` — timestamps zo HW NIC clocku
Najčastejšia príčina vysokého jitter-a (> 500 μs): unmanaged switch v Profinet ceste. Bežný D-Link / TP-Link / Netgear switch nemá QoS pre Profinet EtherType 0x8892 — RT frames stoja vo fronte za bulk traffic-om (firmware download, configuration upload, video feed z kamery).
Príbeh, ktorý sa stal naozaj — 50 ms cycle → 200 ms cycle
Klient (potravinársky závod, Bratislava, plnič tlakových liniek, 5-line setup). Sťažnosť: jedna linka z piatich má cycle time 200 ms namiesto designed 50 ms. PLC: Siemens S7-1517F. IO: ET 200SP s 6 IO moduly + 2 servoaxes cez Profinet IRT.
**Prvé 3 dni — falošné cesty:** - TIA Portal diagnostics: žiadne ERROR, ale `IO update time exceeded` warnings - Firmware update PLC + IO moduly: žiadny posun - Výmena IO modulu predpokladaného „pomalého": žiadny posun
**4. deň — Wireshark + PRONETA:**
PRONETA topology scan ukázal: - 4 linky majú line topology: PLC → IO1 → IO2 → IO3 → IO4 (cez built-in 2-port switches v IO moduloch) - **Piata linka má STAR topology cez externý switch** SCALANCE X-208 — historický artefakt z času, keď linka mala dodatočný workstation
Wireshark capture na piatej linke: - Update time 50 ms ± 80 ms (!) — masívny jitter - Frame loss: 4 / 10 000 (1e-3.4) — nepoužiteľné pre IRT motion - Bulk traffic: 200 Mbps RTSP video stream z HMI kamery cez ten istý switch
**Príčina:** SCALANCE X-208 mal **default QoS config** (FIFO, no priority for Profinet EtherType). Pri video stream záťaži Profinet RT frames čakali vo fronte. Operátor predtým povolil video monitoring „len na testovanie" — 6 mesiacov predtým.
**Riešenie:** 30-minútová zmena v Web Based Management switche: 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
**Výsledok:** cycle time späť na 50 ms ± 2 ms. Jitter < 80 μs. OEE linky vzrastlo z 71 % na 88 % týždeň po fixe.
Tento konkrétny problém by PLC firmware update **nikdy neopravil** — chyba bola v switch konfigurácii o 3 hopy vzdialenej od PLC. Bez Wireshark capture + PRONETA topology by hľadanie príčiny trvalo ďalšie 2–4 týždne a stratilo by ďalších €40–60k v ušlej výrobe.
Päť miest, ktoré nikto nekontroluje
1. **Kábel mimo PROFINET Type A/B/C** (ISO/IEC 11801). Bežný office CAT-6 v hale s frekvenčnými meničmi degraduje rýchlejšie ako papier. Industrial Type C s double shield stojí €40–80 navyše per linka — investícia, ktorá sa vráti pri prvom dropp-e. 2. **Shield ukončený na obidvoch koncoch** v rôznych ground potential bodoch → ground loop → induced voltage 5–50 V → corrupted frames. Profinet shield ide iba na jednom konci. 3. **Switch QoS misconfiguration** — default QoS na managed switche často NIE je správny pre Profinet EtherType 0x8892. Treba explicitne enable Profinet QoS preset, alebo manuálne nakonfigurovať VLAN + 802.1p priority class 6. 4. **Wrong Conformance Class.** Profinet má tri triedy (CC-A basic, CC-B device replacement + diagnostics, CC-C isochronous IRT). Pre IRT motion musí byť **každý** switch v ceste CC-C. Lacnejší CC-B switch v IRT ceste = inconsistent cycle time. 5. **Device name duplicates.** Profinet identifikuje device cez `device_name` (DNS-like), nie MAC. Náhradný IO modul s neuploadnutým menom = duplicate v sieti = arbitrarný frame routing = random failures.
Praktický playbook — 4 hodiny na diagnostiku
Pri Profinet problémoch:
1. **(30 min)** PRONETA Basic topology scan. Porovnaj s TIA Portal projektom. Identifikuj rozdiely. 2. **(45 min)** Wireshark capture 5 minút na problémovom segmente cez TAP alebo mirror port. Filter `pn_rt`. Analyzuj cycle time consistency, frame loss, alarm frames. 3. **(30 min)** PRONETA IO Test na problémovom device. Funguje? Problém je v PLC config. Nefunguje? Problém je v device alebo cesty k nemu. 4. **(60 min)** Switch management — skontroluj QoS, priority, conformance class všetkých switches v ceste. Skontroluj kabeláž (Type A/B/C), shield termination, EMC environment. 5. **(45 min)** Reproduce + verify. Po identifikácii predpokladanej príčiny — zmeniť, znova merať, porovnať pred / po.
Toto vás dostane k 90 % Profinet problémov. Pre zvyšných 10 % (TSN, advanced motion sync, multi-vendor inter-op) treba SIEMENS SINEC NMS (paid, €4 000–8 000 ročne) alebo vendor support — ale tých 10 % stojí za to mať z roboty externý expert namiesto vlastného tímu.
---
*Robíme Profinet diagnostiku, network auditing a TSN migráciu pre výrobné linky v SR/CZ/PL. Prvá konzultácia (90 min) na vašom konkrétnom probléme vám pravdepodobne odhalí 1–2 zo spomínaných piatich miest — alebo aspoň povie, ktorá z troch vrstiev (cable / switch / device) si zaslúži ďalšie investigácie.*