Вебинар. Введение в K-Bus и терминалы серии KL3xxx

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

Вещал Мартин Подрушек (Martin Podrouschek): Beckhoff K-Bus and analog inputs. Introduction of KL3xxx terminals.

В 70-х годах прошлого века (ого!) была принята трехступенчатая система: ПЛК ↔ много-много-модулей-ввода-вывода ↔ сенсоры/актуаторы (исполнительные механизмы). В 95-м году Бекхофф предложил собрать все это в одном устройстве "интеллектуальная система терминалов шины" (intelligent bus terminal system) и в итоге получился Profibus bus coupler BK3000:

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

Кроме коплера как обычного транслятора пакетов данных (коплеры BKxxxx) были разработаны программируемые коплеры с мозгами — серия BCxxxx.

Внутренности и способности

Условно можно разделить систему на два уровня передачи данных: уровень полевой шины до коплера и уровень периферийных устройств — внутренняя шина (K-bus), то есть внутренняя шина между коплером и терминалами. Из-за такой сепарации возникает проблема диагностики, так как отсутствует непосредственная прямая связь между внешней полевой шиной и терминалами.

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

Система поддерживает максимум 256 дискретных устройств ввода/вывода или 128 аналоговых. Так как после 64 терминалов обязательно необходим модуль подпитки шины, то в итоге максимально возможное число модулей сокращается до 250.

Каждое устройство может поддерживать до четырех каналов ввода/вывода. Каждый канал — это всего-лишь 3 байта данных. Если нужно больше каналов, то придется мультиплексировать, дробить время обработки, сокращая другие каналы. Хорошая новость — все это решается на уровне коплера. Также ограничено суммарное количество регистров на канал — 64 регистра. Если нужно больше, то вводят вторую страницу регистров.

Типичное время цикла коплера 1..2 миллисекунды.

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

Внутри память модуля разбита на две области: область входов и область выходов. Каждая из этих областей в свою очередь разбита на область байтовой памяти (регистры данных для аналоговых входов/выходов) и область битовой памяти (дискретные входа/выхода).

Доступ к регистрам

Способ первый: через специальную платную программу KS2000 и специальный кабель Serial/USB KS2000-Z2-USB.

Изображение: Beckhoff Automation

Способ второй: программный, через ПЛК Бекхофф по шине с помощью функциональных блоков библиотеки Tc2_Coupler.lib.

Способ третий: инженерный в режиме FreeRun или Run доступ к регистрам через TwinCAT System Manager: тыкаем правой кнопкой в коплер в дереве конфигурации и выбираем Register Access...

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

Сравнение и выводы

	K-Bus (1995 год прошлого века)	EtherCAT, E-Bus (2003 год настоящего века)
Идентификация устройства	нет	производитель и код продукта
Стоимость	сложный и дорогой	простой и дешевый
Передача данных	меньше 10 мегабит	быстрая, до 10 гигабит
Синхронизация	нет	жесткая, распределенные часы с погрешностью меньше 100 наносекунд
Операционный образ данных	4x12 байт	теоретически можно до 65 килобайт, практически используется 8 килобайт
Диагностика	двух-шаговая	непосредственная
Доступ	опосредованный через регистры	непосредственный CAN-через-ADS (CoE)

Вывод я вам лучше нарисую:

EtherCAT SyncUnit

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

TwinCAT старается объединить все данные в одну единственную большую датаграмму и только затем отправить ее по шине. Тем не менее существуют ситуации, когда должен вмешаться специалист чтобы изменить компоновку фрейма, разбивая его на две, три или даже большее количество частей-фреймов. Для этого у специалиста есть инструмент под названием SyncUnit (SU) — модуль синхронизации.

SU необходимы и работают только для циклического обмена данными.

Модули синхронизации

