Статьи

Изначально статья задумывалась как перевод и адаптация статьи из обучающего курса ESP32 Masterclass от СircuitLabs, но в дальнейшем было принято решение ее дополнить, но если интересно, можно почитать оригинал. В целом основой можно назвать несколько документов, и я их буду приводить по мере изложения темы, но один приведу в самом начале, это что-то типа презентации - EtherCAT_Communication_EN (документ как бы отсутствует в общем доступе на официальных сайтах, но если помучаться то и его можно найти).

Цели главы

К концу этой главы вы сможете:

• Понимать основные принципы EtherCAT (Ethernet для технологии автоматизации управления).
• Опишите концепцию «обработки на лету» и ее влияние на производительность.
• Объясните топологию сети EtherCAT, структуру телеграмм и адресацию.
• Понять роль и важность механизма распределенного времени (Distributed Clocks или DC) для синхронизации.
• Описать конечный автомат EtherCAT (EtherCAT State Machine или граф состояний «ESM») и его различные состояния.
• Определить назначение и структуру файлов информации о ведомых устройствах EtherCAT (ESI, это знакомые нам XML-файлы с описанием).
• Определить критическое аппаратное требование для ведомых устройств EtherCAT: контроллер ведомого устройства EtherCAT (EtherCAT Slave Controller или ESC далее по тексту).
• Обсудить концептуальные подходы к взаимодействию ESP32 с ESC и управлению прикладной логикой ведомого устройства EtherCAT.
• Оценить различия между вариантами ESP32 с точки зрения их пригодности в качестве хост-контроллеров для ESC.
• Знать о распространённых проблемах и методах устранения неполадок при разработке ведомых устройств EtherCAT.

Введение

В сфере промышленной автоматизации потребность в более высокой производительности, большей точности и синхронизации в «реальном времени» обусловила развитие протоколов на основе Industrial Ethernet. EtherCAT (Ethernet for Control Automation Technology) — это высокопроизводительная детерминированная система на базе Ethernet, разработанная компанией Beckhoff Automation. Она известна своей исключительной скоростью, эффективностью и точностью синхронизации, что делает её предпочтительным выбором для требовательных приложений, таких как управление движением, робототехника и высокоскоростной сбор данных.

EtherCAT достигает своей производительности благодаря уникальному принципу: «обработка на лету». Вместо традиционной обработки Ethernet-кадров с промежуточным хранением и пересылкой каждым узлом, телеграммы EtherCAT проходят через подчинённые устройства с минимальной задержкой, поскольку данные извлекаются и вставляются «на лету» специализированным оборудованием. Это обеспечивает чрезвычайно короткое время цикла (до микросекунд) и низкий уровень джиттера связи (здесь джиттер - это вариабельность задержки пакетов данных при их передаче по сети, а не дрожжание самого сигнала при передаче битов и байтов, если вдруг вы подумали об этом).

В целом, реализация полноценного стека EtherCAT для ведущего или ведомого программно на микроконтроллере общего назначения (ESP32, STM итп, об этом говорилось в статье про EtherCAT) чрезвычайно сложна и вовсе нереализуема для ведомого устройства из-за аппаратных требований по быстродействию обработки данных при приеме «на лету» (ну разве что на ПЛИС/FPGA), но ESP32/STM32 вполне может служить интеллектуальным хост-контроллером для специализированного ASIC или ПЛИС ведомого контроллера EtherCAT (ESC) для Slave-устройства и тем более для реализации Master.

Теория

Основные принципы EtherCAT

Философия проектирования EtherCAT отличает его от многих других промышленных Ethernet-решений.

• Обработка на лету: Это краеугольный камень производительности EtherCAT, основа его быстродействия.
  • Ethernet-кадр (телеграмма EtherCAT), отправленный ведущим устройством, проходит через все подключенные ведомые устройства.
  • Каждое ведомое устройство имеет выделенный ведомый контроллер EtherCAT (ESC). При прохождении телеграммы через ESC, ESC считывает адресованные ему данные и вставляет свои данные в кадр, как раз когда этот кадр проходит через узел (это и есть «на лету»). Это упоминаемые ранее AX58100 от ASIX (slave controller, licensed from Beckhoff Automation), XMC4800 от Infineon (slave controller, уже упоминалось), LAN9252/LAN9253 от Microchip Technology (slave controller), ET1100 (slave controller от Beckhoff).
  • Задержка на ведомое устройство обычно составляет наносекунды. Кадр задерживается каждым ведомым устройством лишь незначительно, в основном из-за распространения сигнала. Данные на входе и на выходе (физически это разные порты) следуют практически байт к байту, необходимые данные меняются «на лету».
  • Последний ведомый в сегменте (или логический конец сегмента) отражает кадр обратно ведущему устройству, это определяется по свободному порту.
  • Это означает, что один кадр Ethernet (Ethernet-фрейм) может переносить данные для большого количества подчиненных устройств, как входных, так и выходных и все это в одном кадре, что значительно повышает использование полосы пропускания и снижает накладные расходы протокола.

• Топология сети:
  • EtherCAT поддерживает гибкие топологии: линейную, древовидную, «звезда» или комбинированные, иногда практикуется кольцо, если у мастера есть два порта, встречал такое упоминание.
  • Логически EtherCAT всегда работает как шина. Даже при физическом подключении по схеме «звезда» (с использованием устройств-соединителей EtherCAT с несколькими портами) телеграммы фактически проходят по логической линии.
  • Каждый Слейв (ESC) обычно имеет два порта (или больше для соединительных устройств), рахъем RJ45 (порт 0, порт 1 и т.д.). Кадр входит в один порт, а выходит уже из другого. Если порт не подключен, ESC автоматически замыкает логический цикл в этой точке и возвращает кадр.

Транспорт

Данные EtherCAT передаются в виде пакетов, которые полностью совместимы с Ethernet-пакетами. Это означает, что EtherCAT-пакеты на физическом (PHY) и MAC-уровне построены так, что для Ethernet-сетей они выглядят как родные и устройства типа роутеров, свичей и хабов могут передавать их не задумываясь, наравне с остальными пакетами Ethernet. Если же необходимы более высокоуровневые фишки (типа IP-роутинга), то без проблем можно перейти на уровень выше и поместить фрейм EtherCAT в UDP/IP датаграмму.

