Изоляция ядер в TwinCAT 3.1

В TwinCAT 3 появилась возможность закрепить задачу (Task) за определенным ядром многоядерной системы. В TwinCAT 3.1 появилась новая возможность — изоляция ядра от операционной системы. Это очень полезная функция, особенно для балансировки вычислительной нагрузки.

Обычная ситуация — CX5120 и TwinCAT 2: операционная система Windows и система реального времени TwinCAT выполняются на одном ядре. Приоритет за Твинкатом, а операционной системе отдаются оставшиеся 20% времени процессора. Если Твинкату понадобится меньше, то он поделится с операционной системой.

Теперь возьмем CX5130 с двухъядерным атомом. Ситуация аналогичная — 80% Твинкат, 20% операционная система. Нагрузка распределяется между ядрами средствами операционной системы. Но(!) ситуация резко меняется, если работает TwinCAT 3.1, в котором можно изолировать одно или несколько ядер от операционной системы (но не все). Ну, и конечно же можно закрепить задачу за конкретным ядром: здесь все по прежнему.

Практика

В принципе, на картинке выше можно остановить свой рассказ, но все-таки проверим. Берем трех ядерную систему, изолируем от операционной системы два ядра, оставляя Windows только одно ядро. Как и ожидалось, диспетчер задач Windows показывает, что операционной системе известно только одно процессорное ядро:

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

Операционная система — сама по себе, Твинкат — сам по себе. Тут же обратим внимание на графу CPU Limit — она показывает, что системе реального времени выделено 100% ресурсов ядра. TwinCAT теперь полноценный хозяин всего ядра и будет работать независимо от вычислительной загруженности операционной системы.

Как изолировать ядра?

Можно вспомнить, что процессы в операционной системе закрепляются за ядрами через CPU affinity mask, но здесь этого знать не требуется, достаточно:

• нажать кнопку "Read from Target", чтобы определить количество ядер целевой системы; 
• задать сколько ядер оставить операционной системе, а сколько для остального;
• по окончании нажать "Set on target" и перезагрузить целевую систему.

После распределения ядер (и если Твинкату доступны несколько ядер), можно распределить задачи: высоконагруженные задачи, такие как управление движением NC SAF, на одно ядро, более медленные задачи — на другое:

Презентация на английском языке:

Что не так с PERSISTENT?

RETAIN — не используйте. PERSISTENT сохраняйте при каждой загрузке контроллера. NOV/DP-RAM работает автоматически.

В случае с PERSISTENT переменные будут автоматически восстановлены при следующей загрузке. Но(!) только при следующей. Если не сохранить переменные в текущей сессии — при следующей загрузке они не восстановятся! Так сделано для улучшения контроля за целостностью данных на флеш-памяти и, как следствие, для повышения надежности.

Стандартный сценарий работы с PERSISTENT-переменными:

- Прибывает новый станок.

- Первая загрузка ПЛК (параметры по умолчанию).

- Оператор изменил параметры, нажал кнопку «Сохранить».

- Прошел вызов WritePersistentData().
- PERSISTENT-переменные сохранились на флеш.

…

- Длинный рабочий день.

…

- Конец смены.

- Станок отключен в конце рабочего дня.

...

- Ночь.

…

- Утро. Оператор поправляет спецовку и включает станок.

- ПЛК загрузился.

- PERSISTENT-переменные автоматически восстановили свое значение.

- ПЛК-программа самостоятельно вызывает WritePersistentData().

- PERSISTENT-переменные сохраняются для автоматического восстановления при следующей загрузке.

…

- Длинный рабочий день.

…

- Конец смены.

- Станок отключен в конце рабочего дня.

...

- Ночь.

…

- Утро. Оператор поправляет кепку и включает станок.

- ПЛК загрузился.

- PERSISTENT-переменные автоматически восстановили свое значение.

- ПЛК-программа самостоятельно вызывает WritePersistentData().

- PERSISTENT-переменные сохраняются для автоматического восстановления при следующей загрузке.

…

Используйте Нов-дипи-рам, там все работает автоматически.

Вебинар. Расширение кулачковых механизмов

Линейная версия цифрового управления движением NC PTP может быть расширена с помощью дополнений, одним из которых является механизм поддержки так называемых "кулачковых механизмов" (cam plates). Принцип работы тот же, но в случае использования цифрового управления, отсутствует механическая передача между подчиненной и мастер осями. Ее функцию выполняет нелинейный электронный редуктор.

Расширение оперирует нелинейным сцеплением по двум осям и описывает взаимное позиционирование: позиция по оси X — мастер ось (линейное перемещение) и позиция по оси Y — подчиненная ось (нелинейное изменение позиции или генерируется "на лету").

Для работы с данным расширением необходим контроллер с уровнем производительности не ниже 40. CX5120-012x вполне подойдет в качестве стартового ПЛК. Кроме того, необходим набор программного инструментария. Ниже подборка для TwinCAT 3 (для TwinCAT 2 принцип тот же, но заказные номера отличаются):

• TC1250 — TC3 PLC/NC PTP 10, минимально необходимый уровень NC PTP.
• TE1510 — TC3 Cam Design Tool, опционально, можно обойтись без нее, но сильно упрощает разработку.
• TF5050 — TC3 NC Camming, библиотека функциональных блоков для ПЛК-программы. Без нее надстройка практически теряет смысл.

Режимы работы

1. Периодический, главная ось периодически сбрасывает значение своей позиции в исходное значение: 0..360, 0..360, ... Подчиненная ось циклически отрабатывает свою траекторию. 
2. Апериодический (линейный), оси сцепляются по мере необходимости. Для данного режима перед сцеплением и запуском функций расширения необходимо предусмотреть выход осей в заданные таблицей начальные положения.

Виды позиционирования

1. Обычные таблицы (контурный режим) — множество точек, образующие траекторию. Не могут изменяться во время работы.
2. Специальные функции движения (интерполяции) — ряд точек траектория между которыми задается интерполяционной функцией. Для каждой точки можно задать свою собственную функцию. Таблицу можно изменять или генерировать "на лету".

Таблицы в ПЛК-программе задаются как массив координат + дополнительный массив структур описывающий интерполяционные функции.

Создание и управление таблицами движения

1. TwinCAT Cam Design Tool — задание и управление опорными точками траектории движения и способом интерполяции. Применяется на этапе конфигурирования ПЛК, непосредственно в System Manager или XAE.
2. ПЛК-программа (требуется TwinCAT NC Camming Supplement, библиотека разработчика):
   • Создание таблиц.
   • Сцепление/расцепление осей.
   • Масштабирование таблиц.
   • Редактирование таблиц во время работы.
   • Переключение таблиц.
   • Мониторинг параметров и характеристик.
3. Другие внешние программы — например, Microsoft Excel. Таблицы в дальнейшем переносятся либо в массив ПЛК-программы, либо в Cam Design Tool.

Полный вебинар на английском языке: Cam plate application in the TwinCAT editor and runtime system.

Диагностические возможности TwinCAT

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

Условно, все диагностические средства можно разделить на две части:

• Диагностика операционных данных (process data) с помощью "операционных счетчиков" (working counter, WKC).
• Диагностика шины: пакеты данных, контрольные суммы (CRC) и пр.

Что, где и когда контролировать?

1. В каждом цикле, синхронно с циклом, контролировать операционные счетчики, т. к. они контролируют операции чтения/записи операционных данных. Сами счетчики только отображают ситуацию. Реагировать, делать выводы и совершать какие-либо телодвижения на изменение состояния счетчиков должна ПЛК-задача (программа).
2. Асинхронно (не в каждом цикле), при наступлении определенного события можно контролировать состояние мастера и состояние подчиненных.

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

Как для мастера, так и для подчиненного можно асинхронно следить за машиной состояния EtherCAT (OP, Pre-OP, состояние ошибки и т. п.).

Кроме этого на мастере можно следить за общим состоянием аппаратного устройства (контроллера, ПЛК) в целом (DevState). Это могут быть ошибки обмена данными, сработало дублирование линий (redundancy), сторожевой таймер (watchdog timer), одно из подчиненных устройств находится в одном из нерабочих состояний, DC не синхронизированы, и др.

Для подчиненного устройства можно также следить за состоянием связи с мастер-устройством.

Диагностика операционных данных

Общая диагностика операционных данных (process data) производится через переменную WcState (тип данных BOOL).

Переменная согласно своему типу данных может принимать два значения: 0 — данные согласно счетчику корректны (data valid) и 1 — данные некорректны (data invalid).

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

Для разбивки подчиненных по командам и/или фреймам существует механизм под названием Sync Unit.

SyncUnit = один фрейм (datagram) = один операционный счетчик (WKC) = одна пачка циклической диагностической информации.

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

Несколько синк-юнитов позволяют мастеру шины отправлять несколько пакетов так, что у каждого пакета будет свой операционный счетчик. Поэтому для мастера доступны несколько переменных вида: FrmXState, FrmXWcState, где X — номер фрейма.

Диагностика шины или сети

Фреймы, бегущие от мастера к подчиненным и обратно, могут по пути "испортиться". Обрыв кабеля, ненадежный контакт, назафиксированный разъем, все это может привести к искажению данных внутри дейтаграммы-фрейма. Поэтому к каждой телеграмме мастер прикрепляет 16-разрядную контрольную сумму, подсчитанную, исходя из содержимого фрейма.

В System Manager, на вкладке Online мастера шины EtherCAT, можно посмотреть статистику пакетов и контрольных сумм (CRC).

Каждое из устройств на шине EtherCAT может иметь до 4-х портов ввода/вывода: A, B, C, D. Каждый из портов в конкретной конфигурации может быть либо входящим, либо исходящим относительно устройства. Контрольная сумма подсчитывается мастером перед отправкой пакета, а затем автоматически проверяется в каждом из портов, каждого подчиненного устройства. Подключившись к мастеру, можно контролировать состояние всей шины целиком и точно определять место, где "испортились" пакеты EtherCAT.

Как получить диагностику?

1. TwinCAT System Manager позволяет разработчику оперативно следить за состоянием шины, мастера шины и подчиненных устройств.
2. Линковка переменных "---State" позволяет ПЛК-задаче диагностировать и реагировать на изменение состояния системы, в том числе сброс или устранение ошибки.
3. Библиотека TcEthercat.lib предоставляет доступ ко всем диагностическим переменным через протокол ADS, предоставляя ПЛК-задаче возможности аналогичные предыдущему п. 2. Кроме этого библиотека позволяет диагностировать состояние других мастеров и других шин EtherCAT. В этом случае каждый мастер контролирует состояние своей шины EtherCAT, мастера объединены в сеть по шине Ethernet, один из мастеров выполняет функцию супермастера, контролируя и координируя работу остальных мастеров.

В TwinCAT 3 появился инструмент под названием Emergency Scan. Он позволяет в режиме конфигурации отправлять до 10000 сетевых пакетов за раз, тем самым облегчая поиск проблем связи на шине.

Полный вебинар на английском языке Possibilities for EtherCAT diagnostics in TwinCAT

TwinCAT 3 и системы контроля версий

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

Конечно, как костыль, можно использовать экспорт в текстовый файл ".exp", но костыль, он только в Африке еще и средство для поимки пропитания, в средних же широтах — это как минимум неудобно.

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

TwinCAT 3 следом за CoDeSys (который и был виновником костылей) наконец-то перешел на текстовые форматы файлов:

• Используются читабельные форматы файлов (основанные на XML).
• XAE (иногда с помощью надстроек) позволяет использовать различные системы контроля версий непосредственно из среды разработки (TFS, SVN, Git).
• Удобно сравнивать внесенные/произошедшие изменения в проекте.
• Можно сохранять временные линки на отсутствующие переменные.

Полный вебинар на английском языке TwinCAT 3 | Source code management