• Для циклического обмена данными с подчиненными устройствами, каждому SU отводится отдельная команда EtherCAT. Можно сказать, что модули синхронизации добавляют отдельные команды во фрейм или что они выделяют соответствующие PDO в отдельную команду EtherCAT и позволяют обособить один PDO от другого.
• Можно комбинировать данные разных подчиненных устройств.
• Каждый SU имеет свою собственную диагностику.
• Выполняет контроль ошибок и целостности циклической передачи данных.
• Осуществляет независимый контроль ошибок: ошибка в одном модуле, не влияет на другой.
• В случае ошибки, можно продолжать работать даже когда недоступна часть системы.
• SU позволяет вмешиваться в работу TwinCAT, в то же время оставаясь полностью автоматической и самостоятельной системой, не требующей настройки.
• Каждый подчиненный может сформировать свой собственный операционный образ, которому гарантируется целостность и синхронность передачи.
• Количество независимых операционных образов зависит от реализации EtherCAT Slave Controller (ESC), то есть от количества SyncManager и доступных каналов FMMU.
• Команда BRD отправляется в задаче с самым низким приоритетом.
• Создавать и управлять новыми SU можно как из настроек подчиненного, так и настройками всей шины EtherCAT.

Не забывайте, что SyncManager и SyncUnit — это разные вещи! Несмотря на то, что на картинке ниже для операционного образа (PDO) используются разные SyncManager (SM): один для входящих, другой для исходящих данных; модуль синхронизации (SU) у них одинаковый, то есть он синхронизирует как ввод, так и вывод данных фрейма.

Для диагностики ошибок существует система счетчиков работоспособности (Working Counter, WkC, WC). Мастер отправляет датаграмму с WC = 0 и ожидает, что датаграмма вернется со счетчиком WC > 0 и WC равному определенному значению, которое мастер определил еще на этапе конфигурации.

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

Справочная система о Sync Unit Assignment.

SyncTask

Всего доступно четыре задачи синхронизации (Sync Tasks) — это задачи осуществляющие обмен данными через шину. Максимально доступное число задач можно изменить в настройках EtherCAT-шины, см. Sync Tasks.

Каждая такая задача TwinCAT (Task with I/O), осуществляющая циклический обмен данным, имеет свой собственный SyncUnit-фрейм. Ее данные отправляются независимым фреймом так, что чтение/запись операционных данных может происходить с разным временем цикла. Это значительно снижает нагрузку шины, а дробление на фреймы производится автоматически, не затрудняя разработчика.

Одна задачи = один фрейм Ethernet = от одной до 15 датаграмм (один фрейм Ethernet способен передавать до 1480 байт). Обычно создается новый фрейм, когда передается больше 15 датаграмм (здесь и только здесь, датаграмма будет соответствовать команде EtherCAT). Также новый фрейм будет создан, если передается больше 1480 байт. Новый фрейм будет иметь аналогичное время цикла.

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

Практика и работа над ошибками

Возьмем два 16-разрядных модуля ввода дискретных сигналов EL1809 и аналогично вывода EL2809. Создадим дополнительную задачу (Additional Tasks) с временем цикла 10 миллисекунд:

#0 LWR, 4 байта, SyncUnit <default>, 10 мсек — модули выходов, два раза по 16 входов = 32 бита / 8 = 4 байта.
#0 LRD, 4 байта, SyncUnit <default>, 10 мсек — модули входов
#0 BRD, 2 байта, SyncUnit <default>, 10 мсек — пока не интересно

Теперь будем читать входа каждые 10 мсек, а отправлять задания на выхода каждые 100 мсек, то есть в десять раз реже, чем ввод (очень похоже на оверсамплинг, только медленнее). Для этого создадим отдельную задачу Task 2:

#0 LRD, 4 байта, SyncUnit <default>,  10 мсек.
#1 LWR, 4 байта, SyncUnit <default>, 100 мсек.
#1 BRD, 2 байта, SyncUnit <default>, 100 мсек.

Так как время цикла задачи отличается — TwinCAT создает второй фрейм #1. Команда BRD при этом уходит во фрейм низкоприоритетной задачи #1.

Низкий приоритет не означает более длинное временем цикла. Не путайте приоритет и время цикла!

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

Для этого подчиненный должен поддерживать эту возможность, о чем изготовитель модуля указывает в ESI-спецификации модуля. Включить поддержку этой функции в мастере можно через:
EtherCAT → Advanced Settings... → State Machine → Slave Settings → Cyclic Frames → Frame Repeat Support.