Условно это для фрейма Ethernet сам пакет EtherCAT data - это уже пользовательские данные, они не регламентируются спецификацией Ethernet, по сути это инкапсуляция пакета EtherCAT в Ethernet. Упрощенно EtherCAT-фрейм состоит из заголовка EtherCAT и данных EtherCAT, но сейчас нам будет интересен только заголовок (header), который в свою очередь состоит из поля длины (Length) и поля типа данных Type, который определяет протокол передачи данных EtherCAT внутри пакета (поле R от слова Reserved- зарезервировано). Источником можно считать ethercat_esc_datasheet_sec1_technology_2i3, хотя есть и более свежая версия, файлы для скачивания прикреплю к посту. Итак что определяют биты Type заголовка EtherCAT Header?

Type (EtherCAT Device Protocol):

• Тип 1: команда EtherCAT. Wireshark определяет как Type: EtherCAT command (0x1), если говорить про EtherCAT Slave Controller (ESC), то они поддерживают только тип 0х01.

EtherCAT Automation Protocol (EAP)

• Тип 4: Синхронный обмен операционным пакетом, PD (Process Data Communication).
• Тип 5: Асинхронный обмен через "почтовые ящики" (Mailbox communication). Для асинхронного обмена доступен только протокол AoE (ADS over EtherCAT). Остальные протоколы, такие как CAN, SERCOS, PROFIBUS и т. п., передаются "внутри" его фреймов.

При непосредственном подключении EtherCAT-подчиненного к мастеру всегда используется EtherCAT Device Protocol (тип 1 или Type1). Для этого на подчиненном устройстве устанавливается специальный микрочип — EtherCAT Slave Controller (ESC). Для остальных видов связи, в том числе и для построения сложных маршрутов, используется EtherCAT Automation Protocol (EAP, тип 4 или 5). Оба протокола могут использоваться как синхронно, так и асинхронно.

Подробнее о структуре фрейма EAP можно прочитать в справочной системе — EAP telegram structure или https://gotwincat.blogspot.com/2017/03/ethercat-automation-protocol.html, но к нашей теме это не относится, тк по большей части относится к Master-Master коммуникации.

Структура телеграммы EtherCAT (Ethernet-фрейм с EtherCAT инкапсуляцией):

Фрейм целиком обрабатывается аппаратно с помощью специального микрочипа EtherCAT Slave Controller (ESC). Поэтому учитываются только фреймы с EtherType = 0x088A4 Ethernet-заголовка и EtherCAT Type = 1, указанного уже в заголовке EtherCAT.

EtherCAT использует обычные Ethernet-фреймы соответствующие стандарту IEE 802.3

• EtherCAT использует стандартные кадры Ethernet IEEE 802.3 с определенным EtherType: 0x88A4.
• В Payload Ethernet-фрейма инкапсулируется одна или несколько датаграмм EtherCAT (ну не нравится мне перевод Payload как полезная нагрузка).
• Каждая датаграмма содержит:
  • Datagramm Header (Заголовок): Содержит команду (например, APRD – автоматическое приращение физического чтения, FPWR – физическая запись с настроенным адресом), индекс (вспомогательное поле для отслеживания датаграмм), адрес (может содержать как адрес получателя, так и адрес смещения для данных внутри ведомого устройства), длина данных и несколько других малозначимых полей, о которых подробнее позже. Заголовок кстати один из важнейших моментов в понимании, потому о нем найдите описание подробнее далее…
  • Data (Данные): Фактические данные процесса или информация об управлении/статусе.
  • Working Counter (WKC) или рабочий счетчик слейвов: это тоже ключевое поле, тк каждое ведомое устройство, успешно обработавшее прошедшую через него дейтаграмму, увеличивает значение WKC при условии, что что—то сделало с этим пакетом (слейв инкрементирует wkc если читал ее данные и инкрементирует wkc если писал в нее данные, так что если он и читал и писал данные в одну и ту же датаграмму то wkc будет инкрементирован дважды). Ведущее устройство использует итоговое значение WKC для проверки того, что все адресованные ведомые устройства правильно обработали свою часть датаграммы. Получая пакет обратно, мастер знает сколько у него подчиненных и может сравнить ожидаемое значение счетчика с актуальным значением. Это позволяет системе определить полноценность исполнения EtherCAT команды. Кстати можно, например, послать BRD датаграмму (Broadcast, что значит широковещательную, то есть адресованную всем слейвам) "прочитать нулевой байт" и по счетчику wkc понять сколько всего устройств находится на линии (главное заранее заготовить нужный объем данных для приема в пакете).

Одним из важных моментов и особенностей работы EtherCAT является гибкая возможность организации адресации, которой я не встречал лично нигде (речь о гибкости), это может очень испугать. А мы плавно переходим к разбору Заголовка или Datagramm Header (пусть не по порядку, но я думаю так даже удобнее). Дело в том, что адресация в EtherCAT работает совместно с командами в поле CMD заголовка датаграммы и вариант заполнения поля Address выбирается в зависимости от выбранной команды (листайте слайд ниже, на втором слайде есть соответствие). Само поле CMD как бы состоит из двух половинок по 4 байта, первая определяет тип адресации, вторая половинка тип доступа (чтение/записть итп), но пока это только для понимания, почему на картинках мы видим надпись в виде APxx или наоборот xxRD. Ну и естественно мы не увидим буков в самих пакетах, за AP/FP скрываются цифры, как и в перечисляемом типе ENUM при программировании на C/С++, для APRD будет 1, для APWR 2, итд, это описано в ethercat_esc_datasheet_sec1_technology_2i3 на 30 страничке. А поле Address в нашем случае может состоять из двух субполей ADP - Address Position и ADO - Address Offset, но об этом подробее ниже, пока это просто для понимания.

Итак, что же нам говорит EtherCAT_Communication_EN по поводу адресации?

Разбор заголовка дейтграммы (Datagramm Header), имеем ввиду порядок следования битов слева направо, то есть Len это младшие биты, а R,C,M старшие —> по поводу адресации листаем дальше→

Адресация в EtherCAT может быть:

