EtherCAT Device Protocol

EtherCAT Device Protocol используется только для обмена данными между подчиненным устройством и мастером.

Фрейм

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

Изображение: Beckhoff Automation GmbH (EtherCAT Slave Controller v2.2 2014-07-07)

EtherCAT телеграмма состоит из нескольких EtherCAT датаграмм, которые, в свою очередь, состоят из заголовка (header), данных (data) и 16-разрядного счетчика работоспособности WC (WkC, Working Counter).

Каждый подчиненный, выполнивший EtherCAT команду (чтение или запись — не важно), увеличивает значение счетчика WC на единицу или больше, в зависимости от типа команды. Получая пакет обратно, мастер знает сколько у него подчиненных и может сравнить ожидаемое значение счетчика с актуальным значением. Это позволяет системе определить полноценность исполнения EtherCAT команды.

Для представления данных датаграммы (Data) используется Mailbox Protocol. Кроме родного протокола ADS и его пакетов, в эту структуру можно уложить пакеты другого протокола, достигая трансляции вообще любых протоколов через EhterCAT. Например: CANOpen, SERCOS, PROFIbus и т. п.

Наиболее интересным будет заголовок EtherCAT датаграммы (Datagram Header). Он состоит из команды (Cmd) и адреса данных (Address). Адрес может быть автоинкрементальным, фиксированным (физическим) или логическим. Команда EtherCAT диктует, что делать с данными, расположенными по указанному адресу. Кроме этих двух полей, в заголовке расположены другая полезная информация:

• Index (индекс) — номер датаграммы, для контроля за дублированием или повторением датаграмм.
• Length (длина) — длина данных в датаграмме.
• R — зарезервирован.
• C (флаг циркуляции) — в случае обрыва соединения с мастером, фрейм может начать бегать по кольцу из подчиненных. Это не корректно.
• M (последняя ли датаграмма?) — последняя ли это датаграмма в EtherCAT-фрейме.
• IRQ (EtherCAT Event Request) — это поле необходимо для уведомления мастера о событиях, произошедших на подчиненных. Неизвестно кто из подчиненных непосредственно был инициатором события, поэтому программное обеспечение мастера должно самостоятельно разобраться с этим.

Команды

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

Действия:

• NOP — нет операции, подчиненный игнорирует эту команду.
• ..RD — записать в датаграмму считанные модулем данные (например, модуль дискретных входов).
• ..WR — запись данные из датаграммы в память по заданному адресу (например, де/активация выходов модуля дискретных выходов).
• ..RW — обмен данными датаграмма-память.

Адресация:

• AP.. — подчиненный наращивает автоинкрементальный адрес и что-то делает, если автоадрес получился равным нулю.
• FP.. — что-то сделать, если адрес в датаграмме соответствует одному из сконфигурированных адресов подчиненного.
• L.. — что-то сделать, если адрес в датаграмме соответствует логическому адресу FMMU-области (см. ниже).
• B.. — все подчиненные наращивают позицию.

Примечания:

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

Упрощенно используется два вида адресации:

• Автоинкрементальная (Auto Inc Addr) — используется для идентификации физического (реального) положения устройства на шине EhterCAT. Он наращивается автоматически и необходим для автоматического назначение адреса для каждого подчиненного шины. Первый подчиненный получает автоматический адрес = 0 (0x0000); второй подчиненный — автоадрес = 0xFFFF, третий = 0xFFFE.
• Фиксированный адрес (EtherCAT Addr) — нужен для работы с модулем как с отдельным устройством (например, через CoE, CAN over EtherCAT). Если рассматривать внешнюю адресацию AmsNetId, то фиксированный адрес соответствует номеру порта устройства на шине (AmsNetId-подчиненного = AmsNetId-мастера).

Отображение

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

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

Изображение: EtherCAT Technology Group (ETG.2200 V2.1.4)

SyncManager