После этого TwinCAT добавляет во фрейм #0 еще одну команду LRD (теперь во фрейме две команды LRD):

#0 LRD, 2 байта,SyncUnit <default>, 10 мсек — один модуль дискретных входов Term2.
#0 LRD, 2 байта, Term4, 10 мсек — другой модуль дискретных входов Term4.
#1 LWR...
#1 BRD...

Теперь диагностика этих модулей будет происходить раздельно.

Новый эксперимент — я хочу одним из модулей выходов управлять быстрее. Для этого будет использоваться третья задача Task3 с временем цикла 15 миллисекунд:

Появляется третий фрейм #2 с командой LWR:

#0 LRD...#0 LRD...
#1 LWR, 2 байта, SyncUnit <default>, 100 мсек.
#2 LWR, 2 байта, SyncUnit <default>, 15 мсек.
#2 BRD, 2 байта, SyncUnit <default>, 15 мсек.

Приоритет задачи Task3 ниже чем у Task1 и Task2, поэтому команда BRD уползла во фрейм #2 задачи Task3:

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.

Сервер Modbus TCP

Протокол Modbus поддерживается практически всеми производителями и реализован на многих устройствах. В TwinCAT он существует в виде модбас-сервера как для десктопа, так и для компактной Windows CE:

TS6250 | TwinCAT Modbus TCP Server
TS6250-0030 | TwinCAT Modbus TCP Server CE

В 8000 серии модбас-сервер уже встроен, но про 8000 серию мы разговаривать не будем, так как она мне не нравится.

Итак, чтобы установить — прочтите руководство по установке. Там все просто и подходит для всех видов операционок.

После установки получаем сервер и библиотеку с функциональными блоками. Библиотека позволяет использовать произвольные функции Modbus, работать в роли клиента или использовать UDP-протокол вместо скучного и надежного TCP.

Для передачи данных чаще используют заранее подготовленные глобальные переменные или области памяти, но если очень хочется, то порт и прочие настройки можно переназначить в файле настроек — TcModbusSrv.xml. Там же можно переназначить порты ADS и адреса смещений. В операционной системы CE | Compact файл должен лежать в \hard disk\system. Если его там нет — значит сервер настроен по умолчанию. Работа с файлом конфигурации описана в Mapping between Modbus and ADS.

Для настольных операционных систем существует готовый конфигуратор, после установки лежащий в x:\TwinCAT\TcModbusSrv.

Тонкая настройка сервера

Все начинается с <Configuration>. По умолчанию, как это принято в сетях Модбас, коммуникационный сетевой порт равен 502:

<!-- Modbus TCP port, default = 502-->
<Port>502</Port>

Далее идет раздел маппинга: <Mapping>, в котором задается отражение адресного пространства Modbus на адресное пространство операционного образа ПЛК или, проще говоря, к каким областям памяти контроллера приведут заданные адреса Modbus.

Начинаем конфигурировать дискретные входа (биты дискретных входов только для чтения): <InputCoils>. Если вы внезапно забыли о функциях Modbus — кратко ознакомьтесь с обзорной статьей: она короткая и надолго вас не задержит.

Задаем стартовый адрес пространства Modbus: <StartAddress>0</StartAddress>
...и конечный адрес: <EndAddress>32767</EndAddress>

Остается настроить место, куда эти адреса приведут на стороне контроллера. ADS-порт выбирает устройство на шине EtherCAT. 801 — это стандартный порт первого рантайма ПЛК-задачи:

<!-- AdsPort: TwinCAT2 PLC1 = 801, PLC2 = 811...-->
<AdsPort>801</AdsPort>

Затем идет индекс группы и смещения. Они конкретизируют переменные, области памяти и пр.:

<!-- IndexGroup 61473 = 0xF021 -> physical plc inputs %IX -->
<IndexGroup>61473</IndexGroup>

<!-- Bit offset-->
<IndexOffset>0</IndexOffset>

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

<MappingInfo>
<AdsPort>801</AdsPort>

<!-- Modbus input coils -->
<StartAddress>32768</StartAddress>
<EndAddress>33023</EndAddress>

<VarName>.mb_Input_Coils</VarName>

</MappingInfo>
</InputCoils>

