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: