December 30, 2015

Универсальная летающая пила

Кроме базовых возможностей управления движением (без интерполяций), TwinCAT NC PTP позволяет осуществлять более сложные виды управления движением. Одним из таких видов движения является «универсальная летающая пила» (Flying Saw).

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

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

Минимальные требования:
  • ПЛК Бекхофф уровня TC40 и выше. Например: CX9020, P205NC, CX5020, CX2020.
  • TwinCAT 2 (NC PTP или NC I) или TwinCAT 3 (TC3 PLC/NC PTP 10, NC I).
  • Библиотека «NC Flying Saw». Заказные номера TS5055 (TwinCAT 2) или TF5055 (TwinCAT 3).

В какой-то момент библиотека была переписана и названа "Универсальной летающей пилой" (Universal Flying Saw), т. к. теперь обеспечивала поддержку разных видов пил (обычная летающая пила, диагональная летающая пила и др.).


Обычная летающая пила


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

Передаточное отношение между пилой и конвейером рассчитывается как обычная пропорция Vs / Vm. Если они равны, то получим передаточное отношение Vs / Vm = 1.



Диагональная летающая пила


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

В данном случае передаточное отношение рассчитывается чуть сложнее, т. к. диагональная скорость пилы складывается из скоростей движения по горизонтали и вертикали: Vs / [ cos(α) * Vm ].



Библиотека TcMC2_FlyingSaw.lib


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


В отличие от обычного электронного редуктора, доступного в NC PTP, сцепление и последующая синхронизация могут выполняться «на ходу»: когда скорости осей не равны нулю. Такая функция не доступна в электронном редукторе NC PTP.

Весь функционал библиотеки сосредоточен в двух функциональных блоках: MC_GearInVelo и MC_GearInPos. Первый просто синхронизирует оси по скорости. Второй синхронизирует оси ориентируясь на заданную позицию, т. е. только по достижении заданной позиции, оси будут синхронизированы. После этого, функциональный блок можно сбросить. Дальнейшее поддержание синхронности производится автоматически подсистемами NC и сервоусилителем.

Основной орган управления пилой – это позиция. Управляя позицией синхронизации, можно регулировать длину отреза материала (CUTTINGLENGTH).


December 29, 2015

Структурные типы данных AX5000

Ряд параметров сервоусилителей серии AX5000 являются сложными типами данных. По сути, это структуры или списки (list), что в принципе одно и то же, но не стоит забывать о порядке полей.

Для работы с такими параметрами нужно сделать чуть больше телодвижений, чем при работе с простыми типами данных: перед записью структурных параметров, нужно "завернуть" их в структуру-контейнер.
Этот контейнер – обычный массив байт, оформленный определенным образом, со строгим соблюдением порядка полей в структуре. 
В самом начале контейнера содержится два поля: размер структуры (WORD, 2 байта) и максимальный размер структуры (WORD, 2 байта). Затем, в заданном порядке, идут данные конкретного параметра. Размеры задаются в байтах без учета длины самих полей размера.
В документации указана общая длина параметра в битах с учетом длины полей размера, тогда как сами поля размера должны содержать длину в байтах без учета длины самих полей размера. Еще проще – общая длина в байтах минус 4 байта.
Посмотрим на примерах. Возьмем параметр P-0-0251 – это параметр конфигурации сканера позиции.
  1. Берем из конца таблицы значение общей длины: "Data length: 96". Это общее значение длины в битах.
  2. Делим на 8, чтобы получить значение общей длины в байтах = 96 бит / 8 = 12 байт.
  3. Вычитаем длину поля длины (WORD, 2 байта) и длину поля максимальной длины (WORD, 2 байта) = 12 - 2 - 2 = 8 байт. Получили значение поля максимальной длины. Если мы записываем все поля структуры, то это же значение подойдет и для поля длины.

Еще один пример – параметр вывода текста на дисплей сервоусилителя P-0-0313.
Data length: 416 бит / 8 - 4 байта = 48 байт.

Для задания таких параметров удобно создавать собственные структуры вида:

TYPE ST_SoE_ParameterList :
    STRUCT
        Length    : WORD := 48;
        MaxLength : WORD := 48;

        First  : UDINT;
        Second : INT;
        Third  : WORD;
        (* ... *)
    END_STRUCT
END_TYPE


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

ParamList : ST_SoE_ParameterList;

ParamList.First  :=  1;
ParamList.Second := -2;
ParamList.Third  :=  3;

SoeWrite(...
    pSrcBuf  := ADR(SoeList),
    cbBufLen := SIZEOF(SoeList),
    ...);


Если переменная такого структурного типа используется многократно, можно очищать ее через функции работы с областями памяти:

MEMSET(ADR(ParamList) + 4, 0, SIZEOF(ParamList) - 4);

December 23, 2015

Debian Linux на контроллерах CX9020

Появился официальный набор скриптов и патчей для сборки и установки Debian Linux на компактные контроллеры CX9020.

Набор выложен в открытом доступе на гитхабе и позволяет собрать образ Linux для флэш-диска, с которого впоследствии будет загружаться операционная система контроллера.

Не все контроллеры CX9020 будут работать с подготовленным образом. При заказе контроллера необходимо указать специальный артикул CX9020-0100. Такой контроллер будет загружаться с подготовленной флэшки, а не со встроенного в ПЛК загрузчика.

Scripts to build a Debian based Linux system for the CX9020 Embedded PC


Обновление: для сборки понадобится Linux-среда; без объяснений рекомендуют Ubuntu LTS. Теребить службу тех.поддержки не имеет смысла: в случае возникновения вопросов - создавайте тикеты в репозитории гитхаба.

December 10, 2015

Виртуальные каталоги FTP-сервера

Иногда возникает необходимость получить удаленный доступ к файловой системе контроллера на базе Windows CE, для этого в нее предустановлен FTP-сервер. Такая необходимость вызвана системными ограничениями самой операционной системы.

