Lorsqu’un codeur absolu Allen-Bradley 842E EtherNet/IP devient silencieux, la demande de capture instinctive est la suivante : « arrêter la trace après N requêtes ENIP sans réponse ». Ce modèle mental s’applique bien à la logique à relais, mais pas à Wireshark, tcpdump ni à la plupart des moteurs de capture intégrés aux appareils. Ces outils évaluent les filtres d’inclusion sur les trames qui existent. Un codeur silencieux ne produit aucune trame UDP/2222 de classe 1 correspondant au filtre : il n’y a donc rien sur quoi arrêter la capture. Le problème de diagnostic consiste à détecter une absence, et non à rechercher une signature.

Capturez en continu sur UDP 2222, puis comparez les trames observées du codeur aux calculs du RPI — n’attendez pas un déclencheur négatif que l’analyseur ne peut pas exprimer.

Périmètre et ports

Cette procédure couvre les variantes 842E-SIP, 842E-MIP, 842E-DIP et M12 documentées dans 842E-UM001. Vérifiez le micrologiciel depuis la page web du codeur, sous Diagnostics → Device Information. Les E/S d’exécution utilisent CIP de classe 1 sur le port UDP 2222 ; les messages explicites utilisent l’encapsulation EtherNet/IP sur TCP/UDP 44818. Les profils de capture doivent activer les deux, mais les investigations de silence se concentrent sur les assemblages produits/consommés du port 2222.

Pourquoi les déclencheurs d’absence échouent

Les filtres d’affichage sont des prédicats booléens appliqués trame par trame. Un filtre tel que (udp.port == 2222) && (eth.src == <842E_MAC>) conserve les trames du codeur lorsqu’elles arrivent. Lorsqu’elles n’arrivent pas, le prédicat ne devient jamais vrai. Pour maintenir l’état « quatre requêtes sans aucune réponse », il faut un état intertrames que les utilitaires de capture standard ne conservent pas. Les onglets de diagnostic du module dans Studio 5000, les statistiques d’appareil de FactoryTalk Linx et l’analyse post-capture permettent d’exprimer cet état.

Solution de contournement 1 : tampon circulaire puis comptage

1. Répliquez le port du commutateur auquel est connecté le codeur vers une carte réseau d’analyse.
2. Capturez le trafic UDP 2222 dans un tampon circulaire (par exemple, cinq fichiers de 40 à 50 Mo).
3. Ouvrez le fichier pcap et filtrez sur l’adresse MAC du codeur ainsi que sur UDP 2222.
4. Comparez le nombre de trames à observation_time / RPI. Les écarts supérieurs à environ 5 % méritent une investigation.

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

Solution de contournement 2 : fenêtres alignées sur le RPI

Alignez les fenêtres de capture sur des multiples entiers du RPI du codeur afin que le tampon contienne des échanges d’E/S complets. Avec un RPI de 10 ms, une fenêtre de 10 secondes devrait contenir environ 1000 trames de classe 1 si la connexion est saine. Lors de l’examen, des intervalles supérieurs à trois périodes de RPI dans la colonne « secondes depuis la trame précédente » constituent la condition pratique d’arrêt.

Solution de contournement 3 : état CIP et compteurs du commutateur

Effectuez périodiquement des lectures Get_Attribute_Single sur la classe 0x01 de l’objet Identity CIP, l’instance 1 et l’attribut 6 (Status). Les changements des bits Owned ou Configured indiquent que la connexion de classe 1 a été interrompue — généralement après trois RPI manqués. En parallèle, interrogez le compteur ifOutUcastPkts du commutateur administrable sur le port du codeur ; un compteur qui reste inchangé pendant plus de 3 × RPI confirme le silence sans fichier pcap.

Procédure sur site et pièges à éviter

Vérifiez l’adresse IP, le RPI et les instances d’assemblage (produit 0x04 / consommé 0x01 par défaut) par rapport à la configuration du module Logix. Vérifiez les voyants de liaison, capturez pendant soixante secondes, comptez les trames, puis tentez une réinitialisation CIP si le nombre est nul. Un trafic qui reprend après la réinitialisation, tout en continuant à manquer des RPI, indique un bruit sur le câble, une chute de tension sur l’alimentation M12 ou une adresse IP en double. Un silence persistant après un cycle de mise hors tension et sous tension met en cause le PHY Ethernet : remplacez le codeur. Ne perdez pas de temps à créer un déclencheur « arrêter en l’absence de réponse » ; l’analyseur ne peut pas l’exprimer. Maintenez des stocks de rechange de codeurs et de contrôleurs conformes aux standards d’usine PLC et PAC lorsqu’une unité tombe en panne sur le terrain.