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" (три). Для выполнения команды еще раз, необходимо записать число три в эту ячейку еще раз.

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, инициализации параметров, и т. п.
• Не зависит от других модулей.
• Может содержать как одну, так и несколько функций

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

• Описание модуля: ClassID, ObjectID.
• Машину состояний EtherCAT: INIT, PREOP, SAFEOP, OP.
• Интерфейс TwinCAT COM-объекта: ITComObject.

Машина состояний 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".

Лицензирование 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".

Открытые разработки 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).

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

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

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

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

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

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

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

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