Обычно приводят простой пример в котором описывают мапинг переменных ПЛК-программы, но мы заглянем глубже — как сделать мапинг непосредственно ADS-шины. Для начала, необходимо включить ADS-сервер шины и задать номер порта (обычно 27907 для TwinCAT 2, но можно и другой):

TwinCAT 2: I/O - Configuration → I/O Devices → Device 1 (EtherCAT) → Device 1-Image → ADS → Enable ADS Server.
TwinCAT 3: I/O → Devices → Device 1 (EtherCAT) → Image → ADS → Enable ADS Server.

Номер функции Modbus как бы выбирает индекс группы (Index Group), тогда как адрес Modbus задает смещение области памяти, на которую отображаются переменные, а точнее часть операционного образа. Получается, что с помощью настроечного файла XML можно отразить не только образ данных ПЛК-задачи, но и любой другой образ. Например, образ области памяти данных EtherCAT-шины, что нам и требуется.

<MappingInfo>
<AdsPort>27907</AdsPort>

<!-- Modbus input coils -->
<StartAddress>32768</StartAddress>
<EndAddress>33023</EndAddress>

<VarName>Inputs.Frm0InputToggle</VarName>

Физические интерфейсы и модули расширения

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

EtherCAT, Ethernet, Lightbus, PROFIBUS, PROFINET, EtherNet/IP, CANopen, DeviceNet, Interbus, SERCOS, ControlNet, CC-Link, USB, Modbus RTU, Modbus TCP, RS232/RS485, AS-Interface, IO-Link, DALI, EIB/KNX, LON, DMX, MP-Bus, SMI, M-Bus, PTP/IEEE 1588, BACnet/IP.

По слухам:

• 1-wire (эмуляция через RS232).
• Все, что совместимо с RS232/485 и Ethernet.

Модули расширения EtherCAT

• ES/KS модули (EtherCAT terminals) имеют съемную панель для коммутации проводов. Считается, что это удобнее для монтажа. В остальном ничем не отличаются от EL/KL.
• XFC — модули с высоким быстродействием (от 1 мкс), поддержкой отпечатка времени (timestamp), поддержка интегрирования дополнительных шагов дискретизации для повышения точности (oversampling).
• TwinSAFE — модули желтого цвета для обеспечения безопасности.

Дискретные входа — EL1xxx

• 5/12/24/48В DC.
• XFC, 24В — EL12xx.
• TwinSAFE, 24В — EL19xx.
• 120В AC/DC, 230В AC — EL17xx.
• Счетчики (до 100кГц, 32 бита) — EL15xx.

Дискретные выхода — EL2xxx, EM2xxx

• 5/12/24В DC.
• 30В AC/DC, тристабильные (до 230В AC) — EL27xx.
• XFC, 24В DC — EL22xx.
• TwinSAFE, 24В DC — EL29xx.
• Релейные (до 230В AC) — EL26xx.
• ШИМ (24В, 1А), частотные (до 4МГц), контроля тока — EL25xx.

Аналоговые входа — EL3xxx, EM3xxx

• ±75мВ (24 бита), ±200мВ — EL36xx.
• 0..10В
• 0..30В, 12 бит
• ±10В
• 0..20мА
• 4..20мА
• ±10мА
• Термопары, мВ
• Терморезисторы (RTD)
• Потенциометры
• Мосты
• Измерения параметров трехфазной сети
• Цифровой мультиметр: ток, напряжение (18 бит)
• Сенсора ускорения (IEPE)
• Измерения сопротивления
• Измерения мощности
• Измерение давления — EM37xx.

Аналоговые выхода — EL4xxx

• 0..10В
• ±10В
• 0..20мА
• 4..20мА
• ±10мА

Позиционирования — EL5xxx

• SSI
• SinCos 1Vpp
• EnDat 2.2
• инкрементального энкодера: дифф. RS485; 24В, 32 бита

И еще немного других интерфейсов. Линейка постоянно пополняется и все целиком перечислить сложно:

• Передача данных — EL6xxx.
• TwinSAFE логика — ELx9xx.
• Управление движением (модули на дин-рейку) — EL7xxx
• Высокоточные измерения — ELMxxxx.
• Для взрыво- пожаро- опасных зон (помещения Zone 2) — ELXxxx.

