Захват трафика EtherNet/IP с Allen-Bradley 842E

Ноутбук, подключённый к тому же управляемому коммутатору, что и энкодер Allen-Bradley 842E, не будет автоматически видеть циклический трафик энкодера. Обычно коммутатор пересылает одноадресные кадры только к порту назначения. Поэтому анализатор может почти ничего не показывать, пока контроллер сообщает о тайм-ауте ввода-вывода.

Полезный захват начинается с проверяемой гипотезы неисправности и точки захвата, способной наблюдать соответствующие кадры.

Сформулируйте вопрос до начала сбора пакетов

Опишите симптом в измеримых терминах. Например, это может быть тайм-аут соединения во время определённого перехода машины, прекращение изменения значения энкодера, повторяющееся переподключение или поступление данных о положении позже, чем ожидает контроллер. Запишите код неисправности контроллера, время, показания индикаторов энкодера и состояние порта коммутатора.

Определите, какие данные подтвердят или опровергнут каждую гипотезу. Если нужно выяснить, выходят ли кадры из энкодера, зеркалируйте порт, к которому подключён энкодер. Если нужно проверить, достигают ли они восходящего соединения контроллера, наблюдайте этот канал. Захват только с одной стороны промежуточного коммутатора не всегда позволяет локализовать место потери.

Аппаратные средства для энкодеров представлены в коллекции «Датчики», а управляемые коммутаторы и сетевые адаптеры сгруппированы в разделе «Связь и сети».

Изучите сетевой путь 842E

Rockwell Automation описывает 842E как семейство абсолютных энкодеров EtherNet/IP с двумя портами Ethernet для поддерживаемых линейных топологий и топологий Device Level Ring. Конкретная модель и конфигурация проекта определяют подключение данных, сборку, запрошенный интервал пакетов и особенности диагностики.

Задокументируйте оба физических порта, настройки IP, подключение контроллера, топологию, прошивку и наличие активного Device Level Ring. В линейной топологии кабель или устройство ниже по цепочке могут влиять на трафик через энкодер. В кольце событие топологии добавляет данные, которые необходимо сопоставить с неисправностью соединения.

Не следует предполагать, что порт, расположенный ближе всего к контроллеру, всегда является единственной полезной точкой захвата. Нарисуйте фактический путь, включая порты коммутатора, восходящие соединения, супервизор кольца, медиаконвертеры и любые резервные маршруты.

Выберите неинвазивный метод захвата

Сеанс зеркалирования порта управляемого коммутатора обычно является наименее disruptive-методом. Настройте источником порт энкодера, порт контроллера или восходящее соединение, необходимое согласно гипотезе. В качестве назначения укажите порт анализатора и убедитесь, зеркалирует ли коммутатор входящий, исходящий или оба направления трафика.

Другой вариант — специально предназначенный пассивный сетевой ответвитель, если архитектура и процедура отключения это допускают. Не вставляйте неуправляемый коммутатор или обычный офисный концентратор в работающий контур управления. Такое изменение может повлиять на топологию, качество обслуживания, обработку многоадресного трафика, согласование соединения и время возникновения неисправности.

Используйте выделенный интерфейс анализатора. По возможности отключите ненужные протоколы и службы в соответствии с рабочей процедурой. Анализатор должен только наблюдать, а не объявлять устройства, запрашивать адреса или становиться ещё одним участником сети управления.

Убедитесь, что зеркалирование даёт достоверные данные

Сгенерируйте или найдите один известный кадр и убедитесь, что он появляется на анализаторе. Проверьте, видны ли оба направления, если это необходимо. Сеанс зеркалирования может не включать ошибки физического уровня, отбрасывать пакеты при перегрузке порта назначения или копировать только одно направление.

Сравните скорость порта-источника с пропускной способностью порта назначения зеркалирования. Зеркалирование обоих направлений загруженного гигабитного восходящего соединения в один гигабитный порт может превысить пропускную способность назначения. Сузьте источник или окно захвата, а не предполагайте, что каждый пропуск произошёл в сети управления.

Запишите модель коммутатора, версию прошивки, конфигурацию зеркалирования, исходный порт, порт назначения, поведение VLAN и настройки интерфейса захвата. Без этой записи другой инженер не сможет воспроизвести измерение.

Разделяйте классы трафика EtherNet/IP

EtherNet/IP использует явные сообщения для управления соединениями, конфигурации и диагностики, тогда как циклический ввод-вывод обычно использует транспорт UDP. Обмен данными при обнаружении не доказывает исправность установленного соединения ввода-вывода. Сохраните этапы установления и завершения соединения до и после неисправности, а не только циклические пакеты.

