De klant stuurt een screenshot van de SIMATIC Diagnostics-buffer: "PROFINET IO: communication error 16#80B1, slot 3 module 2". De PLC herstelt na 200 ms, de cyclus haalt het net, maar de prediction-time-getallen verslechteren en de OEE is met 4 % gedaald ten opzichte van de vorige maand. Wat is er mis?
Het antwoord dat hij van de meeste integratoren krijgt: "PLC-firmware checken, eventueel IO-module vervangen." Dit is een strategie om 3 weken en € 4 000 aan servicedeklaring te verliezen zonder de oorzaak te vinden. Echte Profinet-diagnostiek doe je niet in TIA Portal — die doe je in Wireshark, in de topology view (LLDP) en in switch-management. Dit artikel is een playbook om in 2–4 uur de oorzaak te vinden in plaats van 2–3 weken.
Vier lagen waar de fout zich kan verstoppen
Bij Profinet RT-problemen zit 95 % van de fouten in een van deze lagen:
- 1.Fysieke laag — kabel, connector, shield, EMC-interferentie, segmentlengte
- 2.Switch / topology layer — QoS, prioriteit, poortconfiguratie, conformance class
- 3.Device layer — IO-module, firmware-versie, device name, IP-configuratie
- 4.Protocol layer — RT class (1 / 2 / 3), update time, watchdog, GSDML-mismatch
De klant kijkt alleen naar 3 en 4 — TIA Portal vertelt wat de PLC ziet. Echte diagnostiek begint bij 1 en 2.
Stap 1 — Wireshark-capture op het Profinet-segment
Zonder Wireshark-capture is gokken zinloos. Setup:
- TAP (Test Access Point) tussen PLC en switch (Profitap ProfiShark 1G, Allegro Network NA10G, Garland Tech P1GMS) — passieve tap, gebruik nooit een mirror port op een productie-switch; de jitter wordt vertekend
- Tweede keuze: geen TAP? Dan port mirror op een managed switch (Cisco IE-4000, Hirschmann RSP, Siemens SCALANCE XR-528) — werkt voor packet content-analyse, werkt niet voor nauwkeurige jitter-analyse
- Wireshark 4.4+ met Profinet-dissector (ingebouwd vanaf versie 3.0)
- Capture filter:
vlan and eth.type == 0x8892(Profinet EtherType) of een volledige capture met dissect achteraf
Wat te meten in Wireshark:
A) Cycle time consistency
Profinet IO RT heeft typisch een update time van 4 ms (default), 8 ms of 16 ms. Vang 60 seconden communicatie tussen PLC en problematische device op. In Wireshark: Statistics → I/O Graphs, filter pn_rt && ip.src == <PLC IP> && ip.dst == <device IP>. Verwacht interval tussen pakketten = update time ± 100 μs jitter.
Reëel voorbeeld van een lijn uit 2026-03 (klant in SK — automotive Tier 1): - Update time geconfigureerd: 4 ms - Gemeten: 4 ms ± 200 μs basis, maar elke 12-18 seconden een spike van 18-32 ms die 1 pakket duurt - Watchdog: 3 × 4 ms = 12 ms → spike overschrijdt watchdog → IO error 16#80B1
B) Frame loss
Profinet RT is UDP-like (geen acknowledgement). Een verloren frame = onmiddellijke sprong in de cycle counter. De Wireshark-dissector toont cycle_counter in elk RT-frame. Een sprong in de counter van meer dan 1 = verloren frame.
Acceptabele rate: < 1 lost frame per miljoen (1e-6). Reëel probleem: > 1/100 000 (1e-5) — dat zien we als "soms valt de communicatie weg" voor de operator.
C) Alarm frames
Profinet heeft een separate alarm-channel (acyclic, low-priority). In Wireshark toont het filter pn_io.alarm_type device-generated alarms: temperature warnings, module diagnostics, diagnostic alarms. Veel klanten negeren dit, omdat "de PLC nog niet heeft geklaagd" — maar er zitten waarschuwingen in die uren vóór een uitval ontstaan.
Stap 2 — SIEMENS PRONETA Basic (gratis tool die niemand gebruikt)
PRONETA Basic is gratis te downloaden (Siemens Support Portal, ID 67460624) en doet 80 % van wat het betaalde SINEC NMS doet — gratis. Drie sleutelfuncties:
- Topology scan via LLDP — bouwt de werkelijke topology graph van het huidige netwerk en vergelijkt deze met de geplande topology uit het TIA Portal-project. Verkeerd kabeltal, foutieve poortassignatie, unknown device (bv. een vergeten laptop van een technicus of een ongeautoriseerde switch) wordt onmiddellijk gevonden.
- IO Test — sluit aan als Profinet IO-controller (emuleert de PLC) en doet een read/write-test rechtstreeks op de IO-module zonder de PLC in het pad. Werkt IO-test wel en de PLC niet, dan zit het probleem in de PLC-config of in het PLC → device-pad. Werkt IO-test niet, dan zit het in het device of de kabel naar het device.
- Diagnostic readout — leest firmware-versies, IP-configuratie, device-name en alarm history van alle bereikbare devices in één keer. 30 % van "niet-deterministische" Profinet-problemen zijn duplicate device names — scan en u ziet twee modules met dezelfde naam in het netwerk.
Stap 3 — Jitter measurement (LLDP en TSN-ready check)
Voor Profinet IRT (motion, sub-ms) is jitter < 1 μs vereist. Voor Profinet RT (1–8 ms cyclus) is jitter < 100 μs acceptabel. Meting:
- PROFITap ProfiShark 1G met precise timestamp (sub-microsecond)
- Synesis InterMatch of Allegro Network Multimeter (dedicated industrial NTM)
- Lightweight: een Linux-box met een PTP-aware NIC (Intel I210, I225) en
tcpdump -i eth0 -j adapter_unsynced— timestamps van de HW NIC-clock
De meest voorkomende oorzaak van hoge jitter (> 500 μs): een unmanaged switch in het Profinet-pad. Een gangbare D-Link / TP-Link / Netgear-switch heeft geen QoS voor de Profinet EtherType 0x8892 — RT-frames staan in de wachtrij achter bulk traffic (firmware-download, configuratie-upload, video-feed van een camera).
Verhaal dat echt is gebeurd — 50 ms cyclus → 200 ms cyclus
Klant (levensmiddelenbedrijf, Bratislava, vullijn voor drukbussen, setup met 5 lijnen). Klacht: één lijn van de vijf heeft een cycle time van 200 ms in plaats van designed 50 ms. PLC: Siemens S7-1517F. IO: ET 200SP met 6 IO-modules + 2 servoaxes via Profinet IRT.
Eerste 3 dagen — valse paden:
- TIA Portal-diagnostics: geen ERROR, maar wel IO update time exceeded-warnings
- Firmware-update PLC + IO-modules: geen verschuiving
- Vervanging van een vermoedelijk "trage" IO-module: geen verschuiving
Dag 4 — Wireshark + PRONETA:
PRONETA-topology-scan toonde: - 4 lijnen hebben line topology: PLC → IO1 → IO2 → IO3 → IO4 (via built-in 2-port switches in de IO-modules) - De vijfde lijn heeft een STAR-topologie via een externe switch SCALANCE X-208 — een historisch artefact uit een tijd dat de lijn een extra workstation had
Wireshark-capture op de vijfde lijn: - Update time 50 ms ± 80 ms (!) — massieve jitter - Frame loss: 4/10 000 (1e-3.4) — onbruikbaar voor IRT-motion - Bulk traffic: 200 Mbps RTSP-videostream van een HMI-camera via dezelfde switch
Oorzaak: de SCALANCE X-208 had de default QoS-config (FIFO, no priority for Profinet EtherType). Bij videostream-load stond Profinet RT in de wachtrij. De operator had eerder videomonitoring "alleen voor test" aangezet — 6 maanden geleden.
Oplossing: 30 minuten Web Based Management op de switch:
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
Resultaat: cycle time terug op 50 ms ± 2 ms. Jitter < 80 μs. OEE van de lijn steeg van 71 % naar 88 % in de week na de fix.
Dit specifieke probleem zou een PLC firmware-update nooit hebben opgelost — de fout zat in een switch-configuratie 3 hops verwijderd van de PLC. Zonder Wireshark-capture + PRONETA-topology zou het zoeken naar de oorzaak nog 2–4 weken hebben geduurd en € 40–60 k aan gederfde productie kosten.
Vijf plekken die niemand checkt
- 1.Kabel buiten PROFINET Type A/B/C (ISO/IEC 11801). Gewone office CAT-6 in een hal met frequentie-omvormers degradeert sneller dan papier. Industrial Type C met dubbele shield kost € 40–80 extra per lijn — een investering die zich terugverdient bij de eerste drop.
- 2.Shield aan beide zijden afgemonteerd in punten met verschillend grondpotentiaal → ground loop → induced voltage 5–50 V → corrupted frames. De Profinet-shield gaat slechts aan één zijde.
- 3.Switch QoS-misconfiguratie — de default-QoS op een managed switch is vaak NIET correct voor Profinet EtherType 0x8892. Schakel expliciet de Profinet QoS-preset in, of configureer handmatig VLAN + 802.1p priority class 6.
- 4.Wrong Conformance Class. Profinet heeft drie klassen (CC-A basic, CC-B device replacement + diagnostics, CC-C isochronous IRT). Voor IRT-motion moet elke switch in het pad CC-C zijn. Een goedkopere CC-B-switch in een IRT-pad = inconsistente cycle time.
- 5.Duplicaten van device names. Profinet identificeert een device via
device_name(DNS-like), niet via MAC. Een reserve-IO-module zonder geüploade naam = duplicate in het netwerk = willekeurige frame-routing = random failures.
Praktisch playbook — 4 uur diagnostiek
Bij Profinet-problemen:
- 1.(30 min) PRONETA Basic topology scan. Vergelijk met het TIA Portal-project. Identificeer verschillen.
- 2.(45 min) Wireshark-capture 5 minuten op het problematische segment via TAP of mirror port. Filter
pn_rt. Analyseer cycle time consistency, frame loss, alarm frames. - 3.(30 min) PRONETA IO Test op het problematische device. Werkt? Probleem zit in de PLC-config. Werkt niet? Probleem zit in het device of pad ernaartoe.
- 4.(60 min) Switch-management — check QoS, prioriteit, conformance class van alle switches in het pad. Check bekabeling (Type A/B/C), shield termination, EMC-omgeving.
- 5.(45 min) Reproduce + verify. Na identificatie van de vermoedelijke oorzaak — wijzig, opnieuw meten, vergelijk voor/na.
Dit brengt u bij 90 % van de Profinet-problemen. Voor de overige 10 % (TSN, advanced motion-sync, multi-vendor inter-op) hebt u SIEMENS SINEC NMS (betaald, € 4 000–8 000 per jaar) of vendor-support nodig — maar voor die 10 % is het de moeite waard om een externe expert in te schakelen in plaats van het eigen team.
---
*Wij doen Profinet-diagnostiek, netwerkaudits en TSN-migratie voor productielijnen in NL/BE/DE/SK/CZ. Het eerste consult (90 min) op uw concrete probleem onthult waarschijnlijk 1–2 van de genoemde vijf plekken — of geeft op zijn minst aan welke van de drie lagen (kabel / switch / device) verder onderzoek verdient.*