Реализация протокола EtherCAT

В предыдущей статье было описано, как создать свою первую программу для контроля движением по EtherCAT, а про сам EtherCAT в https://vk.com/@level174-ethercat-dlya-nachinauschih, но упрощенно как для базового уровня. Так как много действий по настройки проекта было описано без пояснений, а какие-то вопросы вообще остались без внимания, ну а дописывать уже написанные статьи не очень хотелось из-за и так не маленького объема, потому решил написать новую статью, где постараюсь описать по максимуму то, что касается нужных и важных моментов в работе EtherCAT и углубить понимание, но по факту постараюсь преподнести информацию так, чтобы для понимания прочтения других статей было необязательным.

Изначально статья задумывалась как перевод и адаптация статьи из обучающего курса 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 далее по тексту).
• Обсудить концептуальные подходы к взаимодействию микроконтроллера с ESC и управлению прикладной логикой ведомого устройства EtherCAT.
• Для мастера сети вы сможете понять основные действия, которые «лежат на плечах» ведущего устройства сети.
• Оцените различия между вариантами микроконтроллеров с точки зрения их пригодности в качестве хост-контроллеров для 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 автоматически замыкает логический цикл в этой точке и возвращает кадр.

Транспорт

Прежде чем перейти к пониманию дальнейшей информации прошу запомнить следующую конструкцию, если можно так сказать модели работы протокола (по аналогии с OSI у Ethernet), а именно сокращения, описывающие три уровня: PL, DL и AL. Это аббревиатуры от Physical layer, Data Link Layer и Application layer. Что включает каждый уровень будет подробно разобрано далее (хотя касаемо PL ряд информации уже представлен выше, а часть можно найти в EtherCAT_Communication_EN).

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

1 of 3

Условно это для фрейма 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.

1 of 4

• 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 по поводу адресации?

1 of 2

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

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

//Вот пример реализации отправки из SOEM:
for (slave = 1; slave <= *(context->slavecount); slave++) {
 ADPh = (uint16)(1 - slave);
 context->slavelist[slave].Itype = etohs(ecx_APRDw(context->port, ADPh, 0x0140, EC_TIMEOUTRET3)); /* read interface type of slave */

 /* a node offset is used to improve readibility of network frames */
 /* this has no impact on the number of addressable slaves (auto wrap around) */
 ecx_APWRw(context->port, ADPh, 0x0010, htoes(slave + EC_NODEOFFSET) , EC_TIMEOUTRET3); /* set node address of slave */
....

• Преднастроенный или фиксированный адрес (либо псевдоним или Alias): Главное различие между Station Address (0x0010) и Station Alias (0x0012) заключается в том, что первый — это динамический адрес, назначаемый главным устройством (мастером) во время запуска сети (кстати именно этот адрес пишется в регистр 0x0010 в примере кода с SOEM выше), а второй — это статический (или псевдонимный) адрес, который может быть заранее задан для устройства и сохраняется даже после выключения питания. Этот адрес затем может использоваться для последующей связи, а может и не использоваться, если со стороны PDI alias-ы запрещены регистром 0x0100 Register DL Control Bit. Первый Station Address пишется обычно согласно топологии со смещением EC_NODEOFFSET=0x1000, то есть адреса будут идти так: 0x1001,0x1002,0x1003. Второй Station Alias задан извне со стороны EEPROM (настройки например сервопривода).
• Логическая адресация (тут мы чуть перепрыгнули вперед Broadcast): Ведущее устройство настраивает логический образ данных процесса. Данные нескольких ведомых устройств могут быть сопоставлены с этим единым образом, что позволяет ведущему устройству считывать/записывать все соответствующие данные процесса с помощью одного кадра EtherCAT, содержащего несколько датаграмм.
• Ну и не забываем про Broadcast, то есть всем сразу или широковещательно, причем место под адрес все также используется: каждое ведомое устройство увеличивает позицию (само же поле не используется для адресации, ну это и понятно раз броадкаст).

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

Внутренняя память 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 приведена в таблице со смещениями в байтах, приведу здесь некоторые:

• 0x0000 — Type of EtherCAT controller для XMC =0x98 (чтобы убедиться что связь вообще есть можно прочитать нулевой байт)
• 0x0004 — Number of supported FMMU channels (or entities)
• 0x0005 — Number of supported SyncManager channels (or entities)
• 0x0006 — RAM Size (Process Data RAM size supported in Kbyte)
• 0x0008 — ESC Features supported (особенности: типа FMMU, возможностей DC, Enhanced Link Detection, поддержке команд EtherCAT BRW, APRW, FPRW read/write)
• 0x0010..0x0011 — Configured Station Address или преднастроенный/фиксированный адрес, используется при адресации командами FPRD/FPWR/FPRW/FRMW. Мастер этими командами может обращаться к конкретному слейву либо с помощью этого адреса, либо с помощью Alias/псевдонима. Адрес слейва записывается в настройки слейва мастером при инициализации сети (а не берется из настроек слейва), и не сохраняется, то есть зависит от питания. На картинке ниже это поле EtherCAT address в программе CODESYS. Alias в свою очередь это значение, записанное по смещению 0x012..0x013 (как раз следующий пункт списка, см ниже), выбор что будет использовать слейв для идентификации (считаем что мастер отправляя пакет понимает, что он будет сам в адрес писать) определяется настройкой слейва, а именно битом управления DL регистра 0x0100[24].

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

1 of 2

• 0x0040 — RESET_ECAT, мастер может удаленно перезагрузить засбоивший слейв.
• 0x0100..0x0103 — DL_CONTROL, jбычно работа идет с регистрами с адресом смещения 0х101, это настройки управление портами (открыт\закрыт).
• 0x0110 — DL_STATUS, состояние портов (есть ли линк)
  ну и хватит наверное. Подробности в документации.
• 0x0120..0x0121 — 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
• 0x0130..0x0131 — 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
• 0x0500..0x050B — регистры работы с EEPROM (SII), о них чуть ниже поподробнее…

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

EEPROM

Отдельная тема в работе Ethercat это взаимодействие с EEPROM нашего слейва, для этого существует SII или Slave Information Interface (работа с регистрами 0x0500 и далее). EtherCAT использует микросхемы EEPROM для хранения информации, связанной с устройством, включая конфигурацию устройства, его описание и другие данные, которые могут понадобиться мастеру при настройке и в работе EtherCAT. ESC или EtherCAT Slave Controller сам кэширует первые 8 слов (16 байт) EEPROM при загрузке. Эти данные загружаются в регистры конфигурации ESC (например, 0x0140 для типа PDI) только один раз - при включении питания или сбросе. Если вы изменили EEPROM, но не перезагрузили устройство - вы будете читать из регистров старые значения, даже если физическая EEPROM уже обновлена. Поэтому для чтения EEPROM следует учесть, что механизм работы немного более сложен, чем работа с DPRAM.

Практические методы гарантированного чтения EEPROM

1. Прямой доступ через регистры ESC (Обход кэша ESC)

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

Процедура чтения через регистры:

1. Проверить, не занят ли EEPROM со стороны PDI (Биты регистра 0x0500-0x0501)
2. Проверить, не занят ли EEPROM работой с самой EEPROM (Биты регистра 0x0502-0x0503 - Buisy Flag)
3. Записать адрес для чтения в регистр (0x0504-0x0507)
4. Запустить операцию чтения (биты регистра 0x0502, возможно одном залпом на регистры 0x0502-0x0507 - все 6 байт)
5. Проверить (да снова), не занят ли EEPROM работой с самой EEPROM (Биты регистра 0x0502-0x0503 - Buisy Flag)
6. Дождавшись, наконец, завершения, прочитать данные из регистра 0x0508-0x050B

2. Использование специализированных API

Большинство стеков предоставляют функции, которые корректно работают с EEPROM:

3. Принудительная перезагрузка конфигурации

Если вам нужно обновить именно конфигурационные регистры ESC (первые 8 слов), единственный способ - полный сброс питания устройства :

"EEPROM data modified. ESC needs to be powered on again to load the new EEPROM configuration data into the registers."

Это критично для таких параметров как:

• Тип PDI (Parallel/Serial/On-Chip bus)
• Включение DC (Distributed Clocks)
• Enhance Link detection

Данные, хранящиеся в EEPROM, представляют собой подмножество содержимого XML-файла устройства:

XML-файл устройства описывает данные конфигурации EEPROM, необходимые для ESC, следующим образом:

Как уже писалось при включении ESC считывает первые 8 слов (16 байт) из EEPROM для настройки его функций. Значения этих 8 слов загружаются в соответствующие регистры ESC для реализации его конфигурации. Поэтому необходимо понимать данные конфигурации EEPROM в соответствии с описанием соответствующих регистров.

ESC выполнит проверку контрольной суммы первых 8 слов данных в EEPROM. Если проверка контрольной суммы не пройдена, EEPROM будет загружена некорректно (0x110[0]), что повлияет на работу некоторых функций ESC. При возникновении проблемы с контрольной суммой EEPROM сначала следует решить проблему с данными EEPROM.

Приведенные выше данные конфигурации EEPROM показывают 800C8166000000001234, что первый байт 0x80 будет загружен в регистр ESC 0x140, который используется для настройки типа интерфейса PDI ESC. Второй байт 0x0c будет загружен в регистр ESC 0x141, который определяет, включает ли ESC DC и включает ли функцию обнаружения Enhance Link.

Примечание: В периферийных устройствах ESC от Xianji некоторые значения регистров фиксированы на этапе проектирования микросхемы и не могут быть изменены данными конфигурации EEPROM. Например, тип интерфейса PDI периферийного устройства ESC от Xianji фиксирован на значении 0x80: тип шины на кристалле. Поэтому, даже если первый байт данных конфигурации EEPROM будет изменен на другое значение, значение 0x140 в регистре ESC изменить нельзя. Существует несколько других подобных случаев.

Примечание: Функция Enhance Link detection используется для отключения соответствующего порта и запуска повторного согласования PHY в случае разрыва соединения порта или резкого увеличения RX_ER. Эту функцию не следует использовать, если адрес PHY настроен неправильно. Как правило, ее следует отключить.

Когда главная станция TwinCAT сканирует подчиненные устройства, она считывает данные идентификатора производителя/кода продукта/номера ревизии/серийного номера, хранящиеся в EEPROM, и сопоставляет их с XML-файлом подчиненного устройства, хранящимся на главной станции, для идентификации подчиненного устройства.

Данные EEPROM можно обновить с помощью таких инструментов, как TwinCAT и EEPROMProgrammer. После изменения данных EEPROM требуется перезагрузка питания после ESC для загрузки новых данных конфигурации EEPROM в регистры.

Типичные ошибки и как их избежать

1. Ошибка: Чтение EEPROM во время работы
   1. Функции чтения EEPROM нельзя вызывать в циклическом callback'е
   2. Решение: выполняйте чтение/запись EEPROM только в однократном режиме, вне реального цикла
2. Ошибка: Не проверен флаг занятости EEPROM
   1. Если EtherCAT стек использует EEPROM (например, для хранения данных mailbox), прямая запись приведет к ошибке
   2. Решение: всегда проверяйте регистр 0x0500 перед операциями
3. Ошибка: Игнорирование checksum
   1. ESC проверяет checksum первых 8 слов при загрузке
   2. Если checksum неверен - регистры не обновятся, бит 0x110[0] укажет на ошибку
4. Ошибка: Неверная длина чтения/записи
   1. Все операции с EEPROM должны быть word-aligned (четный адрес, четная длина)

Рекомендуемый подход для гарантированного чтения

Если вам нужно прочитать актуальные данные физического EEPROM:

1. Для конфигурационных данных (первые 16 байт):
   1. Либо читайте напрямую из регистров (они отражают загруженное при старте)
   2. Либо перезагрузите устройство и выполните прямое чтение EEPROM
2. Для пользовательских данных EEPROM:
   1. Используйте API вашего стека с блокировкой доступа
   2. Всегда проверяйте регистр 0x0500
   3. Читайте четными блоками

Кстати одна из классических "ловушек" для новичков в SOEM это работа с адресом. В спецификации EtherCAT и документации на устройства адреса в EEPROM обычно указываются в байтах. Но внутренняя организация доступа к EEPROM и константы в SOEM работают с 16-битными словами. Например ECT_SII_START = 0x0040 — это адрес в байтах. Константа ECT_SII_START определена как 0x0040 (64 в десятичной системе). Это стандартный стартовый адрес категории SII (Slave Information Interface) в EEPROM, отсчитываемый от начала памяти в байтах .

Регистры доступа к EEPROM работают со словами

Когда вы читаете EEPROM через регистры ESC (0x0500-0x050F), адрес, который вы записываете в регистр 0x0504 (EEPROM address), интерпретируется как адрес 16-битного слова, а не байта . Если вам нужно прочитать данные, начиная с байтового адреса 0x0040, это соответствует слову с адресом 0x0020 (64 байта / 2 = 32 слова). Причина умножения/деления на 2 кроется в разнице между адресацией в байтах и адресацией в словах (16-битных) в EEPROM.

// Пример из исходников SOEM
// Чтение SII данных начинается с адреса 0x0040 (в байтах)
// ecx_readeeprom ожидает адрес в СЛОВАХ, поэтому умножаем
ecx_readeeprom1(context, slave, ECT_SII_START * 2); 

Команды

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

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

• 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-часов, позволяющий синхронизировать временные интервалы для slave-устройств. Задача механизма распределенного времени заключается в том, чтобы эти счетчики на всех слейвах работали синхронно (с минимальным джиттером и в меньшей минимальной мере задержкой). Это нужно для задач обработки задания на синхронизированное движение, то есть когда координаты приводов зависят друг от друга, то косвенно это зависят от времени активации команд, полученных от мастера, но время поступления которых не возможно синхронизировать.

В сети EtherCAT механизм синхронизации времени реализован полностью аппаратно. Часы на slave-устройствах могут легко и точно измерить задержку относительно других часов, так как для связи используется логическая и полнодуплексная физическая кольцевая структура Ethernet, т.е. каждый пакет EtherCAT проходит дважды через каждое slave-устройство (прямой и обратный путь по разным витым парам). На основе этого значения задержки производится подстройка распределенных часов, что позволяет достичь очень точной временной базы с разбросом существенно меньше 1 мкс в масштабах всей сети. Проще всего понять механизм на примере кода из SOEM, там есть файлы, относящиеся к DC, — это ethercatdc.c и ethercatdc.h. Основные используемые здесь функции — это ecx_configdc, ecx_dcsync0, ecx_dcsync01, ecx_porttime, ecx_prevport и ecx_parentport.

ecx_porttime - эта функция очень проста, она возвращает время фиксации порта на основе номера ведомого устройства и номера порта, которые в примере на картинке ниже равны tA0, tB0, tC0…tE1, tB2, tA1. ecx_parentport - эта функция находит порт предыдущего ведомого устройства, подключенного к текущему ведомому устройству (для текущего это предыдущие по пути движение пакета от мастера). ecx_configdc - основной регулятор DC. В ней производится отправка пакета записи в регистр 0x900 посредством широковещательной рассылки ecx_BWR например нуля «0». Каждый порт фиксирует время поступления первой преамбулы этого кадра данных. Время, зафиксированное четырьмя портами (0-3), хранится по адресам 0x900, 0x904, 0x908 и 0x90C соответственно. Далее с помощью ecx_FPRD можно получить текущее время каждого узла и преобразовать его в наносекунды (нс) как смещение относительно даты 2000-01-01. Ну естественно нужно отделить модули, не обладающие DC, естественно предварительно мастер изучает топологию сети, чтобы понять последовательность опроса узлов и интерпретацию полученных данных.

Далее отрабатывает регулятор:

Считываем время фиксации ведомых портов 0, 1, 2 и 3 и сохраняем их в переменных DCrtA, DCrtB, DCrtC и DCrtD соответственно.

Считаем локальное время ведомой станции (0x0918), используем текущее время ведущей станции в качестве системного времени и вычисляем отклонение между временем ведомой станции и локальным временем.

Запишем отклонение времени в регистр 0x0920.

1 of 6

Если вкратце работа контроллера распределенного времени состоит из 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 (offset) для каждого слейва. Каждый из подчиненных внутри себя имеет входную и выходную отметки времени, по которым можно легко вычислить на сколько задерживается пакет на каждом из подчиненных. После сбора всех временных отметок (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 — сдвиг времени, обычно автоматически определяется правильно при старте системы. При условии, что система работает и построена правильно.

1 of 17

Ну и еще раз закрепим - возможны три режима взаимодействия связки мастера и слейва и конструкции распределенных часов, а также прикладного ПО, которое крутится на мастере и на слейве (синхронизации):

1. Free Run

Связь EtherCAT и приложение работают независимо друг от друга. Этот режим самый простой, тк как таковая синхронизация отсутствует, устройства не обязательно должны поддерживать распределенное время, тк никакой синхронизации не потребуется, команда от мастера поступает на слейв и время исполнения при этом считается не критичным, обычно выбирается либо при наладке, либо когда не требуется детерминированное время исполнения инструкции. Прикладная задача запускается по внутреннему таймеру слейва, короче независимо от того, какой цикл связи или как того хочет мастер. То есть цикл работы слейва в виде обрабока→вывод данных—>ввод данных не привязан к периоду работы мастера можно сказать никак.

2. Synchronized to SyncManager (SM-SYNCHRONOUS mode)

Еще этот режим называют синхронизированным по сообщениям ввода или вывода, но тк этим процессом при обмене PDO рулит SyncManager, то и по сути синхронизация идет именно по событиям SyncManager-а.

Обработка данных процесса запускается синхронно с генерируемым мастером периодическим кадром данных, который принимает слейв. Слейв обычно синхронизируется с событием Output (записываемые в слейв). Если выходные данные не используются, для синхронизации используется событие Input (чтение со слейва). Не самая точная синхронизация, тк действия, которые производит подчиненное устройство запускаются с определённым джиттером, который далек от идеала (не меньше микросекунды).

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

3. Synchronized to SyncSignal (DC-SYNCHRONOUS)

Приложение синхронизировано с SyncSignal, а он в свою очередь синхронизирован с часами DC, джиттер которых может быть настроен на точность в несколько наносекунд, что на 3 порядка лучше режима SM-SYNCHRONOUS mode.

Дополнительную информацию см. в соответствующем разделе информационной системы EtherCAT.

Время передачи данных с использованием синхронизации поясняется на рисунке.

1 of 2

IO(Master)

Время загрузки данных ввода-вывода в буфер связи и наоборот.

Calc(Master)

Время обработки мастера.

Frame(Communication)

Время передачи IO-Data-Frame (около 5 мкс накладных расходов плюс 80 нс на байт данных).

D(Communication)

Время задержки передачи данных ведомыми устройствами EtherCAT (приблизительно 1 мкс с 100BASE-TX, плюс задержка линии приблизительно 5 нс на м).

Jitter(Communication)

Зависит в основном от качества мастер-синхронизации.

U(Communication-Master)

Время смены регулируется внутри главного устройства с целью устранения задержек, необходимых главному устройству, и корректировки времени цикла.

U(Slave)

Время задержки ведомых устройств EtherCAT. Оно может быть установлено каждым ведомым устройством индивидуально и обычно равно 0. Необходимость в установке этого параметра возникает в случае неточностей синхронизации ведомого устройства или для ведомых устройств с медленным выводом по сравнению с другими устройствами с высокой скоростью вывода.

Cycle Time Jitter

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

SyncManager

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

1 of 6

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) Количество байтов, назначенных SyncManager (должно быть больше 1, в противном случае SyncManager не активируется. Если установлено значение 1, генерируется только триггер сторожевого таймера, если он настроен)

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 — для обмена быстроменяющимися данными, такими как PDO. Один все время пишет а второй читает последнюю согласованную копию.

• 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.

1 of 11

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

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

FMMU или Fieldbus Memory Management Unit

1 of 2

Эти модули находятся между соответствующим 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

1 of 15

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

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

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

1 of 3

Словарь объектов (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:

1 of 3

Чтобы избавиться от лишнего, можно активировать фильтр (листаем слайды), фильтры можно комбинировать указав 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% от основного цикла.

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

1 of 21

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

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

1 of 4

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

1 of 3

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

1 of 2

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

А вообще если вдруг захотите разобраться и разработать что-то свое, то «велосипеды» уже есть, в первую очередь это Open source реализация Simple Open EtherCAT Master (SOEM), по ссылке https://github.com/OpenEtherCATsociety/SOEM от rt-labs (хотя по определенным данным это Open EtherCAT Society, но вроде все одно). Его можно адаптировать его к STM32F207/F407/H743 и FreeRTOS. Можно и на компе запустить, правда под виндой боюсь навыков не хватит сделать именно с реал-таймом, чтобы успевало в окно попадать синхронизации, поэтому большинство написано под Linux. Но это не самый крупный проект, есть и покрупнее - это IgH EtherCAT-Master® (EtherLab®) (ссылки https://etherlab.org/en_GB/ethercat, )

Их сравнение можете глянуть здесь: https://www.acontis.com/en/ethercat-master-options-ec-master-vs-open-source-etherlab-SOEM.html или https://visutechsystem.by/sravnenie-programmnyh-stekov-ethercat-master/ у наших братьев-Белорусов.