• Автоматическая инкрементная адресация: Адресация ведомых устройств осуществляется по их физическому положению в сетевом кольце. Первый ведомый имеет адрес 0, второй — -1, третий — -2 и т. д. (относительно ведущего устройства во время настройки). Эту адресацию еще можно назвать Топологическая адресация. Субполе ADP в поле Address содержит "минус индекс слейва к которому обращаемся". Почему минус? Потому что каждый слейв будет инкрементировать это поле, и тот слейв к которому в этом поле придет со значением 0x0000 обработает датаграмму. При этом Субполе ADO содержит смещение в памяти Слейва DPRAM, об этом чуть ниже.
• Преднастроенный адрес (псевдоним или Alias): Во время инициализации ведущее устройство назначает каждому ведомому устройству уникальный 16-битный фиксированный адрес (псевдоним станции). Этот адрес затем используется для последующей связи, то есть слейв обрабатывая датаграмму, производит запись или чтение, если адрес в поле ADP совпадается с адресом, сохраненным в регистре 0x012 DPRAM. Стоить иметь ввиду - данное поле сбрасывается при обесточивании слейва. Субполе ADO содержит все то же смещение, что и при инкрементной адресации.
• Логическая адресация (тут мы чуть перепрыгнули вперед Broadcast): Ведущее устройство настраивает логический образ данных процесса. Данные нескольких ведомых устройств могут быть сопоставлены с этим единым образом, что позволяет ведущему устройству считывать/записывать все соответствующие данные процесса с помощью одного кадра EtherCAT, содержащего несколько датаграмм.
• Ну и не забываем про Broadcast, то есть всем сразу или широковещательно, причем место под адрес все также используется: каждое ведомое устройство увеличивает позицию (само же поле не используется для адресации, ну это и понятно раз броадкаст).

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

Внутренняя память slave — DPRAM

С точки зрения программы, slave устроен типичным для микроконтроллеров способом — есть некая область памяти, мы можем ее читать и писать в нее, при этом МК, обслуживающий слейва тоже может к ней обратиться, в одном случае она мапится на адресное пространство МК (Infineon), в другом случае доступ к ней из программы МК будет через протокол SPI (Microchip). Первые 4 килобайта (адреса < 0x1000) — регистры, имеют специальное назначение описанное в стандарте ethercat, дальше идет пользовательская память где будут оказываться те данные которые пришли от мастера и куда надо помещать те данные которые к мастеру уходят. Конкретно на XMC4800 этой пользовательской памяти 8 килобайт. Конкретно про регистры, доступ к которым в Ethercat идет через поле ADO рассказано в ethercat_esc_datasheet_sec2_registers_3i0, а конкретно с 21 странички. Именно они - основной инструмент по настройки взаимодействия слейва и ПЛК, так например при работе со StateMachine запись именно в эти регистры и чтение статуса в них позволяет делать переходы между состояниями.

Интересно что к этой памяти (а значит и настраивать все параметры обмена с помощью регистров) может обращаться как микроконтроллер слейва, так и мастер посылая EtherCAT пакеты. Логично что одновременный доступ двумя сторонами чреват гонками данных, но о том как это решено чуть позже. Пока же отметим что варианты обозначены в терминологии Ethercat как ECAT и PDI (Process Data Interface).

Память DPRAM приведена в таблице со смещениями в байтах, приведу здесь некоторые:

• 0x000 — Type of EtherCAT controller для XMC =0x98 (чтобы убедиться что связь вообще есть можно прочитать нулевой байт)
• 0x004 — Number of supported FMMU channels (or entities)
• 0x005 — Number of supported SyncManager channels (or entities)
• 0x006 — RAM Size (Process Data RAM size supported in Kbyte)
• 0x010..0x011 — Configured Station Address или преднастроенный/фиксированный адрес, используется при адресации командами FPRD/FPWR/FPRW/FRMW. Мастер этими командами может обращаться к конкретному слейву либо с помощью этого адреса, либо с помощью Alias/псевдонима. Адрес слейва записывается в настройки слейва мастером при инициализации сети (а не берется из настроек слейва), и не сохраняется, то есть зависит от питания. На картинке ниже это поле EtherCAT address в программе CODESYS. Alias в свою очередь это значение, записанное по смещению 0x012..0x013 (как раз следующий пункт списка, см ниже), выбор что будет использовать слейв для идентификации (считаем что мастер отправляя пакет понимает, что он будет сам в адрес писать) определяется настройкой слейва, а именно битом управления DL регистра 0x0100[24].

• 0x012..0x013 — Configured Station Alias, или псевдоним узла, его особенность в том, значение EEPROM передается в этот регистр при первой загрузке EEPROM после включения питания или сброса, то есть в отличие от предыдущего варианта, теперь за этот адрес отвечает настройка слейва, а мастеру лишь нужно сообщить этот адрес. Именно это значение есть в поле настройки Identification программы CodeSys (слайд ниже), если выставить галку Optional. Что выбрать фиксированный адрес или псевдоним, решает мастер (его настройки), в нашем случае для привода программа ставит галочку напротив Configured Station Address и предлагает значение 127.

• 0x040 — RESET_ECAT, мастер может удаленно перезагрузить засбоивший слейв.
• 0x100..0x103 — DL_CONTROL, jбычно работа идет с регистрами с адресом смещения 0х101, это настройки управление портами (открыт\закрыт).
• 0x110 — DL_STATUS, состояние портов (есть ли линк)
  ну и хватит наверное. Подробности в документации.
• 0x120..0x121 — AL Control: в зависимости от битов это может быть несколько функций, но вот эта точно полезна в для понимания bit 3:0 : Initiate State Transition of the Device State Machine:
  • 1: Request Init State
  • 3: Request Bootstrap State
  • 2: Request Pre-Operational State
  • 4: Request Safe-Operational State
  • 8: Request Operational State
• 0x130..0x131 — AL Status: в зависимости от битов это может быть несколько функций, нас интересуют эти - bit 3:0 : Actual State of the Device State Machine:
  • 1: Init State
  • 3: Bootstrap State
  • 2: Pre-Operational State
  • 4: Safe-Operational State
  • 8: Operational State

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

Команды

Нет смысла перечислять все команды, так как их аббревиатуры подчиняются ряду правил, первая часть выбирает тип адресации, вторая тип действия

Выбор адресации:

• APxx — Топологическая адресация. ADP содержит "минус индекс слейва к которому обращаемся". Почему минус? Потому что каждый слейв будет инкрементировать это поле, и тот слейв к которому в этом поле придет 0x0000 обработает датаграмму.
• FPxx — Физическая адресация. Ответит тот слейв у которого STATION_ADR совпадет с полем ADP, тут стоит заметить, что настройками может быть выбран вариант, когда STATION_ADR = значению, которое записано самим же мастером при инициализации EtherCAT (в регистр смещением 0х010 DPRAM), этот адрес сохраняется только до отключения питания, либо взят Alias, который доступен по смещению 0х012 DPRAM и пишется туда МК, обслуживающим слейв, а ESC его только читает, а записать при этом не может, значение получается для самого ESC только для чтения.
• Lxx — что-то сделать, если адрес в датаграмме соответствует логическому адресу FMMU-области (см. ниже). По сути это логическая адресация (про нее тоже написано выше). Подробнее про нее рассказажу в разделе FMMU, но в этом случае в поле адреса находится 32-битный адрес, а слейвы в зависимости от своих настроек пишут или читают данные. Именно этими пакетами идет собственно опрос сотни моторчиков одним пакетом.
• Bxx — Широковещательный пакет. Ответят все слейвы. Ах да, если отвечает несколько слейвов, результат получается логическим OR от их значений. Ну т.е. мастер отправляет в данных нули, а слейвы могут только заменять в пакете данные на единички но не сбрасывать в 0.