Обеспечивает согласованность передачи данных, синхронизирует их, предотвращая одновременный доступ к памяти контроллера (DPRAM). Всего SyncManager может быть до 16 штук. Они могут работать в двух режимах:

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

PDO в TwinCAT

Зоны в закладках System Manager → Process Data:

• Download
• PDO Assignment — можно изменять список готовых PDO (добавлять или исключать объекты-пакеты).
• PDO Configuration — можно изменять PDO (дополнять, убирать параметры в объект-пакет).
• SyncManager — какие SM и какого типа доступны для данного устройства.
• PDO Assignment — список PDO доступных для данного SyncManager и объектов которые включены для обмена. В зависимости от доступности, которое видно в зоне Download → PDO Assignment, это содержимое можно изменять.
• PDO List — словарь PDO, доступных для данной железки.
• Index — индекс PDO.
• Size — размер в байтах.битах (через точку).
• Name — Имя PDO. Если данный PDO закреплен за SyncManager, то данный PDO появится как параметр/переменная в дереве конфигурации контроллера с данным именем.
• Flags.
• F — неизменяемый PDO (Fixed), нельзя изменить состав данного PDO.
• M — обязательный (Mandatory).
• SM — номер SyncManager за которым закреплен данный PDO. Если не закреплен, то PDO не участвует в обмене данными.
• SU — номер SyncUnit за которым закреплен данный PDO.
• PDO Content — содержимое PDO (набор параметров которые будут передаваться или синхронизироваться совместно). В зависимости от доступности, которое видно в зоне Download → PDO Configuration, это содержимое можно изменять.

Полностью конфигурируемые PDO выглядят как:

Фиксированный набор PDO модуля дискретных сигналов:

• Predefined PDO Assigment — заранее подготовленные профили или наборы PDO.
• Load PDO info from device — выгрузить информацию о PDO из устройства, иначе будут использоваться локальные словари из каталога x:\TwinCAT\Io\EtherCAT.
• Sync Unit Assigment... — распределить PDO по фреймам.

Подробнее о настройках можно прочитать в справочной системе EtherCAT Slave Device.

EtherCAT Automation Protocol

Пробежим по EtherCAT от транспортировки пакетов, до синхронизации на уровне переменных в размеченных областях памяти.

Транспорт

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

Изображение: beckhoff.com

Фрейм

Упрощенно EtherCAT фрейм состоит из заголовка и данных, но сейчас нам будет интересен только заголовок (header), который в свою очередь состоит из поля длины и поля типа данных, который определяет протокол передачи данных внутри пакета:

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

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

Подробнее о структуре фрейма EAP можно прочитать в справочной системе — EAP telegram structure.

Синхронный обмен

Ключевые слова — PD, PDO. Максимальная длина EtherCAT-телеграммы — 1472 байта. Синхронный обмен происходит с помощью следующей сетевой матрешки:

Изображение: beckhoff.com

Телеграмма состоит из заголовка Process Data Header (PDH) и одного или нескольких операционных наборов данных Process Data (PD). Заголовок содержит Publisher Id — уникальный идентификатор устройства отправителя (издатель, publisher) данных. Кроме него есть счетчик, нарастающий каждый цикл, и поле с общим количеством блоков, расположенных в PD.

Каждый операционный набор (PD, Process Data) состоит из одного или нескольких PDO. Каждый PDO состоит из заголовка PDO Header и одной или нескольких переменных PDO Variables. PDO Header содержит идентификатор переменной и ряд других полей: версия PDO, длина PDO, свежесть данных в 100 микросекундных интервалах.

Если асинхронный обмен может происходить в произвольные моменты времени, то синхронный обмен обязан происходить через равные промежутки времени, что достигается двумя способами:

1. Pushed Data Exchange (способ проталкивания) — когда "издатель" (Publisher) отправляет PD в сеть через равные промежутки времени или при изменении своего состояния, а "подписчик" (Subscriber) принимает и обрабатывает. Таким образом работают "сетевый переменные" (Network Variables) в TwinCAT 2. За один раз отправляется и принимается один фрейм данных.
2. Polled Data Exchange (опросный способ) — когда "клиент" отправляет запрос, в котором содержится его PD, а в ответ получает отдельный фрейм ответа с PD информацией сервера. Работает клиент-серверная архитектура, поэтому суммарно в общении участвуют два сетевых фрейма.

Здесь внезапно проявляется различие в работе протоколов EtherCAT Device Protocol и EAP, так как в случае с Device Protocol формируется один единственный большой пакет, в котором заранее предусмотрено место для данных подчиненных устройства. По мере прохождения пакета через кольцо EtherCAT-шины в эти пустые места EtherCAT-фрейма "на лету" будут вставляются данные подчиненного устройства. Это очень быстро.

В случае же с EAP можно достичь 10 миллисекундного отклика, если применяются свичи и гигабитный Ethernet; и 100мс отклик, в случае применения UDP/IP роутинга. Это медленнее, но более гибко и можно запускать через интернет. При этом не стоит забывать, что параллельно в сетях Ethernet могут общаться и другие устройства, что в свою очередь может привести к нарушении синхронности обмена сообщениями.

Pushed (1) способ передачи позволяет передаваться данные как на одно устройство, так и на группу устройств:

• Unicast: один издатель — один подписчик.
• Multicast: один издатель — группа заданных подписчиков.
• Broadcast: один издатель — все доступные устройства.

Polled (2) способ передачи связывает только два конкретных устройства.

Триггеры

Отправка EAP телеграм основана на механизме триггеров: происходит какое-то событие и если условие выполнено — происходит отправка ответа. Не рекомендуется использовать одновременно несколько условий для срабатывания триггера, так как система не может гарантировать их взаимодействие между собой.

Существует пять различных условий для срабатывания триггеров:

1. Poll Request Rx PD — пришла телеграмма опроса.
2. Divider/Modulo — регулярная отправка. Divider — это множитель для времени цикла отправки, Modulo — множитель для ожидания перед первой отправкой (смещение первой телеграммы).
3. Cycle Time — отправка через заданный интервал в микросекундах. Отношение интервала цикла передачи и длительность цикла задачи должны быть кратны целому числу.
4. Изменение состояния по таймауту (Change of State, CoS) — отправка происходит при изменении значения переменной. Если значение не менялось в течении заданного времени (в миллисекундах), то происходит повторная отправка того же значения, что и в прошлый раз.
5. Изменение состояния с гарантированным интервалом (Change of State, CoS) — отправка происходит при изменении значения переменной. Между отправкой старого и нового значений должно пройти не меньше заданного времени  (в миллисекундах).

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

Подробнее о механизме триггеров — EAP Send Mechanism.

Конфигурирование

Ранее, в TwinCAT 2, такая модель называлась "сетевыми переменными" (Network Variables). В TwinCAT 3 ее назвали своим именем EtherCAT Automation Protocol. Так или иначе, в начале вы создаете несколько переменных базовых типов или даже структур, а затем TwinCAT автоматически транслирует их через Ethernet на другие устройства (контроллеры, ПЛК, и т. п). Тем самым вы получаете более-менее синхронные данные на обеих сторонах, без необходимости в написании кода для поддержки сетевой передачи данных программой.

Создание EAP-конфигурации:

• Добавление EAP устройства.
• Отправка переменных (источник данных).
• Подписка на переменные.
• Использование типов данных пользователя (структуры).

Конфигурирование EAP-устройства:

• EAP устройство.
• Издатель (Publisher Box).
• Переменные издателя.
• Подписчик  (Subscriber Box).
• Переменные подписчика.
• EAP между TwinCAT 2 и TC3 — обмен данными работает в обе стороны. Автоопределение сетевых переменных (Browse for Computer, Browse for File) работает только в одну сторону: TwinCAT 3 автоматически подхватывает переменные из TwinCAT 2.