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:
No comments
Post a Comment
Note: Only a member of this blog may post a comment.