Начните с известных IP-адресов энкодера и контроллера. Затем определите нужное соединение, а не помечайте каждый UDP-кадр как данные энкодера. Стандартные порты EtherNet/IP могут помочь сузить трассировку, но более весомыми доказательствами являются конечные точки, временные характеристики и контекст соединения.

Сохраните данные ARP, топологии и управления коммутатором, относящиеся к событию. Конфликт адресов или переход состояния канала может проявиться за пределами отфильтрованного потока ввода-вывода. Сохраните исходный нефильтрованный захват и используйте фильтры отображения для анализа, чтобы контекст не был безвозвратно удалён.

Анализируйте интервалы RPI и пропуски

Запрошенный интервал пакетов определяет ожидаемую частоту обновления настроенного соединения ввода-вывода. Измерьте интервал между поступлением пакетов в течение нормальной работы и непосредственно в момент неисправности. Ищите пропущенные интервалы, всплески после паузы, повторяющиеся последовательности и закрытие или повторное открытие соединения.

Не считайте каждый пакет, поступивший позже номинального RPI, неисправностью контроллера. Сопоставьте наблюдаемый пропуск с поведением тайм-аута соединения, настроенным в контроллере. Отклонение на несколько микросекунд и отказ продолжительностью в несколько интервалов имеют разное значение.

Постройте график времени поступления пакетов вместе с битом неисправности контроллера, состоянием задачи, событием машины и журналами коммутатора. Если поток пакетов прекращается до появления события потери соединения, следует проверить исходное устройство или путь выше по сети. Если зеркалирование продолжает видеть кадры энкодера, пока контроллер фиксирует тайм-аут, исследуйте оставшуюся часть пути и обработку в контроллере.

Используйте данные коммутатора вместе с трассировкой

Считайте счётчики портов до и после теста. Ошибки CRC или проверки кадра, переходы состояния канала, отброшенные пакеты, изменения скорости и события кольца могут объяснить пропуск пакетов. Анализатор пакетов, подключённый выше неисправного канала, может никогда не получить повреждённые кадры, поскольку коммутатор отбрасывает их.

Проверьте состояние кабеля и разъёмов, экранирование и заземление, радиус изгиба, загрязнение и натяжение. Заменяйте только один контролируемый компонент и только после сохранения исходных данных. Одновременная замена нескольких кабелей и настроек коммутатора лишает возможности определить причину.

Проверьте согласованную скорость и дуплексный режим в соответствии с поддерживаемой конфигурацией устройства. Не принуждайте настройки без консультации с руководствами по энкодеру и коммутатору. Несоответствие может создавать ошибки, зависящие от нагрузки.

Защитите захват и сеть

Ограничьте продолжительность захвата или используйте кольцевой буфер, чтобы диск анализатора не переполнился. Отметьте точное местное и производственное время. Трассировки пакетов могут раскрывать адреса, имена устройств, конфигурацию и поведение процесса, поэтому храните их с надлежащим контролем доступа.

После тестирования удалите конфигурацию зеркалирования и убедитесь, что порт назначения вернулся в предусмотренное состояние. Оставшееся зеркалирование может раскрыть трафик управления неавторизованному устройству или потреблять ресурсы коммутатора.

Никогда не вносите изменения в конфигурацию только на основании трассировки пакетов. Сопоставляйте данные с диагностикой контроллера, индикаторами энкодера, счётчиками коммутатора и воспроизводимым событием машины. Захват фиксирует трафик, но не подтверждает механическое положение и не доказывает точность самого энкодера.

Преобразуйте наблюдения в вывод о неисправности

Кадры прекращаются в обеих точках захвата

Проверьте питание энкодера, его внутреннее состояние, соединение с программой выше по сети и общий канал до первой точки захвата. Убедитесь, не перезапускается ли устройство и не блокируется ли соединение намеренно.

Кадры видны у энкодера, но не на восходящем соединении

Сосредоточьтесь на промежуточном пути через коммутатор, VLAN, событии кольца, ошибках порта, перегрузке или кабельной линии. Повторите проверку с синхронизированными счётчиками, прежде чем менять энкодер.

Кадры достигают пути к контроллеру, но ПЛК фиксирует тайм-аут

Проверьте настроенное соединение, RPI, тайм-аут, загрузку задач контроллера, дублирование адресов и соответствие захваченных пакетов ожидаемому соединению.

Захват пакетов становится ценным, когда контролируются место захвата, время и сетевой контекст. Цель состоит не в создании большого файла Wireshark, а в сборе небольшого объёма доказательств, показывающих, где изменился циклический обмен и какое физическое или конфигурационное событие изменилось одновременно с ним.