ضبط UDP اترنت/IP روی انکودرهای آلن-بردلی 842E
ضبط بستههای UDP در AB842E هنگام نبود پاسخ متوقف نمیشود؛ فیلترها فقط موارد موجود را شامل میشوند. برای جداسازی EtherNet/IP بیپاسخ، از ضبط بافر و زمانبندی ...
وقتی انکودر مطلق Allen-Bradley 842E EtherNet/IP از پاسخگویی بازمیایستد، درخواست معمول برای ضبط این است: «ردیابی را پس از N درخواست ENIP بیپاسخ متوقف کن.» این مدل ذهنی بهخوبی با منطق نردبانی سازگار است، اما با Wireshark، tcpdump یا بیشتر موتورهای ضبط تجهیزات شبکه سازگار نیست. این ابزارها فیلترهای شاملشدن را روی فریمهای موجود ارزیابی میکنند. انکودر خاموش هیچ فریم UDP/2222 Class 1 تولید نمیکند تا فیلتر بتواند آن را تطبیق دهد؛ بنابراین چیزی برای توقف وجود ندارد. مسئله تشخیصی، شناسایی نبودن فریمهاست، نه تطبیق امضا.
بهطور پیوسته روی UDP 2222 ضبط کنید، سپس فریمهای مشاهدهشده انکودر را با محاسبات RPI مقایسه کنید—منتظر یک ماشه منفی که تحلیلگر قادر به بیان آن نیست نمانید.
دامنه و پورتها
این روند کاری مدلهای 842E-SIP، 842E-MIP، 842E-DIP و گونههای M12 را که در 842E-UM001 مستند شدهاند پوشش میدهد. میانافزار را از صفحه وب انکودر، در بخش Diagnostics → Device Information، تأیید کنید. ورودی/خروجی زمان اجرا از CIP Class 1 روی پورت UDP 2222 استفاده میکند؛ پیامرسانی صریح از کپسولهسازی EtherNet/IP روی TCP/UDP 44818 استفاده میکند. پروفایلهای ضبط باید هر دو را فعال کنند، اما بررسی سکوت روی اسمبلیهای تولیدشده/مصرفشده در 2222 متمرکز است.
| پورت | ترافیک | تناوب معمول |
|---|---|---|
| 2222 | ورودی/خروجی ضمنی (تولیدشده/مصرفشده) | RPI، اغلب ۱۰ میلیثانیه |
| 44818 | CIP صریح | درخواستی |
| 67/68 | BOOTP/DHCP | فقط هنگام روشنشدن |
چرا ماشههای نبودن فریم کار نمیکنند
فیلترهای نمایشی، گزارههای بولی هستند که برای هر فریم اعمال میشوند. فیلتری مانند (udp.port == 2222) && (eth.src == <842E_MAC>) هنگام رسیدن فریمهای انکودر، آنها را نگه میدارد. وقتی فریمی نمیرسد، این گزاره هرگز درست نمیشود. نگهداری وضعیت «چهار درخواست با صفر پاسخ» به وضعیت بین فریمها نیاز دارد؛ وضعیتی که ابزارهای استاندارد ضبط حفظ نمیکنند. زبانههای تشخیصی ماژول در Studio 5000، آمار دستگاه در FactoryTalk Linx و تحلیل پس از ضبط، ابزارهایی هستند که میتوانند چنین وضعیتی را بیان کنند.
راهکار ۱: بافر چرخشی و سپس شمارش
- پورت سوئیچ انکودر را به یک کارت شبکه تحلیلگر میرور کنید.
- UDP 2222 را در یک بافر حلقوی ضبط کنید؛ برای مثال، پنج فایل ۴۰ تا ۵۰ مگابایتی.
- فایل pcap را باز کنید و با MAC انکودر بههمراه UDP 2222 فیلتر کنید.
- تعداد فریمها را با observation_time / RPI مقایسه کنید. انحرافهای بیشتر از حدود ۵٪ نیازمند بررسی هستند.
tcpdump -i eth0 -w capture.pcap udp port 2222 # نمای Wireshark: eth.addr == <842E_MAC> && udp.port == 2222
راهکار ۲: پنجرههای همراستا با RPI
پنجرههای ضبط را با مضربهای صحیح RPI انکودر همراستا کنید تا بافر شامل تبادلهای کامل ورودی/خروجی باشد. با RPI برابر ۱۰ میلیثانیه، یک پنجره ۱۰ ثانیهای، در صورت سالمبودن اتصال، باید حدود ۱۰۰۰ فریم Class 1 داشته باشد. در زمان بررسی، فاصلههای بزرگتر از سه بازه RPI در ستون «ثانیهها از فریم قبلی» معیار عملی توقف هستند.
راهکار ۳: وضعیت CIP و شمارندههای سوئیچ
بهصورت دورهای درخواستهای Get_Attribute_Single را برای CIP Identity Object، کلاس 0x01، نمونه 1 و ویژگی 6 (Status) ارسال کنید. تغییر در بیتهای Owned یا Configured نشان میدهد اتصال Class 1 قطع شده است—معمولاً پس از سه RPI از دسترفته. بهطور مستقل، ifOutUcastPkts سوئیچ مدیریتی را در پورت انکودر پایش کنید؛ ثابتماندن شمارنده برای مدتی بیش از 3 × RPI، بدون نیاز به فایل pcap، سکوت را تأیید میکند.
رویه میدانی و نکات مهم
IP، RPI و نمونههای اسمبلی را (پیشفرضهای تولیدشده 0x04 / مصرفشده 0x01) با پیکربندی ماژول Logix تطبیق دهید. چراغهای لینک را بررسی کنید، بهمدت شصت ثانیه ضبط انجام دهید، فریمها را بشمارید و سپس اگر تعداد صفر بود، یک ریست CIP را امتحان کنید. ترافیکی که پس از ریست برمیگردد اما همچنان نقاط RPI را از دست میدهد، به نویز کابل، افت توان M12 یا IP تکراری اشاره دارد. سکوت پایدار پس از خاموش و روشنکردن، بخش PHY اترنت را مظنون میکند—انکودر را تعویض کنید. برای ساختن ماشه «توقف در نبود پاسخ» وقت تلف نکنید؛ تحلیلگر قادر به بیان آن نیست. هنگام خرابی یک واحد در محل، موجودی انکودرها و کنترلرهای جایگزین را با استانداردهای کارخانه برای PLC و PAC هماهنگ نگه دارید.
درباره نویسنده
Mark Townsend | مهندس ارشد اتوماسیون – سیستمهای Allen-Bradley
Mark Townsend مهندس ارشد اتوماسیون است و بیش از ۱۸ سال روی پلتفرمهای Allen-Bradley، از جمله ControlLogix، CompactLogix و SLC-500 قدیمی، تجربه دارد. فعالیت روزمره او شامل منطق RSLogix / Studio 5000 و راهاندازی HMI در FactoryTalk View برای ناوگانهای قدیمی و ترکیبی است.
