Khi bộ mã hóa tuyệt đối Allen-Bradley 842E EtherNet/IP ngừng phản hồi, phản xạ đầu tiên thường là yêu cầu bắt gói “dừng trace sau N yêu cầu ENIP không có phản hồi”. Mô hình tư duy này phù hợp với logic thang, nhưng không phù hợp với Wireshark, tcpdump hoặc hầu hết các công cụ bắt gói trên thiết bị chuyên dụng. Các công cụ đó đánh giá bộ lọc bao gồm trên những frame đang tồn tại. Một bộ mã hóa im lặng không tạo ra frame UDP/2222 Class 1 nào để bộ lọc khớp, vì vậy không có gì để dừng. Vấn đề chẩn đoán ở đây là phát hiện sự vắng mặt, không phải khớp chữ ký.

Hãy bắt gói liên tục trên UDP 2222, sau đó so sánh các frame của bộ mã hóa quan sát được với phép tính RPI—đừng chờ một điều kiện kích hoạt phủ định mà bộ phân tích không thể biểu đạt.

Phạm vi và các cổng

Quy trình này áp dụng cho các biến thể 842E-SIP, 842E-MIP, 842E-DIP và M12 được ghi chép trong 842E-UM001. Xác nhận firmware từ trang web của bộ mã hóa tại Diagnostics → Device Information. I/O thời gian chạy sử dụng CIP Class 1 trên cổng UDP 2222; nhắn tin tường minh sử dụng cơ chế đóng gói EtherNet/IP trên TCP/UDP 44818. Các cấu hình bắt gói nên bật cả hai, nhưng việc điều tra trạng thái im lặng tập trung vào các assembly được tạo/tiêu thụ trên 2222.

Vì sao các điều kiện kích hoạt sự vắng mặt không hoạt động

Bộ lọc hiển thị là các vị từ Boolean được áp dụng cho từng frame. Một bộ lọc như (udp.port == 2222) && (eth.src == <842E_MAC>) giữ lại các frame của bộ mã hóa khi chúng đến. Khi chúng không đến, vị từ không bao giờ trở thành đúng. Việc duy trì trạng thái “bốn yêu cầu không có phản hồi” đòi hỏi trạng thái liên frame mà các tiện ích bắt gói tiêu chuẩn không lưu giữ. Các tab chẩn đoán module trong Studio 5000, thống kê thiết bị FactoryTalk Linx và phân tích sau khi bắt gói là những công cụ có thể biểu đạt trạng thái đó.

Giải pháp thay thế 1: bộ đệm vòng rồi đếm

1. Phản chiếu cổng switch của bộ mã hóa sang một NIC phân tích.
2. Bắt UDP 2222 vào bộ đệm vòng (ví dụ: năm tệp, mỗi tệp 40–50 MB).
3. Mở tệp pcap và lọc theo MAC của bộ mã hóa cùng UDP 2222.
4. So sánh số frame với observation_time / RPI. Sai lệch vượt khoảng 5% cần được điều tra.

tcpdump -i eth0 -w capture.pcap udp port 2222
# Hiển thị Wireshark: eth.addr == <842E_MAC> && udp.port == 2222

Giải pháp thay thế 2: các cửa sổ căn theo RPI

Căn các cửa sổ bắt gói theo các bội số nguyên của RPI bộ mã hóa để bộ đệm chứa các lần trao đổi I/O hoàn chỉnh. Với RPI 10 ms, một cửa sổ 10 giây phải chứa khoảng 1000 frame Class 1 nếu kết nối hoạt động bình thường. Khoảng trống lớn hơn ba khoảng RPI trong cột “số giây kể từ frame trước” là điều kiện dừng thực tế trong quá trình xem xét.

Giải pháp thay thế 3: trạng thái CIP và bộ đếm của switch

Định kỳ thực hiện các lần đọc Get_Attribute_Single đối với CIP Identity Object class 0x01, instance 1, attribute 6 (Status). Những thay đổi trong các bit Owned hoặc Configured cho thấy kết nối Class 1 đã bị ngắt—thường xảy ra sau ba lần RPI bị bỏ lỡ. Độc lập với việc đó, hãy thăm dò ifOutUcastPkts của switch được quản lý trên cổng bộ mã hóa; bộ đếm không thay đổi trong thời gian dài hơn 3 × RPI xác nhận trạng thái im lặng mà không cần pcap.

Quy trình tại hiện trường và các điểm cần lưu ý

Đối chiếu IP, RPI và các instance assembly (mặc định: produced 0x04 / consumed 0x01) với cấu hình module Logix. Xác nhận đèn LED liên kết, bắt gói trong sáu mươi giây, đếm frame, sau đó thử reset CIP nếu số lượng bằng không. Lưu lượng hoạt động trở lại sau khi reset nhưng vẫn bỏ lỡ các mốc RPI cho thấy nhiễu cáp, sụt áp nguồn M12 hoặc trùng IP. Trạng thái im lặng kéo dài sau khi tắt bật nguồn cho thấy lỗi ở PHY Ethernet—hãy thay bộ mã hóa. Đừng mất thời gian tạo điều kiện kích hoạt “dừng khi không có phản hồi”; bộ phân tích không thể biểu đạt điều đó. Khi một thiết bị hỏng tại hiện trường, hãy duy trì bộ mã hóa dự phòng và bộ điều khiển dự phòng phù hợp với các tiêu chuẩn PLC và PAC của nhà máy.