Když absolutní enkodér Allen-Bradley 842E EtherNet/IP přestane komunikovat, intuitivní požadavek na zachycení zní: „zastav trasování po N nezodpovězených požadavcích ENIP“. Tento mentální model se dobře hodí pro žebříkovou logiku, ale ne pro Wireshark, tcpdump ani většinu zařízení pro zachytávání provozu. Tyto nástroje vyhodnocují filtry zahrnutí u rámců, které existují. Mlčící enkodér nevytváří žádné rámce UDP/2222 Class 1, které by filtr mohl zachytit, takže není na čem zastavit. Diagnostickým problémem je detekce nepřítomnosti, nikoli hledání shody se signaturou.

Zachytávejte provoz nepřetržitě na UDP 2222 a poté porovnejte pozorované rámce enkodéru s výpočtem RPI — nečekejte na negativní spouštěč, který analyzátor nedokáže vyjádřit.

Rozsah a porty

Tento postup se týká variant 842E-SIP, 842E-MIP, 842E-DIP a M12 popsaných v dokumentu 842E-UM001. Firmware ověřte na webové stránce enkodéru v části Diagnostics → Device Information. Provozní I/O používá CIP Class 1 na UDP portu 2222; explicitní zprávy používají zapouzdření EtherNet/IP na TCP/UDP portu 44818. Profily zachytávání by měly povolit oba porty, ale při hledání příčin ticha se zaměřte na sestavy produced/consumed na portu 2222.

Proč spouštěče nepřítomnosti selhávají

Zobrazovací filtry jsou booleovské predikáty aplikované na každý rámec. Filtr jako (udp.port == 2222) && (eth.src == <842E_MAC>) zachová rámce enkodéru, když dorazí. Když nedorazí, predikát se nikdy nevyhodnotí jako pravdivý. Udržování stavu „čtyři požadavky bez jediné odpovědi“ vyžaduje stav napříč rámci, který standardní nástroje pro zachytávání neuchovávají. Karty diagnostiky modulu v Studio 5000, statistiky zařízení FactoryTalk Linx a analýza po zachycení jsou nástroje, které tento stav dokážou vyjádřit.

Alternativní postup 1: kruhová vyrovnávací paměť a následné počítání

1. Zrcadlete port přepínače enkodéru na síťové rozhraní analyzátoru.
2. Zachytávejte UDP 2222 do kruhové vyrovnávací paměti (například pěti souborů o velikosti 40–50 MB).
3. Otevřete soubor pcap a filtrujte podle MAC adresy enkodéru a UDP 2222.
4. Porovnejte počet rámců s hodnotou observation_time / RPI. Odchylky větší než přibližně 5 % vyžadují prověření.

tcpdump -i eth0 -w capture.pcap udp port 2222
# Zobrazovací filtr Wiresharku: eth.addr == <842E_MAC> && udp.port == 2222

Alternativní postup 2: okna zarovnaná s RPI

Zarovnejte okna zachytávání na celočíselné násobky RPI enkodéru, aby vyrovnávací paměť obsahovala úplné výměny I/O. Při RPI 10 ms by okno o délce 10 sekund mělo při zdravém připojení obsahovat přibližně 1000 rámců Class 1. Mezery delší než tři intervaly RPI ve sloupci „sekundy od předchozího rámce“ představují při kontrole praktickou podmínku k zastavení.

Alternativní postup 3: stav CIP a čítače přepínače

Provádějte pravidelné čtení Get_Attribute_Single proti objektu CIP Identity třídy 0x01, instance 1, atributu 6 (Status). Změny bitů Owned nebo Configured signalizují výpadek připojení Class 1 — běžně po třech zmeškaných RPI. Nezávisle na tom dotazujte na spravovaném přepínači ifOutUcastPkts na portu enkodéru; neměnící se čítač po dobu delší než 3 × RPI potvrdí ticho i bez souboru pcap.

Postup v provozu a úskalí

Ověřte IP adresu, RPI a instance sestav (výchozí produced 0x04 / consumed 0x01) podle konfigurace modulu Logix. Zkontrolujte stavové LED linky, zachytávejte po dobu šedesáti sekund, spočítejte rámce a teprve poté se při nulovém počtu pokuste o reset CIP. Provoz, který se po resetu obnoví, ale dál vynechává body RPI, ukazuje na rušení kabelu, pokles napájení M12 nebo duplicitní IP adresu. Trvalé ticho po vypnutí a zapnutí napájení ukazuje na ethernetovou fyzickou vrstvu — enkodér vyměňte. Neztrácejte čas vytvářením spouštěče „zastavit při žádné odpovědi“; analyzátor jej nedokáže vyjádřit. Při poruše jednotky v provozu udržujte náhradní enkodéry a řídicí jednotky v souladu se standardy závodu pro PLC a PAC.