Apabila pengekod mutlak Allen-Bradley 842E EtherNet/IP tidak lagi memberikan respons, permintaan tangkapan yang terlintas biasanya ialah “hentikan jejak selepas N permintaan ENIP tidak berjawab.” Model pemikiran ini sesuai dengan logik tangga, tetapi tidak sesuai dengan Wireshark, tcpdump atau kebanyakan enjin tangkapan perkakas. Alat-alat tersebut menilai penapis kemasukan pada bingkai yang wujud. Pengekod yang senyap tidak menghasilkan bingkai UDP/2222 Kelas 1 untuk dipadankan oleh penapis, jadi tiada apa-apa yang boleh mencetuskan pemberhentian. Masalah diagnostik ini ialah pengesanan ketiadaan, bukannya pemadanan tandatangan.

Tangkap secara berterusan pada UDP 2222, kemudian bandingkan bingkai pengekod yang diperhatikan dengan pengiraan RPI—jangan tunggu pencetus negatif yang tidak dapat dinyatakan oleh penganalisis.

Skop dan port

Aliran kerja ini merangkumi varian 842E-SIP, 842E-MIP, 842E-DIP dan M12 yang didokumenkan dalam 842E-UM001. Sahkan perisian tegar daripada halaman web pengekod di bawah Diagnostics → Device Information. I/O masa jalan menggunakan CIP Kelas 1 pada port UDP 2222; pemesejan eksplisit menggunakan enkapsulasi EtherNet/IP pada TCP/UDP 44818. Profil tangkapan hendaklah mengaktifkan kedua-duanya, tetapi penyiasatan keadaan senyap memberi tumpuan kepada himpunan yang dihasilkan/digunakan pada 2222.

Mengapa pencetus ketiadaan gagal

Penapis paparan ialah predikat Boolean yang digunakan pada setiap bingkai. Penapis seperti (udp.port == 2222) && (eth.src == <842E_MAC>) mengekalkan bingkai pengekod apabila bingkai tersebut tiba. Apabila bingkai itu tidak tiba, predikat tersebut tidak pernah menjadi benar. Untuk mengekalkan keadaan “empat permintaan dengan sifar respons” diperlukan keadaan merentas bingkai yang tidak disimpan oleh utiliti tangkapan standard. Tab diagnostik modul dalam Studio 5000, statistik peranti FactoryTalk Linx dan analisis selepas tangkapan ialah alat yang boleh menyatakan keadaan tersebut.

Penyelesaian 1: penimbal bergilir kemudian kira

1. Cerminkan port suis pengekod ke NIC penganalisis.
2. Tangkap UDP 2222 ke dalam penimbal gelang (contohnya lima fail berukuran 40–50 MB).
3. Buka pcap dan tapis berdasarkan MAC pengekod serta UDP 2222.
4. Bandingkan bilangan bingkai dengan observation_time / RPI. Penyimpangan melebihi kira-kira 5% wajar disiasat.

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

Penyelesaian 2: tetingkap sejajar RPI

Selaraskan tetingkap tangkapan dengan gandaan integer RPI pengekod supaya penimbal mengandungi pertukaran I/O yang lengkap. Pada RPI 10 ms, tetingkap 10 saat sepatutnya mengandungi kira-kira 1000 bingkai Kelas 1 jika sambungan sihat. Jurang yang melebihi tiga selang RPI dalam lajur “seconds since previous frame” ialah syarat pemberhentian praktikal semasa semakan.

Penyelesaian 3: status CIP dan pembilang suis

Keluarkan bacaan Get_Attribute_Single secara berkala terhadap CIP Identity Object kelas 0x01, tika 1, atribut 6 (Status). Perubahan pada bit Owned atau Configured menunjukkan sambungan Kelas 1 terputus—biasanya selepas tiga RPI terlepas. Secara berasingan, tinjau ifOutUcastPkts suis terurus pada port pengekod; pembilang yang tidak berubah selama lebih daripada 3 × RPI mengesahkan keadaan senyap tanpa pcap.

Prosedur lapangan dan perangkap

Sahkan IP, RPI dan tika himpunan (lalai dihasilkan 0x04 / digunakan 0x01) berbanding konfigurasi modul Logix. Sahkan LED pautan, tangkap selama enam puluh saat, kira bingkai, kemudian cuba tetapan semula CIP jika bilangannya sifar. Trafik yang disambung semula selepas tetapan semula tetapi terus terlepas RPI menunjukkan hingar kabel, penurunan voltan kuasa M12 atau IP pendua. Keadaan senyap yang berterusan selepas kitar kuasa menuding kepada PHY Ethernet—ganti pengekod. Jangan bazirkan masa untuk mencipta pencetus “hentikan apabila tiada respons”; penganalisis tidak dapat menyatakannya. Pastikan pengekod dan unit ganti pengawal selaras dengan piawaian PLC dan PAC kilang apabila unit gagal di lapangan.