Захват UDP-пакетов EtherNet/IP на энкодерах Allen-Bradley 842E
Перехват пакетов UDP AB842E не может остановиться при отсутствии ответов — фильтры только включают пакеты. Используйте буферный захват и синхронизацию циклов...
Когда абсолютный энкодер Allen-Bradley 842E EtherNet/IP перестаёт отвечать, первой приходит в голову такая задача захвата: «остановить трассировку после N запросов ENIP без ответа». Эта модель хорошо подходит для лестничной логики, но не для Wireshark, tcpdump или большинства механизмов захвата в специализированных устройствах. Эти инструменты применяют фильтры включения к существующим кадрам. Если энкодер молчит, он не создаёт кадров Class 1 по UDP/2222, которым можно было бы соответствовать фильтру, поэтому останавливать захват не на чем. Диагностическая задача заключается в обнаружении отсутствия трафика, а не в сопоставлении сигнатур.
Выполняйте непрерывный захват по UDP 2222, а затем сравнивайте наблюдаемые кадры энкодера с расчётами RPI — не ждите отрицательного триггера, который анализатор не может выразить.
Область применения и порты
Эта процедура распространяется на варианты 842E-SIP, 842E-MIP, 842E-DIP и M12, описанные в 842E-UM001. Проверьте версию встроенного ПО на веб-странице энкодера в разделе Diagnostics → Device Information. Рабочий обмен данными I/O использует CIP Class 1 через UDP-порт 2222; явные сообщения используют инкапсуляцию EtherNet/IP через TCP/UDP-порт 44818. Профили захвата должны включать оба порта, однако при расследовании отсутствия трафика основное внимание уделяется создаваемым и принимаемым сборкам по порту 2222.
| Порт | Трафик | Типичная периодичность |
|---|---|---|
| 2222 | Неявный обмен I/O (создаваемые/принимаемые данные) | RPI, часто 10 мс |
| 44818 | Явные сообщения CIP | По запросу |
| 67/68 | BOOTP/DHCP | Только при включении питания |
Почему триггеры отсутствия трафика не работают
Фильтры отображения представляют собой логические предикаты, применяемые к каждому кадру. Фильтр вроде (udp.port == 2222) && (eth.src == <842E_MAC>) оставляет кадры энкодера при их поступлении. Когда кадры не поступают, предикат никогда не становится истинным. Для отслеживания ситуации «четыре запроса без единого ответа» требуется межкадровое состояние, которое стандартные средства захвата не сохраняют. Вкладки диагностики модуля в Studio 5000, статистика устройств FactoryTalk Linx и анализ уже выполненного захвата позволяют выразить такое состояние.
Обходной вариант 1: кольцевой буфер с последующим подсчётом
- Настройте зеркалирование порта коммутатора энкодера на сетевой интерфейс анализатора.
- Выполняйте захват UDP 2222 в кольцевой буфер (например, в пять файлов размером 40–50 МБ).
- Откройте pcap и отфильтруйте трафик по MAC-адресу энкодера и UDP 2222.
- Сравните количество кадров с 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 секунд должно быть около 1000 кадров Class 1, если соединение исправно. При проверке практическим условием остановки является наличие разрывов более чем в три интервала RPI в столбце «секунд с момента предыдущего кадра».
Обходной вариант 3: состояние CIP и счётчики коммутатора
Периодически выполняйте чтение Get_Attribute_Single для объекта CIP Identity class 0x01, instance 1, attribute 6 (Status). Изменения битов Owned или Configured указывают на разрыв соединения Class 1 — обычно после трёх пропущенных циклов RPI. Независимо от этого опрашивайте ifOutUcastPkts управляемого коммутатора на порту энкодера; отсутствие изменений счётчика в течение более чем 3 × RPI подтверждает отсутствие трафика без использования pcap.
Порядок действий на объекте и типичные ошибки
Сверьте IP-адрес, RPI и экземпляры сборок (по умолчанию создаваемая 0x04 / принимаемая 0x01) с конфигурацией модуля Logix. Проверьте светодиоды соединения, выполните захват в течение шестидесяти секунд, подсчитайте кадры, а затем попробуйте выполнить сброс CIP, если количество кадров равно нулю. Если после сброса трафик возобновляется, но циклы RPI по-прежнему пропускаются, причиной могут быть помехи в кабеле, просадка питания M12 или дублирующийся IP-адрес. Постоянное отсутствие трафика после выключения и включения питания указывает на неисправность Ethernet PHY — замените энкодер. Не тратьте время на создание триггера «остановить при отсутствии ответа»: анализатор не может его выразить. При отказе устройства на объекте используйте запасные энкодеры и контроллеры, соответствующие стандартам предприятия для ПЛК и PAC.
Об авторе
Mark Townsend | Старший инженер по автоматизации — системы Allen-Bradley
Mark Townsend — старший инженер по автоматизации с более чем 18-летним опытом работы с платформами Allen-Bradley, включая ControlLogix, CompactLogix и устаревшие системы SLC-500. В его повседневную работу входят разработка логики RSLogix / Studio 5000 и запуск HMI FactoryTalk View на устаревающих и смешанных парках оборудования.