Управлять и настраивать FTP-сервер легко и просто, главное не забыть его активировать, т. к. изначально он отключен. Все эти манипуляции производятся из CXConfigurator'а панели управления. Настройки интуитивно понятны, за исключением выпадающего меню, позволяющего управлять пользователями и паролями этих самых пользователей.



Рекомендуется сразу же отключить анонимный вход и создать пару-тройку полезных пользователей с паролями. После активации и перезагрузки можно подключаться с помощью программ клиентов FTP: WinSCP, FAR, и пр., а можно, используя стандартный проводник Windows (см. в конце статьи).

Сложного здесь ничего нет, зато есть фича – виртуальные каталоги. Для создания и последующего доступа к ним, мы заглянем чуть глубже – в реестр: Start → Run... → regedit



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

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



Добавляем в реестр новую запись и получаем в проводнике виндоус путь покороче:

December 8, 2015

Новый HMI для TwinCAT 3

С выходом новой системы человеко-машинного интерфейса (HMI), открытые системы Бекхофф изменяют подход к средствам разработки, программирования и дизайна интерфейсов промышленных систем. В отличии от проприетарных (закрытых) инженерных и коммуникационных систем, новый TwinCAT HMI позволяет использовать такие инструменты как Visual Studio® и HTML5 для разработки, а также защищенные протоколы HTTPS и WebSockets Secure (WSS) для передачи данных. При этом отсутствует зависимость от операционной системы, т. к. клиент взаимодействует с системой через браузер.

В таком ключе Бекхофф действительно разработал открытое и высокопроизводительное решение для современного мира, связанного коммуникациями и движущегося к Индустрии 4.0.
Предполагаемое время выхода TwinCAT 3 HMI – 3-й квартал 2016 года. 

Преимущества

  • Эффективная и простая разработка за счет интеграции в Microsoft Visual Studio.
  • Не зависит от аппаратной платформы.
  • Ориентирован на веб-технологии: анимация, графика, дизайн (HTML5, JavaScript).
  • Мощная и гибкая архитектура.
  • Расширяемость за счет модулей.
  • Использование языков высокого уровня.
  • Привычный набор графических инструментов и ПО.



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

Нововведение в том, что на этот раз TwinCAT предлагает упразднить задачу разработки собственной системы и воспользоваться уже готовой. Новая система представляет собой два новых слоя. Первый – это веб-сервер визуализации с "алармами" и расширениями (HMI Server Extension). Второй слой – веб-клиент работающий на стороне клиента в обычном веб-браузере. Поведением второго слоя также можно управлять с помощью скриптового языка JavaScript.

Все это уже было раньше, но оно не было настолько тесно интегрировано. Теперь же, после слияния System Manager'а и системы программирования PLC Control, в Visual Studio добавляется универсальная система разработки веб-визуализации.



Простота применения


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

HMI такого вида может самостоятельно подстраиваться под ориентацию, пропорции или графическое разрешение экрана. Гибкость организации HMI – как набора модулей и HTML5-страниц, позволяет внедрять одни сложные элементы управления в другие. При этом сохраняется возможность использовать JavaScript для контроля и управления логикой работы клиентской стороны. Не обязательно уметь программировать на JavaScript, достаточно настроить элементы с помощью встроенного графического редактора.

Вывод на стороне клиента осуществляется через браузер, а т. к. браузеры сейчас есть на различных аппаратных платформах – HMI будет одинаково работать как на ARM или Core-i процессорах, так и на специализированных многоядерных платформах. При этом нет необходимости в адаптации или переработке содержимого HMI-страниц.
Логику HMI можно запрограммировать как на стороне клиента с помощью JavaScript, так и на стороне сервера. Такое разделение позволяет также защитить программный код как интеллектуальную собственность.



Организация связи и безопасность


Браузер общается с HMI-сервером напрямую, через защищенные протоколы HTTPS или WebSockets Secure (WSS). HMI-сервер, в свою очередь, общается с контроллером через различные протоколы: OPC UA, ADS (Automation Device Specification). Другие протоколы могут быть реализованы как серверные расширения.

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



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


December 1, 2015

EtherCAT-синхронизация в сервоусилителях AX5000

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

EtherCAT-телеграммы (ECT) рассылаются EtherCAT-мастером (EtherCAT Master) по всем подключенным EtherCAT-подчиненным устройствам (ESC). ESC – это электронный модуль (микросхема), осуществляющий постоянный синхронный процесс обработки и/или копирования данных (содержащихся в телеграммах) через заданные интервалы времени по прерываниям таймера. Конфигурация ESC описывает, какая информация, и как, будет обработана из телеграммы. В приводных технологиях используются очень малые интервалы времени, поэтому очень важно поддерживать непрерывность и постоянность синхронности данных и подчиненных устройств в целом. Синхронность подчиненных устройств обеспечивается так называемыми "распределенными часами" (Distributed Clocks, подробнее см. документацию по EtherCAT).



EtherCAT-мастер


При включении и последующем старте системы, EtherCAT-мастер читает конфигурационный файл AX5000 и записывает "ΔT0 = 250мкс" и "ΔT1 = длительность NC-цикла" в соответствующие регистры подчиненного. ESC постоянно считывает эти значения из регистров и подает сигналы Sync0 и Sync1. Потеря или изменение содержимого этих регистров во время работы, может привести к проблеме выдачи сигналов Sync0 и Sync1.


EtherCAT-подчиненный контроллер (ESC)


ESC-контроллер для синхронизации сервоусилителя AX5000 регулярно, через промежутки времени ΔT0 и ΔT1, отправляет в процессор сервоусилителя два сигнала прерывания – Sync0 и Sync1.

Sync0

