PROFINET hibakeresés lépésről lépésre

A PROFINET az ipari Ethernet-alapú kommunikáció legelterjedtebb szabványa Európában — a Siemens világában gyakorlatilag alapértelmezett. Robusztus, de ha „leesik” egy IO-eszköz, a hibakeresés sokszor kapkodássá válik: kábelt cserélnek, eszközt resetelnek, és közben nem derül ki az ok. Ez a cikk egy szisztematikus, fentről lefelé haladó workflow-t ad — LED-leolvasástól a fizikai rétegig.

A hibás PROFINET-interfész gyakran gazdaságosan javítható: az IEM műhelyében komponens-szinten dolgozunk, a részleteket a PLC javítás oldalunk foglalja össze.

1. Olvassa le a LED-eket (BF / SF)

Minden PROFINET IO-device-on van legalább két állapot-LED. Ezek a leggyorsabb első diagnózis — mielőtt bármilyen szoftvert elindítana:

• BF (Bus Fault) — piros, folyamatos: nincs kapcsolat / nincs konfiguráció. A controller nem éri el az eszközt egyáltalán (kábel, link, vagy név-probléma).
• BF — piros, villog: van link, de nincs kommunikáció — tipikusan a device name nem egyezik, vagy a controller más topológiát vár.
• SF / DIAG (System Fault) — piros: az eszköz elérhető, de diagnosztikai alarm aktív (modul hiányzik, csatorna-hiba, túlmelegedés stb.).
• Mindkettő kialudt, csak a zöld RUN ég: az eszköz rendben kommunikál.

A pontos LED-séma gyártó- és modul-függő (ET 200SP, ET 200MP, harmadik gyártós eszközök), ezért mindig a kéznél lévő eszköz kézikönyve a mérvadó — de a BF = kommunikáció, SF = diagnosztika logika szinte univerzális.

2. Device name és IP-konfliktus (DCP)

A PROFINET nem IP-cím, hanem device name alapján azonosítja az eszközöket. A controller indításkor a DCP (Discovery and Configuration Protocol) segítségével megkeresi az „elvárt” nevet, és csak ezután osztja ki az IP-t. Ha a név hibás, az eszköz villogó BF-fel áll.

Tipikus név-hibák

• Üres név csere után: egy kicserélt eszköz gyárilag névtelen — kézzel vagy „device replacement without exchangeable medium” funkcióval kell nevet adni.
• Elgépelt vagy eltérő név: a projektben ventilator-1, az eszközön ventilator1 — a PROFINET név kötött szintaxisú (csak kisbetű, szám, kötőjel, pont; nem kezdődhet „port-xyz” mintával).
• Duplikált név: két eszköz ugyanazzal a névvel — mindkettő villogó hibát ad, és véletlenszerűen „táncolnak” az online listában.
• IP-konfliktus: egy másik (akár nem-PROFINET) eszköz ugyanazt az IP-t használja a hálózaton.

3. Topológia-hiba (LLDP szomszédok)

A PROFINET az LLDP (Link Layer Discovery Protocol) segítségével ismeri a fizikai topológiát: melyik eszköz melyik portja melyik szomszédhoz csatlakozik. Ha a projektben be van állítva egy elvárt topológia, és a valóság ettől eltér — mert valaki más portba dugta a kábelt — a controller hibát jelez, vagy a „device replacement” funkció nem működik.

• Port-csere: X1 P1 helyett X1 P2-be dugott kábel — topológia-mismatch.
• Áthúzott kábel: line topológiánál egy eszköz kihagyása az utána lévő összes eszközt leveszi.
• Idegen switch a vonalban: egy nem-menedzselt switch „elnyeli” az LLDP-t, és a szomszéd-felismerés megszakad.

A TIA Portal Online & Diagnostics „Topology” nézete grafikusan kirajzolja az elvárt és a tényleges huzalozást — az eltérés azonnal látszik.

4. Port-statisztika: discard és CRC

Ha a kommunikáció „néha” akad meg (sporadikus station failure), a port-statisztika a kulcs. Minden PROFINET-port számlálja a hibás kereteket:

Számláló	Mit jelent	Tipikus ok
CRC / FCS errors	A keret megérkezett, de sérült (checksum hibás)	Kábel, csatlakozó, EMC zaj
Discarded frames	Eldobott keret (puffer-telítődés vagy hiba)	Túlterhelt switch, hibás PHY
Link down count	Hányszor szakadt meg a link	Laza csatlakozó, vibrációs törés

Ha egy port CRC-számlálója folyamatosan nő az adott portra kötött kábel/szomszéd a gyanús. Ha a link-down count nő, az fizikai kontakt-probléma (rezgő gép, oxidált M12 csatlakozó).

5. Update time és reduction ratio