Выбор действия:

• NOP — нет операции, подчиненный игнорирует эту команду.
• xxRD — Это операци «Чтение» со стороны Мастера, а Слейвы должны записать в датаграмму считанные модулем данные (например, модуль дискретных входов).
• xxWR — Запись данных. Мастер записал данные, а выбранные слейвы их читают из датаграммы в память по заданному адресу (например, для активация выходов модуля дискретных выходов).
• xxRW — Чтение И запись. Кроме как в виде LRW выглядит как-то глупо, слейв сначала прочитает данные а потом запишет туда же. А вот с логической адресацией это наоборот основной тип датаграмм.
• xxRMW — Один пишет остальные читают. Тот слейв у которого ADP совпал (см. расшифровку первых половин команд) запишет туда данные, а остальные будут читать. Учитывая что есть LRW не слишком полезная штука.

Примечания:

• BRD — подчиненные помещают в датаграмму логическое ИЛИ между данными из памяти и данными из датаграммы.
• BRW — обычно не используется (аналогично команде BRD только данные помещаются в память).
• ARMW — подчиненный наращивает автоинкрементальный адрес и помещает в датаграмму прочитанные данные, если адрес получился равен нулю. Иначе подчиненный сохраняет данные датаграммы в свою память. Например, эта команда используется для DC: прочитал "часы" на "эталоне" и передал дальше для всех подчиненных, которые сохранили его.
• FRMW — если адрес в датаграмме соответствует одному из сконфигурированных адресов подчиненного, то помещает в датаграмму прочитанные данные. Иначе подчиненный сохраняет полученные данные в свою память.

Кроме этих двух полей, в заголовке расположены другая полезная информация:

• Index (индекс) — номер датаграммы, для контроля за дублированием или повторением датаграмм, просто меняющееся в каждой отправке число. В реализации SOEM туда пишется номер буфера отправки\приема.
• Length (длина) — длина данных в датаграмме.
• R — зарезервирован.

Остальные C, R, M, IRQ если вкратце — просто оставьте их нулями. SOEM так и делает, если любите разобраться, то:

• C (флаг циркуляции) — в случае обрыва соединения с мастером, фрейм может начать бегать по кольцу из подчиненных. Это не корректно. Варианты выбора 0: Frame is not circulating, 1: Frame has circulated once
• M (последняя ли датаграмма?) — последняя ли это датаграмма в EtherCAT-фрейме. Варианты выбора 0: Last EtherCAT datagram 1: More EtherCAT datagrams will follow
• IRQ (EtherCAT Event Request) — это поле необходимо для уведомления мастера о событиях, произошедших на подчиненных. Неизвестно кто из подчиненных непосредственно был инициатором события, поэтому программное обеспечение мастера должно самостоятельно разобраться с этим. EtherCAT Event Request registers of all slaves combined with a logical OR.

Ну вот вроде бы освоили самый сложный раздел и можно расслабиться? Ан нет, ведь впереди не менее важные разделы.

Распределенные часы или механизм распределенного времени (Distributed Clocks DC)

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

В сети EtherCAT механизм синхронизации времени реализован полностью аппаратно. Часы на slave-устройствах могут легко и точно измерить задержку относительно других часов, так как для связи используется логическая и полнодуплексная физическая кольцевая структура Ethernet, т.е. каждый пакет EtherCAT проходит дважды через каждое slave-устройство (прямой и обратный путь по разным витым парам). На основе этого значения задержки производится подстройка распределенных часов, что позволяет достичь очень точной временной базы с разбросом существенно меньше 1 мкс в масштабах всей сети.

Распределенные часы или механизм распределенного времени Distributed Clocks (DC)

Для приложений, требующих высокоточной синхронизации (например, скоординированного управления движением, типа как на станках ЧПУ), EtherCAT предлагает распределенные часы. Системное время считается с даты 01.01.2000 и времени 0:00:00:000000, имеет базовую дискретность 1ns и разрядность регистра сохранения 64-bit. Если вкратце работа контроллера распределенного времени состоит из 2 фаз (см. второй слайд на карусели выше):

• Инициализация: изначально независимые часы настраиваются в соответствии с определением системного времени.

• Компенсация дрейфа: следующие отклонения корректируются для поддержания синхронизации.

Ведущее устройство (Master) активирует ведомые устройства для фиксации (Latch, назовем его отпечаток или снимок) значений локального времени [Слейва] при получении стандартной команды на каждом порту. Фиксация (Latch) активируется путем записи в ADO 0x0900 (регистр DPRAM со смещением 0x0900). Локальное время на порту X фиксируется в SOF (Start of Frame). В момент EOF (End of Frame) зафиксированное время на порту X копируется в ADO(0x0900+4*X).

ADO(0x0900+4*X) указывается в единицах локального времени (на этом этапе локальные часы каждого ведомого устройства ещё не коррелированы с другими). Далее Мастер читает все записанные Слейвами «отпечатки» времени и на их основе рассчитывает как задержку распространения (propagation delay), так и смещение DC для каждого слейва. Каждый из подчиненных внутри себя имеет входную и выходную отметки времени, по которым можно легко вычислить на сколько задерживается пакет на каждом из подчиненных. После сбора всех временных отметок (time stamps), мастер шины, который отлично знает топологию шины, может рассчитать задержки распространения для каждого сегмента кольца шины. Затем, для каждого подчиненного, который имеет DC, мастер индивидуально записывает в специальный регистр System Time Offset смещение между эталонным временем и локальным отсчетом времени. То есть Мастер является своего рода регулятором этого времени. Размер регистра те самые 8 байт или 64 разряда расположенные по адресу 0x0920. Теперь каждый DC-подчиненный может узнать системное время просто сложив свое локальное время (хранящееся в регистре Local Time) со сдвигом (offset). Со временем локальные часы могут "уплыть" в большую или меньшую сторону, поэтому мастеру необходимо постоянно корректировать это отклонение (drift). Для этого постоянно отправляются специальные команды ARMW (Auto Increment Read Multiple Write) или FRMW с эталонным временем. Подчиненное устройство (терминал) получив эту команду, сверяет значение локального времени и ускоряет или замедляет свои локальные часы.

Для понимания (листаем слайды карусели выше далее, там и снимки и задержки):

Смещение - это абсолютная разница между локальными часами ведомого устройства N и стандартным определением системного времени.

Задержка - это время распространения кадров между опорным тактовым генератором и ведомым устройством N

Всякий раз, когда записывается ADO 0x0910, ведомое устройство сравнивает полученное системное время со своим локальным временем (скорректированным с помощью задержки и смещения) и производит коррекцию:

(Local Clock + Offset) –(Received System Time + Delay) > 0 → Local Clock decelerates

(Local Clock + Offset) –(Received System Time + Delay) < 0 → Local Clock accelerates

То есть DC можно еще охарактеризовать следующими пунктами:

• Принцип: ESC содержит высокоточные локальные часы (обычно 64-битные), заметьте не все слейвы имеют такую возможность.
• Синхронизация: Ведущее устройство отправляет специальную дейтаграмму EtherCAT (например, FRMW – Fixed Address Read Multiple Write – чтение с фиксированным адресом и множественная запись) ведомому устройству с опорным тактовым генератором (обычно первому ведомому устройству с поддержкой DC в сети). Это ведомое устройство записывает своё текущее время в кадр. По мере прохождения кадра через последующие ведомые устройства с DC они считывают это опорное время, а также время, записанное предыдущим ведомым устройством, что позволяет им рассчитать задержки распространения сигнала. Эти же данные получает и Мастер.
• Компенсация смещения и дрейфа: Каждое ведомое устройство вычисляет смещение между своим локальным тактовым сигналом и опорным тактовым сигналом и компенсирует его. Также выполняется компенсация дрейфа.
• Результат: Все ведомые устройства с поддержкой DC в сети могут быть синхронизированы с точностью до микросекунды. Это обеспечивает точную синхронизацию операций ввода-вывода и координацию действий на нескольких устройствах.
• Синхронизирующие сигналы (SYNC0, SYNC1): ECS с поддержкой DC может генерировать точно синхронизированные сигналы прерывания (SYNC0, SYNC1) на основе своих синхронизированных часов, запуская действия в приложении ведомого устройства (например, выборку АЦП, выход исполнительного механизма, инициировать прерывание наконец).

Не все подчиненные должны, и не все поддерживают часы распределенного времени (DC [ди́-си́], Distributed Clock). Просто не всем оно нужно и наличие его — не делает модуль лучше.

Плюс-минус 50-100 наносекунд — это обычная точность распределенных часов. Счетчик 64-разрядный, его должно хватить где-то лет на 500. Тикает он, согласно спецификации, с 10 наносекундным интервалом (тут как-то странно в спецификации речь о 1ns, а в статье встречал 10, пока оставил так).

На вкладке DC → Operation Mode того же TwinCAT-а, можно увидеть следующие варианты режимов работы распределенных часов:

• Oversampling — с оверсамплингом, можно задать частоту отправки SyncUnit и частоту семплера, который для получения дополнительных отсчетов работает быстрее SyncUnit.
• DC Latch — только с DC, не работает без него.
• FreeRun / SM-Synchron — синхронизация по фреймам EtherCAT.
• DC-Synchron / DC-Synchron (input based) — TwinCAT делит устройства на группу ввода и группы вывода (плюс информационная зеленая группа). DC может синхронизироваться или там, или там. Этот вариант позволяет выбрать откуда подчиненное устройство будет брать DC-сигнал.

Для тонкой настройки:

I/O → devices → EtherCAT шина → EtherCAT - Advanced Settings... → Distributed Clocks
DC Mode → Automatic DC Mode Selection — по умолчанию, установлен и означает автоматический выбор эталонных часов. Обычно, этот выбор правильный.
Settings→ Continuous Run-Time Measuring — регулярно пересчитывать карту временных задержек. Применимо в случаях частой замены кабелей связи, либо при использовании групп горячего подключения (кабель может быть другой и он будет другой длины).
→ Sync Windwos Monitoring → Sync Window (мкс) — уровень предупреждения при выходе за пределы.
→ Show DC System Time — это копия системного времени, а не локальное DC-время! Отображается в желтой закладки Input, но(!) отстает на один цикл от точного значения, так как необходимо время на получение и отображение значения. В ПЛК-программе лучше использовать множество функций из библиотек TcEthercat, которые дадут точное время.
SYNC Shift Time — сдвиг времени, обычно автоматически определяется правильно при старте системы. При условии, что система работает и построена правильно.

Communication time

Three communication modes are possible:

1. Free Run

EtherCAT Communication and application are running independently from each other.

2. Synchronized to Output Event

The slave application is synchronized to an Output event. If no Outputs are used the Input event is used for synchronization.

3. Synchronized to SyncSignal

Application is synchronized to the SyncSignal.

For further information please refer to the corresponding section within the EtherCAT Information System.

The Communication Timing with use of Distributed Clocks is explained in Figure

IO(Master)

Time to load IO Data to communication buffer and vice versa.

Calc(Master)

Processing time of the master.

Frame(Communication)

Time to transmit the IO-Data-Frame (about 5μs overhead plus 80ns per Byte of Data).

D(Communication)

Delay time of the EtherCAT-Slaves to transfer data (approx. 1 μs with 100BASE-TX, plus line delay of approx. 5ns per m).

Jitter(Communication)

Depends mostly on Master timing quality.

U(Communication-Master)

Shift time that is adjusted internally by the master to deal with delays needed by the master and adjust the cycle time.

U(Slave)

Delay time of the EtherCAT-Slaves. This can be set by each slave individually and is usually 0. There is a need to set this parameter in case of timing inaccuracies of the slave or to deal with slaves that have a slow output method compared to others with high speed output.

Cycle Time Jitter

Cycle Time Jitter is application-specific and depends on the jitter of the master system, the used infrastructure components and the slaves. This example assumes a time of 10% of the cycle time for jitter compensation.

SyncManager

EtherCAT решает возможные проблемы одновременного доступа к памяти (со стороны МК и со стороны пришедшего по сети пакета) с помощью концепции SyncManagerов. А проблемы могут быть примерно такие (хотя на слайдах как раз решение проблем):

MailBox (1 buffer): Read access to an empty SyncManager failes

SyncManager (SM) — специальный блок в модуле ethercat слейва, которому мы указываем на область адресов памяти слейва и он устанавливает особый режим доступа к этой памяти. Он обеспечивает согласованность передачи данных, синхронизирует, предотвращая одновременный доступ к памяти контроллера (DPRAM) со стороны Ethercat (контроллер ECS, это направление будет для терминологии спецификации обозначено как ECAT) и со стороны контроллера, обслуживающего Slave (в терминологии спецификации это будет PDI или Process Data Interface). Всего SyncManager может быть до 16 штук.