Сигнал или прерывание Sync0 генерируется каждые 250мкс. В случае ошибки, соответствующая ось переходит в состояние ожидания (стоп) с рампой "EStop ramp".
  • F414 – если прерывание не проходит, то процессор генерирует код ошибки F414 (см. рисунок ниже, метка F0).
  • F409 – прерывание Sync0 может быть выбрано из трех значений: 62.5мкс, 125мкс, 250мкс. При других значениях интервала генерируются ошибки F409.
  • F410 – возникает, если прерывание Sync0 не активировано (не генерируется) в ESC.
  • F411 – длина импульса прерывания не соответствует стандарту.

Sync1

Прерывание Sync1 рассылается со временем цикла NC-задачи (SAF). Время цикла всегда пропорционально значению частоты прерывания Sync0 и, по умолчанию, равно 1мс.
  • F412 – интервал Sync1 равен времени интервала Sync0, умноженному на целое число, и должно быть идентично значению параметров S-0-0001 и S-0-0002, иначе произойдет ошибка.
  • F414 – если прерывание не проходит, то процессор генерирует код ошибки F414 (см. рисунок ниже, метка F1).
  • F413 – ошибка возникает, если прерывание Sync1 не активировано или не генерируется в ESC.
  • F411 – длина импульса прерывания не соответствует стандарту.




Телеграмма принята (ТЧК)


ESC прочитает телеграмму (ECT), как только она поступит. Допустимый момент поступления находится непосредственно перед Sync1. Момент ТЧК (EOT) немного запаздывает после прерывания Sync1 на время ΔT2. Данные, предназначенные для ESC, затем читаются из телеграммы и записываются в область данных SyncMan-2, после чего, состояние SyncMan-2 устанавливается в значение "SyncMan записан". Контроллер копирует данные из SyncMan-2 в его собственную область памяти только при условии, что в момент Sync1 установлено состояние "SyncMan записан". И, наоборот – данные не копируются, если статус "SyncMan записан" не установлен (см. рисунок выше, метка F2).

Если данные не будут дважды благополучно скопированы – контроллер выдаст ошибку F415, и соответствующая ось перейдет в состояние ожидания (стоп) с рампой "EStop ramp".
Допустимое отклонение наличия телеграммы в требуемый момент времени  равно нулю, т. е. не допустимо! EtherCAT-мастер должен обеспечить своевременное поступление данных в SyncMan-2.

Как пример, можно рассмотреть наличие "дрожания" (jitter), из-за которого отклонение времени прибытия не равно нулю и телеграмма прибыла с опозданием; что может вызвать срыв синхронизации.

Ошибка F415


Распределенные часы: нарушена синхронизация данных.
  1. Таймер контроллера регулярно генерирует прерывания (по умолчанию, базовое время (base time) = 1мсек).
  2. Отдельные задачи обрабатывается диспетчером задач в соответствии с внутренними правилами системы (их нельзя изменить, но можно повлиять на них, см. приоритеты задач).
  3. Если задача может отработать как больше, так и меньше времени, т. е. время ее выполнения сильно зависит от вычислительной нагрузки, то следует поместить процесс обновления данных "I/O Update" перед началом задачи (включить параметр задачи "I/O at task begin"). Это исключит одну из причин некорректной синхронизации.
  4. С помощью процесса "I/O Update" результирующие данные передаются в подсистему TwinCAT-IO и впоследствии будут отправлены в виде телеграммы для подсоединенных устройств. EtherCAT-телеграмма пробежит через все устройства и сбросит и/или подберет данные соответствующих устройств.
  5. Порядок обработки задач зависит от приоритета задачи. Задача с большим приоритетом обрабатывается в первую очередь и раньше других отправляет данные в TwinCAT-IO подсистему (которая занимается обработкой телеграмм). Проблемы обычно появляются, когда отдельные задачи имеют различную длину времени цикла выполнения и в какой то момент могут начать конкурировать за место в телеграмме.
  6. Асинхронные задачи могут вмешаться в произвольный момент времени и разрушить синхронизацию.

November 17, 2015

Изоляция ядер в 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, на одно ядро, более медленные задачи — на другое:



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

November 11, 2015

Что не так с PERSISTENT?

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

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

Стандартный сценарий работы с PERSISTENT-переменными:
- Прибывает новый станок.
- Первая загрузка ПЛК (параметры по умолчанию).
- Оператор изменил параметры, нажал кнопку «Сохранить».
- Прошел вызов WritePersistentData().
- PERSISTENT-переменные сохранились на флеш.
- Длинный рабочий день.
- Конец смены.
- Станок отключен в конце рабочего дня.
...
- Ночь.
- Утро. Оператор поправляет спецовку и включает станок.
- ПЛК загрузился.
- PERSISTENT-переменные автоматически восстановили свое значение.
- ПЛК-программа самостоятельно вызывает WritePersistentData().
- PERSISTENT-переменные сохраняются для автоматического восстановления при следующей загрузке.
- Длинный рабочий день.
- Конец смены.
- Станок отключен в конце рабочего дня.
...
- Ночь.
- Утро. Оператор поправляет кепку и включает станок.
- ПЛК загрузился.
- PERSISTENT-переменные автоматически восстановили свое значение.
- ПЛК-программа самостоятельно вызывает WritePersistentData().
PERSISTENT-переменные сохраняются для автоматического восстановления при следующей загрузке.



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

November 10, 2015

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

Линейная версия цифрового управления движением 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.

November 5, 2015

Диагностические возможности 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

November 2, 2015

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

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

Конечно, как костыль, можно использовать экспорт в текстовый файл ".exp", но костыль, он только в Африке еще и средство для поимки пропитания, в средних же широтах — это как минимум неудобно.
Стоит заметить, что существует .tpy -файл который по сути XML с описанием "переменных" программы, но не самой программы, но и предназначен он для связи между различными программными системами.
TwinCAT 3 следом за CoDeSys (который и был виновником костылей) наконец-то перешел на текстовые форматы файлов:
  • Используются читабельные форматы файлов (основанные на XML).
  • XAE (иногда с помощью надстроек) позволяет использовать различные системы контроля версий непосредственно из среды разработки (TFS, SVN, Git).
  • Удобно сравнивать внесенные/произошедшие изменения в проекте.
  • Можно сохранять временные линки на отсутствующие переменные.



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