Обновлено: 13 мая 2017 г.

Роутеры AMS и роутеры ADS

ADS (Automation Device Specification) – протокол взаимодействия устройств между собой, не зависит от оборудования и не зависит от шины по которой устройства общаются.

AMS (Automation Message Specification) – содержимое и структура сообщений ADS.

Каждое устройство или программный сервис ADS имеет свой уникальный номер или номер порта (AdsPortNr). Часть номеров заранее занята стандартными и системными сервисами.

Общение между ADS-устройствами может происходить поверх любой сети, а в разных сетях – разная адресация и, вообще, все разное. Кто-то должен перебрасывать мостик между «тем и другим»; в TwinCAT этим занимается AMS Message Router (AMS-роутер, ADS-роутер или просто роутер). Для примера, возьмем ситуацию, когда контроллер извне общается через Ethernet, а внутри через EtherCAT.

Каждый контроллер шины имеет собственный ADS-роутер. В данном случае, он будет транслировать IP-адреса и пакеты Ethernet в AmsNetId-адреса и пакеты EtherCAT. Например, на EtherCAT-шине AmsNetId-адрес устройства = 5.2.100.109.1.1, это же устройство на шине Ethernet может иметь адрес = 192.168.1.100.

Часто, для удобства, начальные части адресов делают одинаковыми: 192.168.1.100.1.1 и 192.168.1.100, но совпадать они не обязаны и часто совпадают из-за того, что конфигуратор автоматически сформировал AmsNetId-адрес из IP-адреса: взял IP-адрес и приписал к нему «.1.1».

ADS и AMS - это разные вещи: один – это архитектура устройств, другой – структура сообщений. Соответственно, ADS-роутер занимается передачей пакетов и трансляцией адресов между устройствами и сервисами. Термин AMS-роутер чаще употребляется в значении трансляции адресов.

• AMS-адреса никак не связаны с IPv6.
• AmsNetId – это на самом деле адрес AMS-роутера, а не устройства.
• Устройства (как и сервисы) адресуются по номеру порта: 801, 501, и т. п.

Настройка роутера

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

Диалог задает Static Route. Записи такого типа существуют вечно. Точнее, до тех пор, пока пользователь ее не удалит. Вечность записи обеспечивает системный реестр операционной системы:

HKEY_LOCAL_MACHINE\SOFTWARE\Beckhoff\TwinCAT\Remote\

Ключи можно удалять и добавлять через редактор реестра: роутер продолжит работать с новой конфигурацией, перезапускать его не требуется. Кстати, Slow Connection задает очень долгое ожидание подключения устройства и никак не влияет на скорость обмена с устройством. Если галку снять, таймаут будет равен двум секундам.

Если заглянуть под капот устройств c Windows CE 5/6/7, то мы увидим похожую картину. Разве что ветка реестра… хм, она будет той же самой.

В TwinCAT System Manager можно обнаружить еще несколько разновидностей роутинга: Temporary, Current и Project:

• Current – фикция и обман, всего лишь вкладка, отображающая на выбранном устройстве все активные на данный момент записи роутера.
• Project – запись роутера которая пропишется при активации конфигурации. Ее очень удобно хранить вместе с конфигурацией проекта (например, когда нужно «залить» 1500 контроллеров для «кинематического дождя»).
• Temporary – я долго искал, где она хранится, пока не обнаружил ее в памяти Windows-службы TwinCAT System Service. Соответственно, эти записи роутера живут до первого перезапуска сервиса или же перезапуска операционной системы (или контроллера).
• …и конечно же Static – его также можно создать здесь.

Если из системного лотка создаются записи для локальной системы, то с помощью System Manager можно создавать записи роутера для удаленной системы и записи между удаленными системами.

Стоит учесть, что не все устройства содержат полноценные роутеры – некоторые формируют AmsNetId на основе IP-адреса (например, так делали графические панели Вейнтек) или каким-либо другим способом. Тем не менее, перед работой с протоколом ADS нужно каким-либо способом создать записи в роутерах: как с «этой стороны», так и с «той стороны».