Ketika encoder absolut Allen-Bradley 842E EtherNet/IP tidak lagi merespons, permintaan capture yang spontan biasanya adalah “hentikan trace setelah N permintaan ENIP yang tidak dijawab.” Model mental tersebut cocok diterapkan pada logika ladder, tetapi tidak cocok diterapkan pada Wireshark, tcpdump, atau sebagian besar mesin capture appliance. Alat-alat tersebut mengevaluasi filter inklusi pada frame yang ada. Encoder yang tidak merespons tidak menghasilkan frame UDP/2222 Class 1 untuk dicocokkan oleh filter, sehingga tidak ada pemicu untuk menghentikan capture. Masalah diagnostiknya adalah mendeteksi ketiadaan, bukan mencocokkan tanda tangan.

Lakukan capture terus-menerus pada UDP 2222, lalu bandingkan frame encoder yang teramati dengan perhitungan RPI—jangan menunggu pemicu negatif yang tidak dapat dinyatakan oleh analyzer.

Cakupan dan port

Alur kerja ini mencakup varian 842E-SIP, 842E-MIP, 842E-DIP, dan M12 yang didokumentasikan dalam 842E-UM001. Konfirmasikan firmware dari halaman web encoder di bagian Diagnostics → Device Information. I/O runtime menggunakan CIP Class 1 pada port UDP 2222; explicit messaging menggunakan enkapsulasi EtherNet/IP pada TCP/UDP 44818. Profil capture sebaiknya mengaktifkan keduanya, tetapi investigasi kondisi tidak merespons berfokus pada assembly produced/consumed pada 2222.

Mengapa pemicu ketiadaan gagal

Filter tampilan adalah predikat Boolean yang diterapkan pada setiap frame. Filter seperti (udp.port == 2222) && (eth.src == <842E_MAC>) mempertahankan frame encoder saat frame tersebut tiba. Ketika frame tidak tiba, predikat tersebut tidak pernah bernilai benar. Mempertahankan status “empat permintaan tanpa respons” memerlukan state lintas-frame yang tidak disimpan oleh utilitas capture standar. Tab diagnostik modul di Studio 5000, statistik perangkat FactoryTalk Linx, dan analisis pasca-capture adalah alat yang dapat menyatakan kondisi tersebut.

Solusi 1: buffer bergulir lalu hitung

1. Mirror port switch encoder ke NIC analyzer.
2. Lakukan capture UDP 2222 ke dalam ring buffer (misalnya lima file berukuran 40–50 MB).
3. Buka pcap dan gunakan filter pada MAC encoder serta UDP 2222.
4. Bandingkan jumlah frame dengan observation_time / RPI. Penyimpangan lebih dari sekitar 5% perlu diselidiki.

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

Solusi 2: jendela yang selaras dengan RPI

Selaraskan jendela capture dengan kelipatan bilangan bulat dari RPI encoder agar buffer berisi pertukaran I/O yang lengkap. Pada RPI 10 ms, jendela 10 detik seharusnya berisi sekitar 1000 frame Class 1 jika koneksi sehat. Kesenjangan yang lebih besar dari tiga interval RPI pada kolom “seconds since previous frame” merupakan kondisi penghentian praktis selama peninjauan.

Solusi 3: status CIP dan penghitung switch

Kirim pembacaan Get_Attribute_Single secara berkala terhadap CIP Identity Object class 0x01, instance 1, attribute 6 (Status). Perubahan pada bit Owned atau Configured menunjukkan bahwa koneksi Class 1 terputus—umumnya setelah tiga RPI terlewat. Secara terpisah, lakukan polling terhadap ifOutUcastPkts pada port encoder di managed switch; penghitung yang tidak berubah selama lebih dari 3 × RPI mengonfirmasi kondisi tidak ada traffic tanpa pcap.

Prosedur lapangan dan hal-hal yang perlu dihindari

Verifikasi IP, RPI, dan instance assembly (default produced 0x04 / consumed 0x01) terhadap konfigurasi modul Logix. Konfirmasikan LED link, lakukan capture selama enam puluh detik, hitung frame, lalu coba reset CIP jika jumlahnya nol. Traffic yang kembali setelah reset tetapi terus melewatkan titik RPI mengarah pada gangguan kabel, penurunan daya M12, atau IP duplikat. Kondisi tetap tidak merespons setelah siklus daya mengindikasikan masalah pada Ethernet PHY—ganti encoder. Jangan membuang waktu membuat pemicu “hentikan jika tidak ada respons”; analyzer tidak dapat menyatakannya. Selaraskan stok encoder dan controller cadangan dengan standar PLC dan PAC di pabrik ketika unit gagal di lapangan.