September 21, 2015

Питание компактных контроллеров и модулей расширения

Большинство компактных устройств, модули расширения или компактные контроллеры CX, получают электропитание из двух источников. Хотя это и доставляет небольшую проблему при монтаже, но существует вполне объективная причина зачем так сделано.

Модули расширения EtherCAT (EL, ES, EK) получают питание от шины EtherCAT (5 вольт от двух контактов шины, оставшиеся четыре — передача данных) и 24 вольта через два контакта ближе к лицевой стороне (отмечены кругами на рисунке ниже).

 

Шина обеспечивает питание "мозгов" модуля, его внутренней логики, μC-контроллера. Дополнительные контакты питают внешний интерфейс (на картинке выше, это дискретные выхода модуля EL1809). Такое разделение необходимо для того, чтобы отделить "силовое" питания от "логического", что является обычной практикой и позволяет одновременно получать диагностику и сохранять работоспособность модуля независимо от состояния внешнего интерфейса (короткие замыкания, обрывы и пр. неполадки).

В случае с компактными контроллерами CX, контакты 24V и 0V (см. выше зеленая стрелка) обеспечивают питание непосредственно контроллера и его периферии (в том числе и EtherCAT-шины), а контакты ++ и --  (см. выше желтая стрелка) обеспечивают дополнительное питание внешнего интерфейса модулей расширения (24В на дополнительных контактах, отмеченных кругами). Такое разделение позволяет сохранять питание контроллер в случае если у него отвалилась периферия или обеспечить более мощное питание для шины за счет подключения отдельного мощного блока питания, или переводить систему в режим пониженного энергопотребления, отключением энергоемких модулей расширения. Можно придумать что-нибудь еще, но чаще ставят перемычки и "питают" контроллер от единого БП.

Что произойдет если на контроллере не запитывать контакты ++ и --, будут ли работать модули расширения? Будут, но неполноценно: модули будут присутствовать на шине, продолжат передавать информацию по шине, но не будут реагировать или выдавать что-либо на свой внешний интерфейс. Иначе говоря, модули будут выдавать диагностику, но не будут работать с внешним интерфейсом, они замкнуться в своем компактном логическом мире. Еще проще на примере дискретных входов/выходов: контроллер будет считать модуль расширения работоспособным, модуль будет находится в рабочем режиме (OP), но дискретные входа/выхода будут всегда неактивны при любых внутренних и внешних условиях.


Нагрузочная способность шины


Стандартно блоки питания CX-контроллеров выделяют на шину 2А тока. При подготовке новой конфигурации существует хороший способ проверить хватит ли этого для новой конфигурации.



Упрощенно, в таблице выше поле "E-Bus (mA)" показывает сколько "тока" остается на шине после этого модуля. Число может уйти в минус, если достигнут предел нагрузочной способности шины. В таком случае необходимо подпитать шину, освежить ее. Для этого служат модули EL94x0 (EL9410 — с диагностикой).



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

September 3, 2015

Фильтры записи FBWF и EWF

В компактных контроллерах серии CX, в качестве жесткого диска используется флэш-память, у которой есть ограничение на количество перезаписей: 100 000 раз записал и всё. Дальше возможны неприятности и потери.

А еще есть такая операционная система Windows Embedded XP и даже Windows Embedded Standart 7. Они круче чем компактные версии CE, т. к. по сути это те же самые "настольные" операционки. Компьютеры, на которых они установлены, выключаются через меню "Пуск", иначе возможны коллизии интересов: пользователь хочет дернуть рубильник и пойти домой, а операционная система хочет культурного общения и дополнительного времени на выключение (что-то она там себе сохраняет и возможно, даже, что-то важное).

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

На старших контроллерах CX, с установленными операционными системами типа Standart, существует фильтр записи на диск, а иногда даже два:
  • FBWF (File-Based Write Filter) -- действует на уровне файлов.
  • EWF (Enhanced Write Filter) -- действует на уровне секторов, т. е. на уровне более низком, чем файловый.
Эти два фильтра установлены на каждом контроллере с операционной системой Windows Embedded Standart 7. И как я подозреваю, будут встраиваться в следующие операционные системы.
При включенном фильтре (одном из) операционная система думает, что запись идет на диск. Тем временем запись идет в оперативную память, файлы на диске остаются нетронутыми, а операционной системе каждый раз подсовываются файлы из оперативной памяти. После перезагрузки все файлы как бы возвращаются к своему изначальному состоянию, ведь на самом деле они и не изменялись, а изменялись их копии в оперативной памяти.
Об этом стоит помнить. Если вам нужно обновить информацию на контроллере, а фильтр включен (нужно проверить), то сначала выключите фильтр, перезагрузьте контроллер и только затем обновляйте. По окончании, не забудьте включить фильтр обратно. Ресурс флэш-диска не бесконечный.

Какой из фильтров использовать и почему их два?


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

Основная причина использовать FBWF, это возможность установить (или снять) ограничение на конкретные файлы, а лучше на специально выделенные каталоги. Например, каталог TwinCAT\Boot автоматически вносится в исключительный список и всегда доступен для записи:

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


Если все-таки любопытно, то фильтром EWF поддерживаются следующие функции NTFS и не поддерживаются фильтром FBWF:
  • блокировка и разблокирование файлов;
  • идентификаторы файлов в NTFS;
  • точки повторной обработки;
  • квоты;
  • жесткие связи;
  • нежесткая блокировка;
  • шифрование файлов;
  • поддержка множественных оверлеев;
  • поддержка дисковых оверлеев;
  • фиксация и выключение в режиме реального времени.
На разных томах можно одновременно использовать два разных фильтра. На одном томе можно использовать только один из фильтров или выключить фильтры совсем.
В случае с жестким диском, фильтр помогает сохранять целостность информации при внезапных отключениях ПЛК. Дернули рубильник, затем повторно включили и получили то же самое, что было до отключения: все изменения пропали, никаких ошибок записи или не оконченных операций с жестким диском не осталось.

July 21, 2015

S и P параметры сервоусилителей

Несмотря на то, что сервоусилители AX5000 работают с шиной EtherCAT, внутри у них неонка SERCOS. Отсюда тянется специфика работы с параметрами и объяснение, почему этих параметров два вида: S и P.

S -- стандартные.
P -- от слова "product" -- уникальные для продукта. Могут различаться для разных версий, продуктов и т. п.

Тем не менее, работа с этими параметрами ведется через EtherCAT и где-то есть преобразование (на самом деле не преобразование, а маппинг операционного образа данных). Поэтому, для прямого доступа через EtherCAT используются следующие значения:

Группа (IGrp), константа:
EC_ADS_IGRP_ECAT_SOE = 0xF420

Смещение (IOffs) формируется сложнее:
(nDriveNo & 7) << 24 | (nElement << 16) | nIdn;
  • nDriveNo -- номер канала сервоусилителя.
  • nElement -- номер функции CoE, иначе говоря, что и с чем будем делать. Например, nElement для записи значения в ячейку: EC_SOE_ELEMENT_VALUE = 0x40.
  • nIdn -- номер ячейки SoE (SERCOS over EtherCAT).


В библиотеке TcEthercat.lib для разработчиков подготовлены специальные константы. Например, nIdn для параметра S_0_0099, формируется как сумма номера параметра и соответствующей константы смещения: S_0_IDN + 99.

S-параметры расположены в начале адресного пространства, P-параметры смещены на постоянную величину:
S_0_IDN = 0
P_0_IDN = 0x8000

Так выглядит вычисление смещения изнутри функционального блока:

nOffset := SHL(BYTE_TO_DWORD(nDriveNo AND 16#07), 24) OR SHL(BYTE_TO_DWORD(nElement), 16) OR nIdn;

fbAdsWrite( WRITE    := TRUE,
            NETID    := sNetId,
            PORT     := nSlaveAddr,
            IDXGRP   := EC_ADS_IGRP_ECAT_SOE,
            IDXOFFS  := nOffset,
            SRCADDR  := pSrcBuf,
            LEN      := cbBufLen,
            TMOUT    := tTimeout );


Кроме ячеек для хранения данных, существуют ячейки для исполнения команд сервоусилителя. Для выполнения таких команд (например, сброс ошибки сервоусилителя через командный параметр S_0_0099), достаточно записать в эту ячейку магическую цифру "3" (три). Для выполнения команды еще раз, необходимо записать число три в эту ячейку еще раз.

July 20, 2015

TcCOM модули в TwinCAT 3

TcCOM TwinCAT 3 модуль:
  • Может работать внутри системы реального времени.
  • Может быть написан на C/C++/ST/...
  • По сути COM-объект с заданным интерфейсом.
  • Всегда идет вместе с описанием "TwinCAT Module Class" -- это .tmc файл c XML форматированием.
  • Каждый экземпляр модуля описывается в "TwinCAT Module Instance" -- это .tmi файл, содержащий как минимум: Object Id, Object Name, Type Name, GUID, инициализации параметров, и т. п.
  • Не зависит от других модулей.
  • Может содержать как одну, так и несколько функций

Модуль обязан поддерживать:


Машина состояний EthreCAT


  • INIT → PREOP (IP) -- модуль загружается в память.
  • PREOP → SAFEOP (PS) -- выделение или захват ресурсов (например, памяти).
  • SAFEOP → OP (SO) -- связь с другими модулями.
  • OP → SAFEOP (OS) -- отключение от других модулей.
  • SAFEOP → PREOP(SP) -- освобождение ресурсов.
  • PREOP → INIT (PI) -- модуль освобождает занятую им же память.


Способы коммуникации


  • Маппинг переменных области данных:
    - гарантирует целостность данных;
    - разрабатываются на любых языках программирования;
    - данные доступны только внутри цикла задачи.
  • Маппинг указателей на переменные области данных:
    - только для C/C++;
    - целостность данных не гарантируется;
    - возможен прямой доступ к данным извне цикла задачи.
  • Вызов интерфейсов других COM-объектов:
    - множество нюансов и трудностей на пути реализации.
  • Коммуникация через ADS-клиент/сервер:
    - самый универсальный, но не самый быстрый.

Полный вебинар на английском языке "TwinCAT 3 modules: idea and realization".

July 17, 2015

Лицензирование TwinCAT 3

Лицензирование стоит на трех китах:

  • System ID — уникальный идентификатор (номер), закрепленный за конкретным аппаратным обеспечением — ПЛК или аппаратный ключ. Он неизменяемый и "зашит" в материнскую плату или сформирован на основе аппаратной конфигурации.
  • Volume ID — уникальный идентификатор (номер), закрепленный за разработчиком. Код не привязан к аппаратному обеспечению. Это не совсем точно, но лучше считать, что он все-таки закреплен за разработчиком.
  • Platform / Performance Level — описывает стандартные конфигурации со стандартной производительностью (чаще всего, это минимальный уровень производительности). Стоимость лицензий TwinCAT 3 отталкивается от этого значения. Классы производительности ПЛК:

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

Также существует сводная таблица производительности для компонентов и библиотек.


Виды лицензий


  • Демо лицензия (Trial Licenses)
    • Выдается на семь дней, путем ввода "капчи" в XAE.
    • Может быть активирована много раз, по мере необходимости.
  • Стандартная лицензия (Standard Licenses)
    • Привязана к определенному аппаратному обечпечению ("System ID" ПЛК, аппаратный ключ).
  • Пакетная лицензия (Volume Licenses)
    • Множество идентичных конфигураций, требующие стандартных TwinCAT-лицензий.
    • Привязываются к "Volume ID" ПЛК или аппаратному ключу; т. е. группа контроллеров/систем имеет одинаковый "Volume ID" (но по прежнему различные "System ID").
    • Значительно упрощается лицензирование большого числа идентичных систем т. к. требуется всего-лишь один лицензионный файл.
    • Лицензия закрепляется за конкретным разработчиком и может использоваться только им.
    • Лицензия создается на основе конкретной платформы и закрепляется либо за ПЛК (промышленным компьютером), либо за аппаратным ключом. Нужно заранее выбрать один вариант на этапе подготовки комплектации.
    • Пакетная лицензия может сочетаться со стандартной лицензией в случае, если один из ПЛК требует модификации или должен выделяться среди похожих систем. В таком случае стандартная лицензия может основываться или расширять пакетную лицензию.

Хранение и перенос


Лицензионная база хранится в виде файла, официальное название которого "TwinCAT 3 License Response File". Файл хранится на жестком диске ПЛК и может быть заменен; т. к. кроме "System ID", существует "Volume ID", то на жестком диске хранится "TwinCAT 3 Volume License Response File". И тот и другой содержат информацию о лицензиях, соответствующий ID, номер заказа (Order ID) и уровень производительности системы (Performance Level).

Лицензионная база закрепляется за ПЛК или аппаратным ключом, которым может выступать модуль расширения EL6070 (Licensing Key Terminal) или USB-ключ С9900-L100 (третий квартал 2015). Они идентичны по параметрам и позволяют использовать лицензии на различных, но идентичных по конфигурации ПЛК: сняли с "одного", установили на другой, и все завертелось. Использовать одновременно один аппаратный ключ на нескольких ПЛК не получится.
Лицензия активируется из пункта "License" дерева конфигурации проекта.
Если стандартная лицензия привязана к "System ID" ПЛК, то несмотря на идентичность аппаратных платформ, у нового ПЛК будет другой "System ID", поэтому понадобится заново лицензировать ПЛК. Для этого необходимо связаться с местным офисом Бекхофф. Аналогично, если понадобится перейти от использования "System ID" ПЛК, к использованию EL6070/USB ключа.

Если же лицензия привязана к аппаратному ключу (EL6070/USB), то достаточно переставить ключ на новый ПЛК, а затем скопировать файл лицензии x:\TwinCAT\3.x\Target\License со старого ПЛК на новый ПЛК. Звонить никуда не надо.

С пакетными лицензиями все намного проще, т. к. они изначально предполагают использования большого количества идентичных ПЛК. Исключение составляет переход от привязки к ПЛК, на привязку к EL6070/USB-ключу — здесь понадобится звонить в офис Бекхоффа и создавать лицензию заново, т. к. пакетная лицензия может привязываться или только к ПЛК, или только к аппаратным ключам. Выбирайте заранее!


Аппаратные ключи


EL6070-0000 — стандартные лицензии.

TC12xx-0000-xxxx — лицензия привязывается к ПЛК.
TC12xx-0010-xxxx — лицензия привязывается к EL6070.

EL6070 не поставляется отдельно, он всегда идет в составе системы, точнее как часть заказа и привязан к номеру заказа. Маркироваться он будет как EL6070-xxxx, где xxxx - идентификатор конкретного заказчика для его пакетной лицензии.
EL6070 требует переконфигурирования контроллера: нельзя просто так взять и поставить.
Вебинар по теме лицензирования на английском языке с немецким акцентом: "EL6070 licence key terminal for TwinCAT 3.1 licence management".

July 12, 2015

Открытые разработки Beckhoff на GitHub

Появился официальный GitHub аккаунт Бекхофф -- Open Source Projects of Beckhoff Automation GmbH & Co. KG
  • ADS: протокол обмена данными с TwinCAT устройствами (C++). Для разработчиков, которые хотят наладить обмен данными из не-Windows операционных систем с контроллерами Beckhoff. Это исходный код библиотеки ADS Client Library.
  • CCAT: драйвер ядра Linux для Beckhoff CCAT FPGA (Си), предоставляющий доступ к EBus интерфейсу CX50x0, CX51x0 и CX20x0.
  • BBAPI: драйвер Beckhoff BIOS API Linux (C++). Linux Kernel драйвер для Beckhoff BIOS API, для доступа к информации об аппаратном обеспечении, а также для управления нестандартным "железом" (например, дисплей CX2100).

July 1, 2015

Количество и качества Ethernet-интерфейсов

При выборе CX-контроллера нужно помнить, что бывают контроллеры с одним Ethernet-интерфейсом, а бывает с двумя. Больше, не значит лучше.

Для интереса, посмотрим на контроллеры CX1030, CX2030. Это очень разные контроллеры, хотя артикулы отличаются всего-лишь одной цифрой. У первого два ethernet-разъема, но один сетевой интерфейс, у второго -- два сетевых интерфейса и два сетевых разъема, зато у первого есть встроенный аппаратный ethernet-свитч (hardware ethernet-switch).

Встроенный аппаратный ethernet-свитч на два сетевых разъема позволяет строить цепочку мастер-контроллеров (например, daisy chain) без использования дополнительных устройств.



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

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

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

Поэтому, выбирая контроллер, обратите внимание на раздел Technical Data → Interfaces:



June 17, 2015

Машина состояний EtherCAT

Машина состояний EhterCAT (EtherCAT State machine (ESM) -- каждое устройство EtherCAT может и обязано находиться в одном из предопределенных состояний. В каждом из состояний мастером шины производятся определенные действия. Даже в случае ошибки или аварии устройство переходит в заранее предусмотренное состояние и выставляет флаг ошибки. Если устройство не поддерживает аппаратный μС-контроллер, то оно должно эмулировать машину состояний EtherCAT.

  • Init (I) - нет синхронного обмена PDO; мастер может писать в информационные регистры подчиненных.
  • Pre-Operational (Pre-Op, PREOP, P) -- нет синхронного обмена PDO; мастер конфигурирует подчиненных; обмен данными через асинхронные почтовые слоты.
  • Safe Operational (Safe-Op, SAFEOP, S) - обмен данными через асинхронные почтовые слоты; синхронный обмен PDO -- только входа; выхода в безопасном состоянии ("Safe State").
  • Operational (OP, O) -- полностью рабочий режим; синхронный обмен данными через PDO: как входа, так и выхода.
  • Bootstrap (B) -- опциональный режим для "заливки" новых прошивок.

Часто используются сокращения или если хотят показать направление переключения:
  • IP: Init → Pre-Op
  • PI: Pre-Op → Init
  • OI: Op → Init
  • SO: SAFEOP → OP

Для инициализации подчиненного устройства, достаточно выполнить проход по состояниям: Init → Pre-Op → Safe-Op → Op (что сокращенно будет выглядеть как "I-P-S-O"). Здесь состояние Safe-Op не обязательно, но в стандарте фигурирует.

Для переконфигурации устройства необходимо вернуть устройство в состояние Init, а затем выполнить всю цепочку сначала: I-P-S-O. В результате прохода по этой последовательности, мастер заново переконфигурирует подчиненное устройство и гарантированно сбросит все ошибки устройства (если причина ошибки была устранена).

Смена состояния подчиненного устройства (или когда мастер управляет сам собой) происходит не сразу, а посредством управляющего регистра, т. е. сначала мастер запрашивает требуемое состояние, и только затем подчиненный какое-то время пытается изменить свое состояние, по результату изменяя значение регистра состояния. Если подчиненный не смог переключиться в требуемое состояние, то в итоге получится разное значение для запрошенного состояния подчиненного (Requested State) и текущего состояния подчиненного (Current State). Этот процесс хорошо отслеживается на закладке "Online" в System Manager.

Множество тонких настроек поведения EtherCAT-устройства доступны во вкладке "EtherCAT", диалог "Advanced Settings...".


Библиотека TcEtherCAT.lib


Библиотека входит в стандартный комплект TwinCAT и содержит множество низкоуровневых и чуть-выше функций для работы по шине EtherCAT:
  • CoE Interface (CAN over EtherCAT) -- работа с параметрами подчиненных устройств у которых внутренняя шина -- CAN: многие модули расширения, дискретные и аналоговый входа/выхода и пр.
  • SoE Interface (SERCOS over EtherCAT) -- функции работы с параметрами SERCOS-устройств; например, сервоусилители серии AX5000.
  • FoE Interface (File over EtherCAT) -- функции заливки прошивки в устройства.
  • Множество других функций: диагностика рабочих счетчиков (WcState), подсчет контрольных сумм, функции конвертеры для распределенных часов и т. п.

Для переключения состояния подчиненного можно воспользоваться функциями FB_Ec[Get|Req|Set]SlaveState. Для мастера -- аналогично, только Slave нужно заменить на Master.

Функция Get вернет текущее состояние в виде структуры ST_EcSlaveState, которая состоит из двух битовых полей:
  • deviceState - состояние подчиненного устройства.
  • linkState - состояние линии связи.

В библиотеке доступны следующие константы состояний: EC_DEVICE_STATE_INIT, EC_DEVICE_STATE_PREOP, EC_DEVICE_STATE_xxx, ...

Перед определением текущего состояния необходимо обработать поле deviceState битовой маской EC_DEVICE_STATE_MASK. Недостаточно просто вытащить из структуры поле и сравнить его с константой состояния! Например, выясняем, что в настоящий момент устройство не способно полноценно работать:

IF ( curState AND EC_DEVICE_STATE_MASK ) <> EC_DEVICE_STATE_OP THEN


Кроме текущего состояния, поле deviceState содержит биты-флаги ошибок. Для них специальной маски нет, поэтому проверить устройство на ошибки можно следующим образом:

IF ( currState.deviceState AND 16#70 ) > 0 THEN


Подробнее о состоянии устройства можно прочитать в описании структуры ST_EcSlaveState.


Изменение состояния подчиненного устройства

Для изменения состояния устройства, в библиотеке существуют два набора функций: FB_EcReqSlaveState и FB_EcSetSlaveState. Разница в том, что Req отправляет запрос и заканчивает свою работу. Set же будет ожидать, пока устройство не переключится в необходимое состояние и, если этого не произойдет в течение времени tTimeout, выбросит ошибку: 16#745; (*ADSERR_DEVICE_CLIENT_TIMEOUT*)
Если в проекте не требуются нюансы работы с EtherCAT-шиной, то лучше воспользоваться функциями Set.
Не нужно изобретать свою функцию, когда уже есть готовая Set: она использует Req как основу, организуя внутри себя опрос состояния подчиненного устройства.

June 14, 2015

OPC-сервер

OPC-сервер покупается на каждый контроллер отдельно, затем устанавливается. Существует два вида:
  • OPC DA/XML-DA -- только для настольных операционных систем: XP, 7, Embedded Standart, и т. п. [TS6120]. Для его работы необходим DCOM и пр. системные сервисы, и это единственная причина, почему его нет для компактных операционок.
  • OPC UA (IEC 62541) -- не только для настольных [TS6100], но и для компактных: CE, Emb. Compact, ... [TS6100-0030]
Если тип OPC-сервера не важен, то стоит выбрать OPC UA.
Обе версии настраиваются через XML-файл. Существует конфигуратор, который умеет создавать этот XML-файл и активировать его на ПЛК. Немного про настройку можно прочитать в "OPC сервер: настройка и тестирование".

June 9, 2015

Форматы времени и даты

Посмотрим на полный список форматов времени и даты. Немного об этом было в ST и C#, или туда и обратно, теперь рассмотрим подробнее.
Все переменные типа даты, времени, промежутков, длительности и т. п. хранятся в ПЛК как 32-х разрядные целые, беззнаковые.

TIME


Длительность или промежуток времени в миллисекундах. Аналогом в C# можно считать TimeSpan.

Формат:
:= T#521h33m23s231ms;
:= TIME#521h33m23s231ms;

Время в строку: TIME_TO_STRING(T#12ms);
Результат типа STRING: 'T#12ms'

Строка во время: STRING_TO_TIME('T#127ms');
Результат типа TIME: T#127ms


DATE


Только дата  — как число секунд, прошедших с 1 января 1970 года.

Формат:
:= D#1993-06-12;
:= DATE#1993-06-12;

Дата в строку: DATE_TO_STRING(D#2002-08-18);
Результат типа STRING: 'D#2002-08-18'


DATE_AND_TIME или DT


Дата и время — как число секунд, прошедших с 1 января 1970 года. В C# можно использовать DateTime, не забывая, что в ST дата-время начинаются в Unix-стиле с 1970 года, а в C# с нулевого года.

Формат:
:= DT#1993-06-12-15:36:55;
:= DATE_AND_TIME#1993-06-12-15:36:55;

Дата-время в строку: DT_TO_STRING(DT#1998-02-13-14:20);
Результат типа STRING: 'DT#1998-02-13-14:20'

Несложно избавиться в строке от префиксов T#DT#, TOD# и т. п. Функция DELETE входит в стандартную библиотеку STANDART.lib. Удаляем слева n-символов:

str := DELETE(str, 2, 1); (*   T#... TIME_TO_STRING *)
str := DELETE(str, 3, 1); (*  DT#... DT_TO_STRING   *)
str := DELETE(str, 4, 1); (* TOD#... TOD_TO_STRING  *)


TIME_OF_DAY или TOD


Время дня: количество миллисекунд, прошедших начиная от начала дня — от ноля часов и ноля минут (00:00).

Формат:
:= TOD#12:34:56.123;
:= TIME_OF_DAY#12:34:56.123;

Время дня в строку: TOD_TO_STRING(TOD#14:01:05.123);
Результат типа STRING: 'TOD#14:01:05.123'



FILETIME (T_FILETIME)


Структура из двух DWORD (udint) полей. 64-х разрядное целое, содержит число 100-наносекундных интервалов с 1 января 1601 года (UTC). Для вменяемой работы с этим форматом (распаковки), существуют вспомогательные функции FILETIME_TO_DTFILETIME_TO_SYSTEMTIME, и в обратную сторону [...]_TO_FILETIME.


SYSTEMTIME (TIMESTRUCT)


Удобная структура с большим количеством удобных 16-разрядных полей типа WORD (uint):
  • wYear — год, 1970..2106;
  • wMonth — месяц, 1..12 (1 - январь, 2 - февраль и т. д); 
  • wDayOfWeek — день недели, 0..6 (0 - воскресенье (!), 1 - понедельник, ...);
  • wDay — день месяца, 1..31;
  • wHour — час, 0..23;
  • wMinute — минуты, 0..59;
  • wSecond — секунды, 0..59;
  • wMilliseconds — миллисекунды, 0..999.

Существует функция для преобразования строки в системное время: STRING_TO_SYSTEMTIME( 'YYYY-MM-DD-hh:mm:ss.xxx' ). На выходе получаем TIMESTRUCT.

Формат входной строки жестко фиксирован: через разделители '-' и ':' должны быть введены все цифры, а недостающие — заменены нулями:
  • YYYY — год,1601..9999;
  • MM — месяц, 01..12;
  • DD — день, 01..31;
  • hh — час, 00..23;
  • mm — минуты, 00..59;
  • ss — секунды, 00..59;
  • xxx — миллисекунды, 000..999.

Например:

ts := STRING_TO_SYSTEMTIME( '2012-01-30-05:12:09.567' );


Обновлено: 5 февраля 2017 г.

June 8, 2015

Энергонезависимые переменные

Рано или поздно контроллер выключается. Иногда - внезапно, тогда содержимое оперативной памяти теряется. Для таких случаев существует несколько видов специальных переменных, способных сохранять (и восстанавливать) данные в моменты без электричества.
Несколько видов переменных существует из-за ограниченности флэш-памяти на количество записей. Жесткие диски, внешние базы данных, сетевые переменные и пр. - хорошая альтернатива, но не всегда доступны.

RETAIN
По сути применимы только для серии BC. Можно и в других случаях, но неудобно, т. к. сохраняют свое значение только при корректном завершении работы TwinCAT. Не спасут при внезапном пропадании электричества (*). Совершенно не экономят ресурс флэш-памяти. На контроллерах BC сохраняют свое значение при изменении значения переменной и могут удлинить время цикла (если нужно).

PERSISTENT
Аналогично RETAIN, но сохраняются при вызове специального функционального блока (FB_WritePersistentData из TcUtilities.lib), либо при корректном выключении TwinCAT (*). Экономят ресурс флэш-памяти.
При использовании RETAIN и PERSISTENT данных, значения переменных по прежнему сбрасываются на флэш-диск. TwinCAT самостоятельно восстанавливает данные и может отследить нарушение целостности сохраненных данных (об этом можно узнать из специальной системной переменной: SYSTEMINFO). Остальные подробности - в справочной системе: TX1200 | TwinCAT PLC.

NOV/DP-RAM


Nonvolatile DualPort RAM - энергонезависимая двухпортовая  память.

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

Но(!) не все контроллеры поддерживают этот вид памяти.

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


Односекундные бесперебойники


Теперь вернемся к звездочке в скобках (*): ограничение на аккуратное завершение работы TwinCAT снимается "односекундным бесперебойником" (S-UPS: capacitive seconds UPS). За счет энергии, накопленной в ионисторах, эта опция позволяют подпитывать контроллер некоторое время, достаточное для сброса данных во флэш-память. Для работы этой функции необходимо обрабатывать функцию FB_S_UPS из библиотеки TcSUPS.Lib.

Но(!), опять-таки, не все контроллеры и не для всех.
Для всех видов переменных, при использовании файловых фильтров EWF или FBWF, необходимо разрешить на запись каталог Boot. Это происходит автоматически при включении фильтров, но проверить, не помешает.