среда, 29 марта 2017 г.

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.

Комментариев нет :

Отправить комментарий