เมื่อเอนโคดเดอร์แอบโซลูต Allen-Bradley 842E EtherNet/IP หยุดส่งข้อมูล สัญชาตญาณแรกมักเป็นการตั้งคำขอจับข้อมูลว่า “หยุดการติดตามหลังจากไม่มีการตอบกลับคำขอ ENIP จำนวน N รายการ” แนวคิดนี้สอดคล้องกับลอจิกแบบแลดเดอร์ แต่ไม่สอดคล้องกับ Wireshark, tcpdump หรือเอนจินจับข้อมูลของอุปกรณ์ส่วนใหญ่ เครื่องมือเหล่านี้จะประเมินตัวกรองการรวมข้อมูลกับเฟรมที่มีอยู่เท่านั้น เอนโคดเดอร์ที่เงียบจะไม่สร้างเฟรม UDP/2222 Class 1 ให้ตัวกรองตรวจจับ จึงไม่มีสิ่งใดให้หยุดการจับข้อมูล ปัญหาด้านการวินิจฉัยคือการตรวจจับการไม่มีข้อมูล ไม่ใช่การจับคู่ลายเซ็น

จับข้อมูลบน UDP 2222 อย่างต่อเนื่อง จากนั้นเปรียบเทียบเฟรมเอนโคดเดอร์ที่ตรวจพบกับการคำนวณ RPI—อย่ารอทริกเกอร์เชิงลบที่เครื่องวิเคราะห์ไม่สามารถแสดงได้

ขอบเขตและพอร์ต

เวิร์กโฟลว์นี้ครอบคลุมรุ่น 842E-SIP, 842E-MIP, 842E-DIP และรุ่น M12 ที่ระบุไว้ใน 842E-UM001 ให้ยืนยันเฟิร์มแวร์จากหน้าเว็บของเอนโคดเดอร์ภายใต้ Diagnostics → Device Information การทำงานของ I/O ใช้ CIP Class 1 บนพอร์ต UDP 2222 ส่วนการส่งข้อความแบบ explicit ใช้การห่อหุ้ม EtherNet/IP บน TCP/UDP 44818 โปรไฟล์การจับข้อมูลควรเปิดใช้งานทั้งสองพอร์ต แต่การตรวจสอบกรณีเงียบควรเน้นแอสเซมบลี produced/consumed บนพอร์ต 2222

เหตุใดทริกเกอร์การไม่มีข้อมูลจึงล้มเหลว

ตัวกรองการแสดงผลคือนิพจน์บูลีนที่นำไปใช้กับแต่ละเฟรม ตัวกรองเช่น (udp.port == 2222) && (eth.src == <842E_MAC>) จะเก็บเฟรมจากเอนโคดเดอร์เมื่อเฟรมเหล่านั้นมาถึง แต่เมื่อไม่มีเฟรมเข้ามา นิพจน์ดังกล่าวจะไม่เป็นจริง การติดตามสถานะ “มีคำขอ 4 รายการโดยไม่มีการตอบกลับ” จำเป็นต้องใช้สถานะข้ามเฟรม ซึ่งเครื่องมือจับข้อมูลมาตรฐานไม่มีการเก็บไว้ แท็บการวินิจฉัยโมดูลใน Studio 5000 สถิติอุปกรณ์ของ FactoryTalk Linx และการวิเคราะห์หลังการจับข้อมูลคือเครื่องมือที่สามารถแสดงสถานะดังกล่าวได้

วิธีแก้ชั่วคราว 1: ใช้บัฟเฟอร์แบบวนรอบแล้วนับ

1. ทำมิเรอร์พอร์ตสวิตช์ของเอนโคดเดอร์ไปยัง NIC ของเครื่องวิเคราะห์
2. จับข้อมูล UDP 2222 ลงในบัฟเฟอร์แบบริง (เช่น ไฟล์ขนาด 40–50 MB จำนวน 5 ไฟล์)
3. เปิด pcap แล้วกรองด้วย MAC ของเอนโคดเดอร์ร่วมกับ UDP 2222
4. เปรียบเทียบจำนวนเฟรมกับ observation_time / RPI หากแตกต่างเกินประมาณ 5% ควรตรวจสอบเพิ่มเติม

tcpdump -i eth0 -w capture.pcap udp port 2222
# การแสดงผลของ Wireshark: eth.addr == <842E_MAC> && udp.port == 2222

วิธีแก้ชั่วคราว 2: ใช้ช่วงเวลาที่สอดคล้องกับ RPI

จัดแนวช่วงเวลาการจับข้อมูลให้เป็นจำนวนเท่าของ RPI ของเอนโคดเดอร์ เพื่อให้บัฟเฟอร์มีการแลกเปลี่ยน I/O ที่ครบถ้วน ที่ RPI 10 มิลลิวินาที ช่วงเวลา 10 วินาทีควรมีเฟรม Class 1 ประมาณ 1000 เฟรม หากการเชื่อมต่อทำงานปกติ ช่องว่างที่มากกว่า 3 ช่วง RPI ในคอลัมน์ “วินาทีนับจากเฟรมก่อนหน้า” ถือเป็นเงื่อนไขหยุดเชิงปฏิบัติระหว่างการตรวจสอบ

วิธีแก้ชั่วคราว 3: สถานะ CIP และตัวนับของสวิตช์

ส่งคำสั่งอ่าน Get_Attribute_Single เป็นระยะไปยัง CIP Identity Object คลาส 0x01 อินสแตนซ์ 1 แอตทริบิวต์ 6 (Status) การเปลี่ยนแปลงของบิต Owned หรือ Configured แสดงว่าการเชื่อมต่อ Class 1 หลุด ซึ่งมักเกิดขึ้นหลังพลาด RPI 3 ครั้ง นอกจากนี้ ให้โพลค่า ifOutUcastPkts ของพอร์ตเอนโคดเดอร์บนสวิตช์ที่มีการจัดการอย่างอิสระ หากตัวนับไม่เพิ่มขึ้นนานเกิน 3 × RPI จะยืนยันการเงียบได้โดยไม่ต้องมี pcap

ขั้นตอนภาคสนามและข้อควรระวัง

ตรวจสอบ IP, RPI และอินสแตนซ์ของแอสเซมบลี (ค่าเริ่มต้น produced 0x04 / consumed 0x01) ให้ตรงกับการกำหนดค่าโมดูล Logix ตรวจสอบไฟ LED แสดงลิงก์ จับข้อมูลเป็นเวลา 60 วินาที นับเฟรม แล้วจึงลองรีเซ็ต CIP หากจำนวนเป็นศูนย์ ทราฟฟิกที่กลับมาหลังรีเซ็ตแต่ยังพลาด RPI อย่างต่อเนื่อง ชี้ไปที่สัญญาณรบกวนในสายเคเบิล แรงดันไฟ M12 ตก หรือ IP ซ้ำ หากยังเงียบหลังปิดแล้วเปิดเครื่อง ปัญหาน่าจะอยู่ที่ PHY ของอีเทอร์เน็ต—ให้เปลี่ยนเอนโคดเดอร์ อย่าเสียเวลากำหนดทริกเกอร์ “หยุดเมื่อไม่มีการตอบกลับ” เพราะเครื่องวิเคราะห์ไม่สามารถแสดงเงื่อนไขนี้ได้ เมื่ออุปกรณ์ขัดข้องในภาคสนาม ควรจัดเตรียมเอนโคดเดอร์สำรองและคอนโทรลเลอร์สำรองให้สอดคล้องกับมาตรฐาน PLC และ PAC ของโรงงาน