Управляются регистрами начиная с 0x800. Каждый SM имеет 8 регистров, т.е. 0x800-0x807 задают SM1, 0x808-0x80F задают SM2 и так далее. У XMC4800 например всего 8 SyncManagerов. Регистры имеют следующий смысл:

0x800:0x801 : Physical Start Address

0x802:0x803 : Length (in Byte) Number of bytes assigned to SyncManager (shall be greater than 1, otherwise SyncManager is not activated. If set to 1, only Watchdog Trigger is generated if configured)

0x804 : Control Register (including type and direction) там есть настройки Operation Mode, Direction, Interrupt in ECAT Event Request Register, Interrupt in AL Event Request Register, Watchdog Trigger Enable

0x805 : Status (Interrupt Write, Interrupt Read, Mailbox mode, Buffered mode, Read buffer in use, Write buffer in use)

0x806 : Activate (SyncManager Enable/Disable, Repeat Request, Latch Event ECAT, Latch Event PDI)

0x807 : PDI Control (Deactivate SyncManager, Repeat Ack)

В зависимости от настройки бывают двух типов — mailbox и буфер. Кроме того они могут быть настроены на запись либо на чтение. Картинки из презентации поясняют их довольно очевидно, но чтоб не передирать совсем внаглую распишу словами, нам доступны два варианта работы SyncManager:

Mailbox — предназначены для организации своих протоколов вопрос-ответ поверх ethercat. Один пишет другой ждет, потом другой читает первый ждет.

Buffered — для обмена быстроменяющимися данными. Один все время пишет а второй читает последнюю согласованную копию.

• Mailbox режим Read. Пока слейв не записал данные — читать нельзя (датаграмма чтения вернет WKC=0). Если слейв начал писать (обратился к первому байту но не обратился к последнему байту области) — читать по-прежнему нельзя (датаграмма чтения вернет WKC=0). Как только слейв закончил писать (обратился к последнему байту области) — ящик закрывается и слейв туда писать больше не может (при попытке записи содержимое не изменится), зато мастер может прочитать содержимое датаграммой (WKC вернет 1) и факт этого чтения опять откроет ящик.
• Mailbox режим Write. Работает аналогично. Пока мастер ничего не записал слейв будет читать нули, как только датаграмма с записью прошла слейв сможет читать данные, и пока он не прочитает их до конца (не обратиться к последнему байту области) новые датаграммы записи будут возвращать WKC=0.

• Buffered режим Read. Это более хитрый режим предназначенный для обмена быстроменяющимися данными. В этом режим слейв всегда может писать данные не заботясь о том прочитал мастер их или нет, а мастер соответственно всегда получать при чтении последнюю согласованную копию данных. Организуется с помощью трех буферов, т.е. если мы настроили SyncManager на адреса 0x1000-0x1010, то в памяти слейва они займут 0x1000-0x1030. При этом слейву надо писать всегда в 0x1000-0x1010, а мастеру читать оттуда же, но по факту он прочитает ту из трех копий которая была записана целиком.
• Buffered режим Write. Аналогично, но для записи. Т.е. мастер может писать данные, они будут попадать в один из трех буферов, а слейв может спокойно читать не беспокоясь что они перетрутся новой посылкой в процессе чтения.

Если чуть иначе записать работу SyncManager то для режима почтового ящика (Mailbox) это будет следующий функционал:

• Один буфер с режимом установки связи (handshake).
• Защита от переполнения буфера.
• Передающая сторона должна записать в буфер, перед тем как принимающая сторона сможет читать буфер.
• Принимающая сторона должна "вычитать" буфер, перед тем как передающая сторона сможет записать буфер.
• Используется для обмена данными "от случая к случаю" (иногда, нерегулярно) требуемых в данный момент данных.
• Стандартный способ для обмена параметрами данных, диагностики, конфигурации рабочего образа данных.
• Полнодуплексный.
• Подчиненный может инициировать передачу.
• Доступен уже из состояния Pre-Operational (Pre-OP).
• Позволяет реализовать множество протоколов:
  • EoE (Ethernet через EtherCAT) — туннель Ethernet через EtherCAT.
  • CoE (CANopen через EtherCAT) — для передачи словарей объектов (словарей PDO)
  • FoE (Передача файлов через EtherCAT) — передача файлов, например, для перепрошивки устройства.
  • SoE (SERCOS через EtherCAT) — доступ к параметрам сервоусилителей.
  • VoE (уникальный протокол разработчика (Vendor specific) — разработчик может самостоятельно разработать свой собственный протокол.

Буферизированный режим (Buffered):

• Менеджер синхронизации с тремя буферами гарантирует целостность данных и доступ к новым данным в произвольный момент времени.
• Всегда доступный буфер для записи.
• Буфер чтения всегда заполнен гарантированно целостными данными (за исключением момент старта, то есть перед первой записью в буфер чтения).
• Используется для циклического обмена заранее сформированного списка данных (PDO).

Стандартное распределение SyncManager:

• Mailbox
  • SM0 — Mailbox-вывод.
  • SM1 — Mailbox-ввод.
  • SM2 — PDO-вывод.
  • SM3 — PDO-ввод.

• Buffered
  • SM0 — PDO-вывод (или PDO-ввод, если отсутствует вывод).
  • SM1 — PDO-ввод.

PDO всегда точно умещается в буфере соответствующего SyncManager. Поэтому размер PDO всегда ограничен.

PDO и SDO

PDO в терминах TwinCAT — это заранее подготовленный пакет с описанием набора параметров которые будут передаваться или синхронизироваться совместно. PDO заимствованы из CANOpen.

Словарь объектов — это не подсистема, а словарь который используется всеми подсистемами и описывает целевые данные которыми надлежит обмениваться, а также правила обмена. Словарь может храниться в различных местах, но в итоге объекты должны быть настроены одинаково.
Синхронизация обмена данными (ключевое слово SYNC) — необязательная, но целесообразная подсистема. При использовании данной подсистемы в сети существует генератор синхросообщений, периодически передающий высокоприоритетное сообщение SYNC. После появления в сети такого сообщения все синхронизируемые устройства производят обмен данными в течение заданного временного интервала(окно синхронного обмена данными). Коллизии (одновременная передача данных двумя и более устройствами) разрешаются на уровне физического уровня протокола CAN. Словарь объектов содержит перекрёстные ссылки откуда какие данные взять, и какие куда положить. Таким образом приложения не занимаются самостоятельно сбором данных — просто с точки зрения приложения в определённых переменных периодически оказываются свежие данные.
При обмене PDO, с точки зрения приложения, всё происходит автоматически по определённым правилам, и приложение, не обращаясь к сетевым примитивам, получает данные из переменных, как будто бы данные появляются внутри этого самого прибора. Для получения данных по принципу SDO приложение должно при помощи сетевых сервисов запросить данные у другого устройства, и только потом, получив ответ, использовать данные для работы. Поэтому основу обмена данными следует строить на PDO-обмене. К сожалению имеются ограничения на размер данных(8 байт для PDO, но можно использовать несколько таких PDO).
SDO стоит использовать только по необходимости. При SDO обмене данными, устройство, к которому обратились с запросом на получение или запись(dowload/upload) данных, называется SDO сервером, а устройство которое инициировало обмен — называется клиентом. В зависимости от объема передаваемых данных, обмен производится по разным алгоритмам, и может быть не менее эффективен чем PDO обмен. SDO обмен допускает производить контроль безошибочности данных, что позволяет даже загрузку отдельных порций исполняемого кода.

Раз описали работу SyncManager, то теперь можно приступить и к FMMU

FMMU или Fieldbus Memory Management Unit

FMMU или Fieldbus Memory Management Unit

Эти модули находятся между соответствующим SyncManager (SMx) и физическим уровнем. Задача FMMU в отражении локального адресного пространства подчиненных модулей на глобальное адресное пространство мастер-контроллера и наоборот. Другими словами — FMMU транслирует и раскидывает данные из логического операционного образа (фрейма, датаграммы) в физическую память и обратно. FMMU умеет работать вплоть до битовых полей (это стоит запомнить отдельно! если хотите работать с целым числом байтов, то StartBit ставьте 0, а EndBit — 7).

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

Если взять пример, когда одной командой нужно прочитать данные сотни датчиков и записать уставки сотне исполнительных устройств, то на каждом из датчиков можно использовать FMMU0 установив физический адрес в 0x1000 (ну или где мы хотим хранить показания датчика), а логический адрес в 0x12345678+4*номер датчика, размер 4 байта, ну и направление READ. На каждом из исполнительных мы используем FMMU0 установив физический адрес в 0x1000 (ну или где мы будем хранить уставку скорости), а логический адрес в 0x12345678+400+4*номер исполнительного, ну и направление WRITE. Теперь мастер может отправить один LRW пакет с логическим адресом 0x12345678, размером 800 байт, во вторую половину которого он запишет все уставки. А по приходу ответа прочитает из первой половины данные всех датчиков. Теоретически, исполнительные могут даже читать данные которые отправил датчик, если находятся после него в топологии (так называемый slave2slave communication), но мы таким не заморачиваемся.

Разумеется, одно устройство может использовать несколько FMMU чтобы и писать и читать данные, ну и стоит настроить SyncManagerы на соответствующие адреса.

Mailbox

Конечный автомат или машина состояний EtherCAT (ESM)

Каждое ведомое устройство EtherCAT должно реализовывать конечный автомат EtherCAT. Ведущее устройство управляет переходами состояний своих ведомых устройств.

• Init (Инициализация):
  • Состояние по умолчанию после включения питания или сброса.
  • Базовая коммуникация (доступ к регистрам) возможна, но обмен данными процесса или связь с почтовым ящиком невозможны.
  • ESC инициализирован.
• Pre-Operational (Предоперационное состояние):
  • Возможен обмен данными через почтовые ящики (для доступа к SDO и настройки).
  • Обмен данными процесса пока не активен.
  • Ведомые устройства проверяют параметры конфигурации, полученные от ведущего устройства.
  • Распределенные часы могут быть инициализированы и синхронизированы.
• Safe-Operational (Безопасное операционное состояние):
  • Входные данные процесса (PDO) циклически считываются ведущим устройством.
  • Выходные данные процесса (PDO) принимаются ведомым устройством, но выходы обычно находятся в безопасном состоянии (например, двигатели выключены).
  • Это состояние позволяет ведущему устройству проверить конфигурацию системы и входы перед включением выходов.
• Operational (Операционное состояние):
  • Активен полный обмен данными процесса (входы и выходы).
  • Устройство полностью работоспособно и участвует в процессе управления.
  • Выходы управляются ведущим устройством через данные процесса.
• Bootstrap (Boot):
  • Дополнительное состояние для обновления прошивки через EtherCAT (FoE – доступ к файлам через EtherCAT).

Словарь объектов (OD) и обмен даннымиe

• Словарь объектов (Object Dictionary или OD):
  • Подобно CANopen, ведомые устройства EtherCAT могут иметь словарь объектов.
  • Это структурированный набор всех элементов данных, доступных в ведомом устройстве, включая параметры устройства, настройки конфигурации и сопоставления данных процесса.
  • Каждая запись идентифицируется 16-битным индексом и 8-битным субиндексом.
  • OD обеспечивает стандартизированный способ доступа к информации об устройстве.
• Объекты данных процесса (Process Data Objects или PDOs):
  • Используется для быстрого циклического обмена данными процесса в реальном времени (входными и выходными).
  • Объекты PDO сопоставляют данные из приложения ведомого устройства с образом данных процесса EtherCAT.
  • Настраивается ведущим устройством при запуске на основе файла ESI и конфигурации ведущего устройства.
  • Передается в циклических датаграммах EtherCAT.
• Объекты сервисных данных (Service Data Objects или SDOs):
  • Используется для ациклического доступа к записям в словаре объектов (например, для чтения/записи параметров устройств).
  • Обычно используется механизм почтовых ящиков EtherCAT (который, в свою очередь, использует датаграммы EtherCAT).
  • Медленнее, чем PDO-соединение, используется для настройки и диагностики. EtherCAT предлагает различные протоколы почтовых ящиков, такие как CoE (CANopen через EtherCAT), SoE (сервопривод через EtherCAT), EoE (Ethernet через EtherCAT). CoE очень распространён.

Файлы информации ведомого устройства EtherCAT (ESI)

• Назначение: Файл ESI представляет собой XML-файл описания устройства. Он предоставляет ведущему устройству EtherCAT (и среде разработки) всю необходимую информацию о ведомом устройстве.
• Содержимое:
  • Информация о поставщике (название, идентификатор).
  • Информация об устройстве (код продукта, номер версии, имя устройства).
  • Поведение конечного автомата EtherCAT.
  • Элементы данных процесса (параметры сопоставления PDO).
  • Записи словаря объектов (если поддерживается CoE).
  • Конфигурация почтового ящика.
  • Параметры распределенной синхронизации.
  • Описания физических портов.
  • Ну и иногда иконки, обычно в формате ASCII, то есть берется каждый байт файла, и его представление в виде символов, сохраняется текстом (хотя бытует мнение, что в формате Base64). Например файл *.bmp, имеет первые два байта 0x42, 0x4D, это даже можно в блокноте прочитать открыв в нем файл картинки, так вот эти данные заменяются текстом 424D и так далее.
• Формат: Standardized XML schema defined by the EtherCAT Technology Group (ETG).
• Соглашение об именовании: Обычно это VendorName_DeviceName_Revision.xml или похожим образом.
• Роль: Инструмент настройки ведущего устройства импортирует файл ESI, чтобы понять возможности ведомого устройства, настроить его и настроить обмен данными процесса.

Важнейшая роль ведомого контроллера EtherCAT (ESC)

В отличие от некоторых полевых шин, которые можно реализовать преимущественно программно на микроконтроллере общего назначения, ведомые устройства EtherCAT требуют специального оборудования для реализации механизма «обработки на лету». Таким оборудованием является ведомый контроллер EtherCAT (ESC).

• Функциональность:
  • Обрабатывает низкоуровневый протокол EtherCAT (приём кадров, анализ, извлечение/вставка данных «на лету», пересылка кадров/циклическая обратная связь).
  • Управляет конечным автоматом EtherCAT.
  • Реализует интерфейс данных процесса (PDI) для обмена данными с ведущим микроконтроллером (в нашем случае ESP32). К распространенным PDI относятся SPI, параллельная шина (например, FSMC-подобная) или сигналы ввода/вывода.
  • Содержит память (DPRAM – двухпортовое ОЗУ или ОЗУ данных процесса), доступную как ведущему устройству EtherCAT (через сеть), так и ведущему микроконтроллеру (через PDI).
  • Реализует механизм распределенного времени (при наличии поддержки этого режима у слейва).
  • Генерирует прерывания для ведущего микроконтроллера при таких событиях, как изменение состояния, новые данные процесса, сигналы SYNC.
• Примеры ESC:
  • Beckhoff ET1100, ET1200 (ASIC).
  • FPGA IP различных производителей (например, Beckhoff, Hilscher, TI).
  • Микроконтроллеры со встроенными ESC (например, серии TI Sitara AMxxxx, серии Renesas R-IN32M).

ESP32 не может работать как ведомое устройство EtherCAT без внешнего ESC. Встроенный Ethernet MAC-контроллер ESP32 предназначен для стандартной Ethernet-связи; он не имеет специализированной аппаратной логики для обработки данных EtherCAT «на лету». Роль ESP32 заключается в том, чтобы выступать в качестве хост-процессора приложения для ESC..

WireShark

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

Дизайн программы постоянно меняется, поэтому теперь экраны выглядят чуть иначе. Буду приводить их по мере работы здесь, а нам для начала работы надо будет подключиться с EtherCAT, для этого можно подключить сетевой кабель, соединенный с машиной с Wireshark к свободному порту EtherCAT, например свободному порту конечного устройства (либо к роутеру EtherCAT). Даже в отключенном состоянии (контроллер в режиме STOP), мастер все равно интересуется жизнью на шине EtherCAT:

Так выглядела программа ранее, и так пользователь может видеть, что читает Wireshark

Чтобы избавиться от лишнего, можно активировать фильтр (листаем слайды), фильтры можно комбинировать указав and/or или &&/ || в качестве логических выражений, а так же not для отрицания.

Таким образом можно выйти на фильтрацию не просто пакетов EtherCAT, а даже более тонкой настройки, нажав Анализ→Показать фильтр отображения, можно посмотреть готовые фильтры по EtherCAT, так можно найти такие фильтры для EtherCAT frame Header как ecatf.type == 0x1 (EtherCAT Command), ecatf.type == 0x5 (Mailbox) или по полю длина в заголовке EtherCAT frame Header ecatf.length, либо воспользоваться встроенной системой автозаполенния и написав в фильтре ecat смотреть что предложит система, можно например отсечь по данным ecat.adp == 0x4 выбрав адрес получателя, либо ecat.cmd == 8 выбрав команду broadcast write read. Ну это все для примера. Кстати вот еще примеры, как работать именно с EtherCAT на Wireshark https://wiki.wireshark.org/protocols/ethercat.

Итак что же происходит на шине EtherCAT при инициализации?

Для определения состояния ведомых устройств считывается регистр 0x120. Возможны следующие значения:

01 – Init (Инициализация), 02 – Pre-Operational (Предоперационный), 03 – Request Bootstrap (Запрос начальной загрузки), 04 – Safe-Operational (Безопасный-операционный), 08 – Operational (Рабочий).

Отфильтруйте файл журнала по отправленным командам со значением регистра 0x120 и ознакомьтесь с разделом «Датаграммы EtherCAT» для получения подробной информации.

Фильтрация лог-файла по полученным командам со значением регистра 0x130

Появление значения 1 в четвёртом бите регистра 0x130 означает ошибку перехода. Подробнее см. значение регистра 0x134 (код состояния AL).

Обычно ведущее устройство отправляет кадр с рабочим счётчиком, равным 0, а затем получает этот кадр обратно с рабочим счётчиком, отличным от 0. Это означает, что кадр был отправлен, прошёл по шине и вернулся к ведущему устройству.

Если в какой-то момент в лог-файле Wireshark обнаруживается только отправленный кадр, но не полученный, это означает, что кадр потерян. В лог-файле Wireshark будет обнаружена пара отправки-приёма, но с ошибкой CRC или выравнивания, которую можно отобразить в лог-файле, если протокол ESL включён для показателей производительности (см. далее).

Если кадр прошел через шину, но каким-то образом был поврежден, в журнале Wireshark будет обнаружена отправленная-полученная пара, но с ошибкой CRC или выравнивания.

Для оценки джиттера отправки пакетов мастером нужно включить фильтрацию файла журнала по циклическим кадрам, отправленным Мастером

Отсортируйте журнал по столбцу «Время» и найдите минимальное и максимальное значения.

Разница между этими значениями — это джиттер. Обратите внимание, что джиттер должен составлять +/-10% от основного цикла.

Вот кстати пример работы ПЛК, здесь мы видим отсылаемую и возвращаемую посылки:

Здесь мы видим работу с регистром 0х101 настройка портов (пишем в слейвы)

После некоторого времени кучи «непонятной работы» с регистрами статуса мастер начинает наконец переводить слейвы в рабочий статус

Далее начинается работа работа уже по следующему сценарию:

Все еще продолжается работа с DC:

После стабилизации работы DC выставляем новый статус

В общем далее работа с SyncManager, FMMU и DC.