Wenn ein absoluter Allen-Bradley-842E-EtherNet/IP-Encoder verstummt, lautet die intuitive Erfassungsanforderung: „Trace nach N unbeantworteten ENIP-Anfragen stoppen.“ Dieses Denkmodell lässt sich problemlos auf Kontaktplanlogik übertragen, jedoch nicht auf Wireshark, tcpdump oder die meisten Erfassungs-Engines in Geräten. Diese Tools werten Einschlussfilter auf vorhandenen Frames aus. Ein stummer Encoder erzeugt keine UDP/2222-Class-1-Frames, auf die der Filter zutreffen könnte; daher gibt es nichts, worauf der Stopp ausgelöst werden kann. Das Diagnoseproblem ist die Erkennung des Ausbleibens, nicht die Übereinstimmung mit einer Signatur.

Erfassen Sie kontinuierlich auf UDP 2222 und vergleichen Sie anschließend die beobachteten Encoder-Frames mit der RPI-Berechnung – warten Sie nicht auf einen negativen Trigger, den der Analyzer nicht ausdrücken kann.

Geltungsbereich und Ports

Dieser Ablauf deckt die in 842E-UM001 dokumentierten Varianten 842E-SIP, 842E-MIP, 842E-DIP und M12 ab. Bestätigen Sie die Firmware auf der Encoder-Webseite unter Diagnostics → Device Information. Laufzeit-I/O verwendet CIP Class 1 auf UDP-Port 2222; explizite Nachrichten verwenden die EtherNet/IP-Kapselung über TCP/UDP 44818. Erfassungsprofile sollten beide aktivieren, bei Untersuchungen des Ausbleibens liegt der Schwerpunkt jedoch auf den von den Baugruppen erzeugten/empfangenen 2222-Frames.

Warum Trigger für das Ausbleiben fehlschlagen

Anzeige-Filter sind boolesche Prädikate, die auf jeden Frame angewendet werden. Ein Filter wie (udp.port == 2222) && (eth.src == <842E_MAC>) behält Encoder-Frames bei, sobald sie eintreffen. Wenn sie nicht eintreffen, wird das Prädikat nie wahr. Für die Erfassung von „vier Anfragen ohne Antworten“ wäre ein statusübergreifender Zustand über mehrere Frames erforderlich, den Standard-Erfassungsprogramme nicht speichern. Modulediagnose-Registerkarten in Studio 5000, Gerätestatistiken in FactoryTalk Linx und die Analyse nach der Erfassung können diesen Zustand abbilden.

Workaround 1: Ringpuffer und anschließende Zählung

1. Spiegeln Sie den Switch-Port des Encoders auf eine Analyzer-NIC.
2. Erfassen Sie UDP 2222 in einem Ringpuffer (beispielsweise fünf Dateien mit jeweils 40–50 MB).
3. Öffnen Sie die pcap-Datei und filtern Sie nach der Encoder-MAC-Adresse sowie UDP 2222.
4. Vergleichen Sie die Frame-Anzahl mit observation_time / RPI. Abweichungen von mehr als etwa 5 % sollten untersucht werden.

tcpdump -i eth0 -w capture.pcap udp port 2222
# Wireshark-Anzeige: eth.addr == <842E_MAC> && udp.port == 2222

Workaround 2: RPI-ausgerichtete Zeitfenster

Richten Sie die Erfassungsfenster an ganzzahligen Vielfachen der Encoder-RPI aus, damit der Puffer vollständige I/O-Austauschvorgänge enthält. Bei einer RPI von 10 ms sollte ein 10-Sekunden-Fenster etwa 1000 Class-1-Frames enthalten, wenn die Verbindung fehlerfrei ist. Lücken von mehr als drei RPI-Intervallen in der Spalte „Sekunden seit dem vorherigen Frame“ sind bei der Auswertung die praktische Stoppbedingung.

CIP-Status und Switch-Zähler

Führen Sie regelmäßig Get_Attribute_Single-Lesevorgänge am CIP-Identity-Objekt Klasse 0x01, Instanz 1, Attribut 6 (Status) durch. Änderungen an den Bits Owned oder Configured zeigen an, dass die Class-1-Verbindung abgebrochen ist – üblicherweise nach drei verpassten RPIs. Fragen Sie unabhängig davon ifOutUcastPkts des verwalteten Switches am Encoder-Port ab; ein unveränderter Zähler über mehr als 3 × RPI bestätigt das Ausbleiben ohne pcap-Datei.

Vorgehensweise vor Ort und Fallstricke

Überprüfen Sie IP-Adresse, RPI und Baugruppeninstanzen (Standardeinstellungen: erzeugt 0x04 / empfangen 0x01) anhand der Logix-Modulkonfiguration. Prüfen Sie die Link-LEDs, erfassen Sie sechzig Sekunden lang Daten, zählen Sie die Frames und versuchen Sie anschließend einen CIP-Reset, wenn die Anzahl null beträgt. Wenn der Datenverkehr nach dem Reset wieder einsetzt, aber weiterhin RPI-Zeitpunkte verpasst, deutet dies auf Kabelstörungen, einen Spannungsabfall an der M12-Versorgung oder eine doppelte IP-Adresse hin. Anhaltendes Ausbleiben nach einem Aus- und Einschalten weist auf die Ethernet-PHY hin – ersetzen Sie den Encoder. Verschwenden Sie keine Zeit damit, einen „Stopp bei keiner Antwort“-Trigger zu erstellen; der Analyzer kann dies nicht ausdrücken. Halten Sie Encoder- und Controller-Ersatzgeräte an die PLC- und PAC-Standards des Werks angepasst, wenn ein Gerät vor Ort ausfällt.