Minden PROFINET IO-device-nak van egy update time-ja (pl. 1, 2, 4…512 ms) — ennyente cseréli a controller az I/O adatokat. Ezt a „send clock” és a „reduction ratio” szorzata adja. Ha túl agresszívre állítják (sok eszköz 1 ms-on), a hálózat vagy a CPU túlterhelődik, és sporadikus kiesés jön.

• Watchdog / accepted update cycles: alapból 3 elmaradt ciklus után az eszköz hibára vált. Túl rövid watchdog + ingadozó hálózat = véletlenszerű leesés.
• Túl sok eszköz alacsony update time-on: oszlopozza el — nem minden I/O igényel 1 ms-ot, egy hőmérséklet-modulnak 64 ms is bőven elég.

6. Diagnostic alarm (modul / csatorna)

Az SF/DIAG LED diagnosztikai alarmot jelez — az eszköz kommunikál, de panaszkodik. A TIA Portal „Device diagnostics” nézete szövegesen megmutatja az okot:

• Module missing / wrong module: a slotban nincs modul, vagy más típusú van, mint a projektben.
• Channel error: szakadt vezeték (wire break), rövidzár, vagy mérési tartomány túllépés egy analóg csatornán.
• Power supply error: a load-feszültség (pl. 24 V) hiányzik egy potenciál-csoporton.
• Maintenance required / demanded: előrejelző figyelmeztetés — még működik, de karbantartást igényel.

7. IRT szinkronizáció és jitter

Motion-alkalmazásoknál (szervo-tengelyek, nyomtatás, csomagolás) gyakran IRT (Isochronous Real-Time) fut, ahol a ciklus szinkronizációja kritikus. Itt a hibák más jellegűek:

• Sync master kiesés: ha a sync-master eszköz leesik, az egész isochronous domain elveszti a szinkront.
• Nem IRT-képes switch a domainben: az IRT a tervezett topológiát és IRT-képes hardvert követel — egy „sima” switch megtöri.
• Jitter a tengelyek között: ha a tengelyek „ugrálnak”, a szinkronizációs hibát a domain-beállításban és a topológiában keresse.

8. Kábel, csatlakozó és EMC

A fizikai réteg a hibák másik nagy forrása — különösen ipari környezetben:

• PROFINET kábel és csatlakozó: használjon dedikált, zöld ipari Ethernet kábelt és megfelelő RJ45 / M12 (D-kódolt) csatlakozót. A „maradék irodai patch-kábel” gyakori hibaforrás.
• Maximális szegmenshossz: rézkábelnél ~100 m két aktív eszköz között — e fölött száloptika kell.
• EMC / zavarforrások: ne vezesse a busz-kábelt frekvenciaváltó motorkábele mellett párhuzamosan; tartson távolságot, vagy keresztezze 90°-ban. A nem megfelelő árnyékolás-földelés CRC-hibák tömegét okozza.
• Vibráció: mozgó gépeknél a sima RJ45 idővel kilazul — itt M12 push-pull vagy reteszelt csatlakozó indokolt.

9. A 9 lépéses workflow összefoglalva

1. LED-leolvasás — BF (kommunikáció) vagy SF (diagnosztika)? Ez azonnal két ágra bontja a keresést.
2. Online lista — PRONETA vagy TIA Portal „Accessible devices”: látszik-e az eszköz egyáltalán?
3. Device name & IP — egyezik-e a projekttel? Nincs duplikáció vagy IP-konfliktus?
4. Topológia — a tényleges huzalozás megegyezik-e az elvárttal (port-szintű LLDP)?
5. Port-statisztika — nő-e valamelyik porton a CRC / discard / link-down?
6. Diagnostic alarm — ha SF aktív, mi a konkrét üzenet (modul, csatorna, táp)?
7. Update time / watchdog — nem túl agresszív-e a ciklus-idő a hálózat méretéhez?
8. Fizikai réteg — kábel típus, hossz, csatlakozó, EMC-elválasztás, árnyékolás-földelés.
9. Dokumentálás — rögzítse a számláló-értékeket „előtte/utána”, hogy a sporadikus hiba megszűnése igazolható legyen.

Eszközök és szoftver

• Siemens PRONETA — ingyenes, telepítés nélkül futtatható: topológia-szkennelés, device name kiosztás, LED blink, alap-diagnosztika. Gyors első ránézésre ideális.
• TIA Portal — Online & Diagnostics — a teljes diagnosztika: device diagnostics, topology compare, port-statisztika, modul/csatorna-szintű alarm.
• Wireshark + PROFINET dissector — alacsony-szintű paket-elemzés DCP, alarm és RT-keretek szintjén — mély, sporadikus hibákhoz.
• Kábel-/vonal-tesztelő — ipari Ethernet-tanúsító műszer a fizikai réteg (csillapítás, áthallás, hossz) ellenőrzésére.