Программирование ARM CiA306: стандарт файлов EDS для CANopen Thu, March 28 2024  

Поделиться

Нашли опечатку?

Пожалуйста, сообщите об этом - просто выделите ошибочное слово или фразу и нажмите Shift Enter.

CiA306: стандарт файлов EDS для CANopen Печать
Добавил(а) microsin   

Применение устройств в сетевом обмене требует конфигурации параметров устройств и описания их коммуникационных возможностей. CANopen определяет стандартный способ доступа к этим параметрам через словарь объектов (object dictionary, OD). Приведен перевод CiA-306 Version 1.3 (DS 306 V1.3, январь 2005 г.) [1].

Для работы со сложными системами CANopen требуются специальные программные инструменты. Это упрощает планирование, конфигурирование и анализ процессов, и значительно повышает безопасность системы.

Программный инструментарий обслуживания сетей CANopen требует наличия электронного описания устройств CANopen. Чтобы обеспечить такое описание, независимое от производителей, был разработан специальный формат описания устройств Electronic Data Sheet (EDS). Впоследствии на основе этого формата появились и другие, например Device Configuration File (DCF), который описывает конкретную инкарнацию конфигурации устройства. Формат Module Data Sheet (MDF) описывает модули устройств, которые имеют модульную структуру.

CiA301 CiA 301, CANopen application layer and communication profile [3]

CiA302 CiA 302, CANopen framework for CANopen managers and programmable CANopen devices

CiA401 CiA 401, CANopen device profile generic I/O modules

CiA405 CiA 405, CANopen interface and device profile for IEC 61131 programmable devices

ISO646 ISO/IEC 646, ISO 7-bit coded character set for information interchange

ASCII Американский стандартный код для обмена информацией (формат текста).

CAN Controller Area Network, промышленный стандарт для построения сетей обмена данными.

COB Communication object, объект для обмена данными.

COB-ID Идентификатор COB.

CR Carriage return, возврат каретки.

DCF Device configuration file, файл описания устройства.

DIN Deutsches Institut fur Normung (Немецкий Институт Стандартизации).

EBNF Extended Backus-Naur form, расширенная форма Бэкуса — Наура. Из Википедии: формальная система определения синтаксиса, в которой одни синтаксические категории последовательно определяются через другие. Используется для описания контекстно-свободных формальных грамматик.

EDS Electronic data sheet, описание электронного устройства.

ID Identifier, идентификатор.

ISO International standardisation organisation, организация международных стандартов.

LF Line feed, перевод строки.

LSS Layer settings specification, протокол для конфигурирования параметров связи устройств в сети CANopen, подробнее см. [2].

MD Module description, описание модуля.

MDS Module data sheet, документация модуля.

NMT Network management, управление сетью.

OS Operation system, операционная система.

OSI Open systems interconnection, открытое описание взаимодействия систем.

PDO Process data object, объект для обмена обрабатываемыми данными.

RPDO Receive PDO, объект приема обрабатываемых данных.

SDO Service data object, объект для передачи данных обслуживания.

TPDO Transmit PDO, объект передачи обрабатываемых данных.

Примечание: также см. описание аббревиатур и терминов CANopen в разделе "Словарик" статьи [2].

[4. Спецификация Electronic data sheet]

4.1. Общая информация. Чтобы предоставить пользователю устройства CANopen расширенную поддержку, должен существовать стандартный метод описания устройства. Это дает возможность создавать стандартизованные инструменты для следующих задач:

• Конфигурирование устройств CANopen.
• Разработка сетей с устройствами CANopen.
• Управление информацией проекта сети на различных платформах.

Таким образом, введено 2 типа файлов, чтобы определить устройство CANopen с помощью электронных средств. EDS может использоваться для описания:

• Функционала коммуникаций и объектов согласно стандарта CiA301 [3] и фреймворкам приложения.
• Объектов, специфичных для устройства, как это определено в профилях устройства.

EDS служит шаблоном для устройства "XY" и вендора "UV". DCF описывает инкарнацию (программисты применяют для этого термин "экземпляр") сконфигурированного устройства не только с объектами, но также и со значениями этих объектов. Кроме того, он содержит значение для скорости передачи устройства (CAN bitrate) и для ID узла (node-ID).

CiA 306 EDS structure

Рис. 1. Структура EDS.

EDS предоставляется производителем (вендором) для определенного устройства. Если производитель не предоставляет EDS для своих устройств CANopen, то может использоваться EDS по умолчанию. "EDS по умолчанию" включает в себя все записи профиля устройства для определенного класса устройства. Пользователь должен знать, что описание отличается от конкретно реализованных опций того устройства, что может вызвать серьезные проблемы!

4.2. Базовая структура EDS

Файл с расширением *.eds это простой текстовый файл, формат которого похож на обычный ini-файл Windows. Файлы кодируются как текст ASCII, в этом тексте должен использоваться набор символов ISO646. Строки могут заканчиваться символом LF (перевод строки, стиль Linux) или комбинацией символов CR+LF (возврат каретки+перевод строки, стиль Windows). Общая длина строки не должна превышать 255 символов.

Файл EDS содержит несколько секций, каждая из которых содержит группу взаимосвязанных элементов (записей). Секции и их записи выглядят вот так:

[section name]
keyname=value

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

Пример:

[DeviceInfo]
VendorName=CANFestival
VendorNumber=0x00000000
ProductName=CAN-Generator
RevisionNumber=45
BaudRate_10=0
BaudRate_20=0
BaudRate_50=0
BaudRate_125=1
BaudRate_250=0
BaudRate_500=0
BaudRate_800=0
BaudRate_1000=0
SimpleBootUpMaster=0
SimpleBootUpSlave=0
Granularity=8
DynamicChannelsSupported=0
CompactPDO=0
GroupMessaging=0
NrOfRXPDO=1
NrOfTXPDO=1
LSS_Supported=0

В этом примере показаны основные параметры устройства: информация о производителе, название устройства, номер его ревизии, поддерживаемые скорости CAN (поддерживается только скорость 125 кбит/сек), поддержка протокола LSS (отсутствует) и другие параметры.

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

Оператор keyname=value определяет значение для каждой записи. Слово keyname задает имя элемента (атрибута), которому присваивается значение value. Имя элемента может быть любой последовательностью английских букв и цифр, и оно должно заканчиваться непосредственно знаком =. Имя элемента не чувствительно к регистру символов. Если имя элемента состоит только из цифр, то оно интерпретируется как строка, а не число. Это означает, к примеру, что запись 10=nnn не то же самое, что и 0xA=nnn. То же самое правило накладывается и на имена секций.

Value это строка, которая интерпретируется в зависимости от контекста (см. далее), т. е. может быть как числом, так и строкой.

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

Секции в файле могут появляться в любом порядке. Внутри каждой секции её элементы также могут следовать в любом порядке.

Если не указано обратное, все секции и записи в EDS-файле являются обязательными. Чтобы поддержать будущие расширения, разрешено добавлять дополнительные секции и записи внутри этих секций. Утилиты, предназначенные для проверки совместимости файлов EDS (EDS Conformance Test Tool) распознают эти записи, и пометят их предупреждающими сообщениями.

4.3. Интерпретация value. Анализ значения записи зависит от её специфического смысла. Для этого определены некие общие правила:

1. Начальные и завершающие пробелы обрезаются. Т. е. строка

keyname=value

будет интерпретирована так же, как и строка

keyname= value

2. Целые числа могут быть записаны как обычные десятичные, или как шестнадцатеричные (с префиксом 0x), или как восьмеричные (с префиксом из цифры 0). Например, если запись соответствует числу, то смысл следующих строк определения записи идентичен:

keyname=10
keyname=0xa
keyname=0x0a
keyname=0xA
keyname=0x000A
keyname=012

3. Если запись не имеет значения, то после знака = должен идти конец строки (пустая запись). Пропущенная запись интерпретируется так же, как и запись без значения (пустая запись).

4. Строковые значения сохраняются без кавычек. Строки октетов и сырые данные доменов сохраняются как последовательность шестнадцатеричных байт (без префикса 0x). Байты, у которых старший ниббл равен 0, должны быть сохранены с начальным нулем. Если данные не помещаются в одной строке, они могут быть сохранены в отдельном файле, см. раздел 5.3.1 ParameterValue в описании стандарта.

Пример октетной строки:

DemoSeq=01a1053c45aabbccddeeff

Битовые строки должны сохраняться как последовательность символов 0 и 1. Пример:

BitDemo=11001010000111

Для записей одного из целых типов может использоваться формула. Это дает шанс описать значения, которые зависят от других значений. Например, идентификаторы COB-ID объектов PDO по умолчанию зависят от node-ID устройства.

Синтаксис формулы дается следующим EBNF-описанием:

IntEntryValue = $NODEID { "+" number }

Для конкретных устройств $NODEID заменяется действительным значением node-ID устройства. $NODEID должен появляться в начале выражения, иначе строка интерпретируется без формулы. В этой формуле можно использовать только смещение к этому node-ID. Более сложные выражения не разрешены.

4.4. Информация о файле

EDS содержит информацию о самом себе. Это полезно для управления версиями конфигураций и устройств. Информация о файле сохраняется в секции [FileInfo]. Используются следующие ключевые слова:

Имя записи Функция
FileName Имя файла (соответствующее ограничениям используемой операционной системы).
FileVersion Актуальная версия файла (Unsigned8).
FileRevision Актуальная ревизия файла (Unsigned8).
EDSVersion Версия спецификации (3 символа) в формате "x.y". Если эта запись отсутствует, то она равна "3.0". Файлы EDS, записанные в соответствии с этим документом, должны использовать "4.0".
Description Описание файла (максимум 243 символа).
CreationTime Время создания файла в формате hh:mm(AM|PM).
CreationDate Дата создания файла в формате mm-dd-yyyy.
CreatedBy Имя или описание создателя файла (максимум 245 символов).
ModificationTime Время последней модификации в формате hh:mm(AM|PM).
ModificationDate Дата последней модификации в формате mm-dd-yyyy.
ModifiedBy Имя или описание создателя, изменившего файл (максимум 244 символа).

Не обязательная секция [Tools] может описывать некоторые аспекты использования EDS программными пакетами. Спецификация этой секции дана в CiA405.

4.5. Основное описание устройства

EDS должен содержать специфическую информацию об устройстве:

• vendor name (имя производителя устройства),
• vendor ID (числовой идентификатор производителя),
• device name (имя устройства),
• device code (код устройства),
• version information (информацию о версии),
• LSS-information (части адреса LSS),
• device abilities (возможности устройства).

Вся эта информация должна находиться в секции [DeviceInfo]. Должны использоваться следующие ключевые слова:

Имя записи Функция
VendorName Имя производителя (максимум 244 символа).
VendorNumber Уникальный идентификатор производителя в соответствии sub-индексом 01h идентичности объекта (Unsigned32).
ProductName Имя изделия устройства (максимум 243 символа).
ProductNumber Код продукта в соответствии с sub-индексом 02h идентичности объекта (Unsigned32).
RevisionNumber Номер версии продукта в соответствии с sub-индексом 03h идентичности объекта (Unsigned32).
OrderCode Код заказа для этого продукта (максимум 245 символов).
BaudRate_xxx Эти записи показывают поддерживаемые скорости CAN (указывается значение типа boolean, где 0 = скорость не поддерживается, 1 = поддерживается). Указываются записи с именами BaudRate_10, BaudRate_20, BaudRate_50, BaudRate_125, BaudRate_250, BaudRate_500, BaudRate_800, BaudRate_1000.
SimpleBootUpMaster Функционал простого главного узла загрузки (boolean, 0 = не поддерживается, 1 = поддерживается).
SimpleBootUpSlave Функционал простого подчиненного узла загрузки (boolean, 0 = не поддерживается, 1 = поддерживается).
Granularity Разрешена или нет гранулярность для отображения этого устройства - большинство существующих устройств поддерживают гранулярность 8 (Unsigned8; 0 - отображение не модифицируемо, 1..64 гранулярность).
DynamicChannelsSupported В соответствии со стандартом CiA302 эта запись показывает функцию генерации динамической переменной. Если здесь указано не равное 0 значение, то существует дополнительная секция DynamicChannels (подробности см. в CiA302 и CiA405).
GroupMessaging В соответствии со стандартом CiA301 Annex A эта запись должна показать функцию мультиплексированных объектов PDOs (boolean, 0 = не поддерживается, 1 = поддерживается). Подробности см. в CiA301 [3].
NrOfRXPDO Количество поддерживаемых PDO приема (Unsigned16).
NrOfTXPDO Количество поддерживаемых PDO передачи (Unsigned16).
LSS_Supported Показывает, поддерживается ли LSS (boolean, 0 = не поддерживается, 1 = поддерживается).

По соображениям совместимости зарезервированы записи ProductVersion, ProductRevision, LMT_ManufacturerName, LMT_ProductName, ExtendedBootUpMaster и ExtendedBootUpSlave.

4.6. Словарь объектов (OD)

4.6.1. Эта логическая часть EDS должна предоставить следующую информацию:

• Какие объекты поддерживаются в OD.
• Предельные значения параметров.
• Значения по умолчанию.
• Типы данных.

Дополнительно может быть предоставлена дополнительная информация.

Описание объектов должно быть структурно поделено на 3 отдельные части, соответствующие:

• Обязательным (mandatory) объектам.
• Не обязательным (optional) объектам.
• Объектам, специфическим для производителя (manufacturer specific).

4.6.2. Отображение фиктивных записей ("dummy"). Иногда требуется предоставить промежутки в отображениях переменных устройства. Это означает, к примеру, что устройство обрабатывает только последние 2 байта данных PDO, длина которого 8 байт. Первые 6 байт должны игнорироваться (возможно они будут обрабатываться другим устройством). В этом случае настройка отображения устройства должна содержать dummy-записи для первых 6 байт.

Для этой цели должны использовать индексы из области типа данных OD. Пользователь устройства должен знать, какой тип данных может использоваться для создания фиктивных записей, и какой не может (в действительности важна только длина объекта dummy).

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

Dummy< индекс типа данных (без префикса 0x) >={0|1}

Пример:

[DummyUsage]
Dummy0001=0
Dummy0002=1
Dummy0002=1
Dummy0003=1
Dummy0004=1
Dummy0005=1
Dummy0006=1
Dummy0007=1

Это означает, что устройство поддерживает отображение типов данных Integer8/16/32 и Unsigned8/16/32.

4.6.3. Описания объектов

4.6.3.1. Списки объектов. OD должен быть структурно поделен на 3 части:

• [MandatoryObjects] здесь должны содержаться только обязательные объекты. Здесь должны быть как минимум объекты 1000h (тип устройства) и 1001h (регистр ошибки). Для устройств, которые реализовали версию 4.0 CANopen, дополнительно обязательным должен быть объект 1018h (объект идентификации).
• [OptionalObjects] эта часть должна содержать все другие объекты областей 1000h-1FFFh и 6000h-FFFFh.
• [ManufacturerObjects] должна содержать все объекты, специфические для производителя (находящиеся в области 2000h-5FFFh).

Каждая из этих секций должна содержать список поддерживаемых объектов, который содержит записи этих поддерживаемых объектов. Запись SupportedObjects показывает количество объектов в соответствующей секции (Unsigned16). Записи обозначаются десятичными цифрами, начиная с 1. При таком способе нумерации имя последней записи соответствует количеству доступных записей. Пример:

[OptionalObjects]
SupportedObjects=7
1=0x1005
2=0x1016
3=0x1017
4=0x1400
5=0x1600
6=0x1800
7=0x1A00

4.6.3.2. Описание объекта. Каждый из перечисленных объектов должен быть описан в своей секции. Имена секций должны быть составлены по одинаковой схеме:

[< ИНДЕКС_ОБЪЕКТА >]

Здесь для < ИНДЕКС_ОБЪЕКТА > используются шестнадцатеричные значения для индекса и sub-индекса без префикса "0x" и без дополняющего лидирующего 0.

В секции могут присутствовать следующие ключевые слова:

Имя записи Функция
SubNumber Показывает количество sub-индексов (sub-index), доступных по этому индексу (Unsigned8), не считая sub-индекса FFh. Это может использоваться для описания sub-объектов, как описано далее. Эта запись может быть пустой или отсутствующей, если нет sub-объектов.
ParameterName Предоставляет имя параметра (до 241 символов).
ObjectType Показывает код объекта (необязательная запись, см. далее).
DataType Показывает индекс типа данных объекта в OD.
LowLimit Показывает нижний предел значения объекта (только если это применимо).
HighLimit Показывает верхний предел значения объекта (только если это применимо).
AccessType Для этого объекта строкой показывает тип доступа: "ro" - read only (только для чтения), "wo" - write only (только для записи), "rw" - read/write (чтение/запись), "rwr" - read/write on process input (чтение/запись на процессе ввода), "rww" - read/write on process output (чтение/запись на процессе вывода), "const" - постоянное значение.
DefaultValue Показывает значение по умолчанию для этого объекта.
PDOMapping Показывает, можно или нет отобразить этот объект к PDO (boolean, 0 = не отображается, 1 = можно отобразить).
ObjFlags Опциональная запись для назначения специального поведения (см. далее).
ModifiedBy Имя или описание создателя, изменившего файл (максимум 244 символа).

Ключевое слово ObjectType является не обязательным. Если оно отсутствует, то считается как ObjectType=0x7 (=VAR, т. е. переменная).

В следующей таблице дан обзор обязательств ключевых слов. В соответствии типу объекта записи в секциях объекта должны быть обязательными (mandatory, m), не обязательными (optional, o) или не поддерживаемыми (not supported, n). Отсутствующий ObjectType эквивалентен ObjectType VAR. Значения в круглых скобках должны считаться как значения для замены, если запись отсутствует. Пустые скобки () эквивалентны "запись=". Для определения ObjFlags и CompactSubObj см. главы ниже.

Имя записи DEFTYPE
VAR
DEFSTRUCT*
ARRAY*
RECORD*
DEFSTRUCT**
ARRAY**
RECORD**
DOMAIN
ParameterName m m m m
ObjectType o (VAR) m m m
DataType m n m o (DOMAIN)
AccessType m n m o (rw)
DefaultValue o () n o () o ()
PDOMapping o (0) n o (0) n
SubNumber n m n*** n
LowLimit o () n o () n
HighLimit o () n o () n
ObjFlags o (0) o (0) o (0) o (0)
CompactSubObj n n*** m n

Примечания:

* без CompactSubObj или с нулевым CompactSubObj.
** с не нулевым CompactSubObj. См. далее примечания в 4.6.3.4.2.
*** не поддерживается. Опционально может быть 0.

Пример:

[1000]
ParameterName=Device Type
ObjectType=0x7
DataType=0x0007
AccessType=ro
DefaultValue=
PDOMapping=0

Для описания структурированного объекта (который содержит sub-индексы) каждый sub-индекс должен быть описан в своей секции. Имя секции должно быть составлено по правилу:

[< index >(sub< sub-index >)]

При этом должны использоваться шестнадцатеричные значения для index и sub-index без лидирующего "0x" и без дополнительного лидирующего 0.

Пример:

[1003]
SubNumber=2
ParameterName=Pre-defined Error Field
ObjectType=8
 
[1003sub0]
ParameterName=Number of Errors
ObjectType=0x7
DataType=0x0005
AccessType=ro
DefaultValue=0x1
PDOMapping=0
 
[1003sub1]
ParameterName=Standard Error Field
ObjectType=0x7
DataType=0x0007
AccessType=ro
DefaultValue=0x0
PDOMapping=0

Совет для приложения: в принципе возможно, что у списка sub-объекта нет последовательных sub-индексов. Значение sub-индекса 00h должно всегда предоставлять самый верхний реализованный sub-индекс. Напротив, запись SubNumber (показывает количество sub-объектов объекта) EDS должна содержать некоторое количество реализованных sub-индексов, включая subindex 00h.

Пример:

[1010]
SubNumber=2
ParameterName=Store Parameters
ObjectType=8
 
[1010sub0]
ParameterName=largest Sub-Index supported
ObjectType=0x7
DataType=0x0005
AccessType=ro
DefaultValue=0x4
PDOMapping=0
 
[1010sub4]
ParameterName=save manufacturer defined parameters
ObjectType=0x7
DataType=0x0007
AccessType=ro
DefaultValue=0x1
PDOMapping=0

Не обязательная запись ObjFlags позволяет определить специальное поведение для инструментов - как рассматривать объект.

Пример: типичной задачей для конфигурационного ПО является загрузка сконфигурированного файла DCF. Если делать это без специального распознавания специальных объектов, то возникает следующая проблема: такие объекты, как 1010h "Store parameters" будут записаны либо неправильными значениями, либо как минимум в неправильном порядке. Сначала записываются объекты от 1000h до 100Fh, затем "Store parameters", и затем другие параметры. Это приведет к несоответствиям, и получится не то, что хочет пользователь. Одним из решений проблемы могла быть специальная обработка таких объектов конфигурационным ПО. Но даже тогда может произойти случай, когда профили устройства или специфические объекты производителя получат подобную проблему.

Эти специальные объекты помечаются в файлах EDS и DCF. Секции описания объекта могут содержать запись ObjFlags, содержащую unsigned32: младший бит должен быть значением boolean (0=false, 1=true) для "Refuse write on download" (отказ от записи при загрузке), второй бит должен быть значением boolean для "Refuse read on scan" (отказ от чтения при сканировании), другие биты зарезервированы для будущего использования организацией CiA, и должны быть в 0.

Если эта запись отсутствует, то это эквивалентно, что в ней значения 0. Рекомендуется записать эту запись в EDS/DCF только если она не равна 0. Это позволит избежать нежелательного увеличения размера файла.

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

4.6.3.4.1. Определения PDO. В принципе определения объекта для записей PDO все приблизительно одинаковые. Самой важной информацией является количество TPDO и RPDO, которое дается стандартом CiA301 [3]. Это позволяет опустить все описания объекта PDO. Чтобы пометить такую организацию EDS, должна быть добавлена запись CompactPDO (Unsigned8) в секцию DeviceInfo. Она должна содержать реализованные sub-индексы объектов коммуникации PDO в качестве битовой маски. Самый младший байт должен определять, реализован ли sub-индекс 01h, второй бит соответственно будет определять, реализован ли sub-индекс 02h и так далее.

[DeviceInfo]
...
CompactPDO=0x3

Надлежащие типы данных неявно известны по спецификациям CANopen, как и значения по умолчанию для первых PDO COB-ID. Другие значения, такие как тип передачи и отображение, очень часть находятся в зоне ответственности планирования и настройки проекта, что не требуется знать в момент загрузки.

Если PDO описан явно, то должны быть описаны не только все sub-объекты параметров коммуникации, но также и параметры отображения этого PDO. Это явно разрешено комбинированием неявно описанных PDO с явно описанными PDO:

NrOfRXPDO общее количество RPDO
Количество неявных PDO = (общее количество PDO) – (количество перечисленных PDO)

Пример:

[DeviceInfo]
NrOfRXPDO = 5
CompactPDO=0x3
 
;явно определенные RX-PDO
[1402]
...
 
[1403]

Здесь существует в компактной форме 3 неявно определенных PDO с индексами 1400h, 1401h и 1404h (остальные 2 определены явно в соответствующих секциях).

4.6.3.4.2. Значения массивов. Чаще всего все секции sub-индексов массива эквивалентны, кроме имени. Это позволяет описать только шаблон основного объекта. Для этого может быть добавлена дополнительная запись CompactSubObj типа unsigned8. Если такая запись существует, и не равна 0, то:

• подразумевается, что задаются имена для xxxn с xxx в качестве имени основного объекта и n в качестве десятичного sub-индекса. Sub-индекс 00h должен содержать имя NrOfObjects
• подразумевается, что типы объектов VAR
• тип данных для всех sub-индексов, кроме 00h и FFh показаны записью DataType главного объекта. Sub-индекс 00h должен всегда быть типом данных unsigned8
• подразумевается, что пределы отсутствуют (NONE)
• тип доступа для всех sub-индексов, кроме 00h и FFh, показаны записью AccessType основного объекта. Подразумевается, что тип доступа для sub-индекса 00h только чтение (ReadOnly)
• значения по умолчанию для всех sub-индексов, кроме 00h и FFh показаны записью DefaultValue главного объекта. Значение по умолчанию для sub-индекса 00h это число, которое показывает CompactSubObj
• запись PDOMapping для всех sub-индексов, кроме 0 и 255, даны записью PDOMapping главного объекта. Подразумевается, что sub-индекс 0 не может иметь отображения.

Должно выдерживаться правило, что список sub-индексов не содержит разрывов.

Если используется CompactSubObj, то запись SubNumber не поддерживается, она должна быть равна 0, пустая или вовсе отсутствовать.

Можно задавать явные имена, если имена по умолчанию не достаточно полезны. Для этого может появиться список соответствующих имен. Имя секции должна быть дана через [xxxxName], где xxxx дано в качестве индекса (Index). Запись NrOfEntries должна показать количество имен в списке. Имена должны быть перечислены со своими sub-индексами как запись с десятичным именем (начиная с 1). Пример:

[2050Name]
NrOfEntries=3
1=NameOfSubIndex1
2=NameOfSubIndex2
15=NameOfSubIndex15

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

4.6.3.4.3. Сетевые переменные. В случае программируемых устройств, соответствующих CiA302, CiA405, описание динамических сетевых переменных массивов не должно быть записано в EDS. Вся необходимая информация уже дана в секции DynamicChannels. Чтобы гарантировать непротиворечивую интерпретацию EDS, не разрешено описать секции динамической сетевой переменной!

Описание для сетевых переменных, которые не рассматриваются динамично, но полностью описаны в EDS, может использовать механизм CompactSubObj.

4.6.4. Связи объектов. Чтобы упростить реализацию инструмента конфигурации, можно группировать связанные объекты с помощью ключевого слова ObjectLinks. Связь объектов должна быть структурирована следующим образом:

[< index >ObjectLinks]
ObjectLinks=< количество имеющихся связей >
1=< index 1-го связанного объекта >
2=< index 2-го связанного объекта >
3=< index 3-го связанного объекта >
4=< index 4-го связанного объекта >
5=< index 5-го связанного объекта >
...

Список связей объектов должен быть пронумерован десятичными числами, начиная с 1. Пример:

; предположим, что мы описываем закрытую петлю обратной связи
; это объект "factor"
[5800ObjectLinks]
ObjectLinks=0x3
; усиление
1=0x5801
; ноль
2=0x5802
; полюс
3=0x5803

4.6.5. Комментарии. Кроме определение комментариев в с помощью точки с запятой в начале строки, в EDS могут быть добавлены комментарии с помощью секции Comments. Эта секция должна предоставить записи, определяющие количество строк комментариев и содержимое этих строк. Количество строк задается ключевым словом Lines (Unsigned16), строки Line< номер строки > задают строки комментария (максимум 249 символов в строке). Номер строки должен кодироваться десятичным числом. Пример:

[Comments]
Lines=3
Line1=|-------------|
Line2=| Don’t panic |
Line3=|-------------|

[5. Файл DCF]

5.1. Файл описания устройства (device configuration file, DCF) включает в себя все объекты сконфигурированного устройства. Файл DCF должен быть структурирован так же, как и как и EDS для этого устройства. Здесь должны быть некоторые дополнительные записи, чтобы описать сконфигурированное устройство.

5.2. Секция информации о файле. LastEDS должна предоставлять имя файла EDS, который использовался в качестве шаблона для этого DCF.

5.3. Секции объектов

5.3.1. ParameterValue. В стандартном описании ParameterValue должно показывать значение объекта (как это определено ObjectType и DataType). Пример:

; Значение для объекта 1006h (период цикла коммуникации)
[1006]
SubNumber=0
ParameterName=Communication Cycle Period
ObjectType=0x7
DataType=0x0007
LowLimit=1000
HighLimit=100000
DefaultValue=20000
AccessType=ro
ParameterValue=15000
PDOMapping=0

Если ObjectType это домен (0x2), то значение объекта может быть сохранено в файле:

Имя записи Функция
UploadFile Если для этого объекта выполняется доступ на чтение, то данные сохранены в этом файле (244 символа, в соответствии с ограничениями OS).
DownloadFile Если для этого объекта выполняется доступ на запись, то данные для записи берутся из этого файла (242 символа, в соответствии с ограничениями OS).

Пример:

; объект 5600h, специфичный для производителя (загружаемая программа)
[5600]
ParameterName=Real Good Program (RGP)
ObjectType=0x2
DataType=0x000F
AccessType=wo
DownloadFile=C:\FAST\PROGRAMS\FIRST.HEX
 
; объект 5700h, специфичный для производителя (дамп ядра)
[5700]
ParameterName=Core Dump (CD)
ObjectType=0x2
DataType=0x000F
AccessType=ro
UploadFile=C:\FAST\DEBUG\DUMPALL.HEX

5.3.2. Denotation. Когда DCF используется в конкретном приложении, то полезно назначать имена объектам, специфические для приложения. Это может быть реализовано путем простого переименования значения записи ParameterName. В качестве альтернативы этому можно записать измененные имена в дополнительной записи Denotation (в переводе это "обозначение").

Пример записи EDS:

[6000sub1]
ParameterName=Dig.Input Lines 0-7
...

Пример записи в DCF, составленной с изменением ParameterName:

[6000sub1]
ParameterName=Имя1СпецифичноеДляПриложения
...

Пример записи в DCF с использованием Denotation:

[6000sub1]
ParameterName=Dig.Input Lines 0-7
Denotation=Имя1СпецифичноеДляПриложения
...

Использование механизма простого переименования имеет преимущество в получении файла меньшего размера, и при этом упрощается реализация ПО, потому что ParameterName обязателен, и поэтому всегда имеется в наличии. Использование записи Denotation открывает возможность регенерации соответствующего файла EDS с сохранением оригинальных имен объектов.

См. врезку "4.6.3.4. Компактное хранилище", относящуюся к файлу EDS. Имеются те же самые причины для формата компактного хранилища файлов DCF.

5.3.3.1. Определения PDO. Если имеется запись CompactPDO секции DeviceInfo, и она не равна 0, то опционально возможно записать только описание объекта и sub-объекта для конкретно сконфигурированных PDO. Все другие PDO должны быть запрещены.

5.3.3.2. Значения массивов. Если существует запись CompactSubObj, и она содержит не равное 0 значение, то все ParameterValue для sub-объектов должны быть сохранены в дополнительном списке. Имя секции должна быть показана как [xxxxValue] с xxxx, представляющим индекс. Запись NrOfEntries должна предоставлять количество записей в списке. Значения должны быть перечислены с использованием их sub-индекса в качестве десятичного имени записи (в диапазоне 1..254). Все пропущенные записи в списке должны иметь значение, указанное DefaultValue.

Пример:

[2050]
SubNumber=0
ParameterName=A big array
ObjectType=8
DataType=0x0007
AccessType=rw
DefaultValue=0x0
PDOMapping=0
CompactSubObj=200
 
[2050Value]
NrOfEntries=3
1=200
2=0xab
15=100

Допускается использование того же синтаксиса для сохранения записей ParameterName в дополнительном списке. Имя секции должна быть показана [xxxxDenotation] с xxxx в качестве индекса. Запись NrOfEntries должна предоставлять количество записей в списке. Значения должны быть перечислены с использованием их sub-индексов в виде десятичного имени записи (в диапазоне 1..254). Все пропущенные записи в списке должны иметь имена в соответствии с правилу по умолчанию, или должна быть секция [xxxxName], как это описано в секции 4.6.3.4.2 с описанием файла EDS.

5.3.3.3. Значения сетевых переменных. Обычно не требуется конфигурировать конкретные значения для динамических сетевых переменных. Если это нужно делать, то значения должны быть сохранены в стандартном формате, показанном в секции 5.3.1. Причина этого в том, что массивы сетевых переменных могут иметь пробелы, но невозможно реализовать эти пробелы с помощью механизма CompactSubObj.

Сетевые переменные, которые не рассматриваются динамически (DynamicChannelsSupported=0) могут быть сохранены с помощью механизма CompactSubObj.

Ввод устройства в эксплуатацию. Для этого должна быть дополнительная секция в DCF с именем DeviceComissioning:

Имя записи Функция
NodeID Показывает адрес устройства (Unsigned8).
NodeName Показывает имя узла (максимум 246 символов).
Baudrate Показывает скорость CAN устройства (Unsigned16).
NetNumber Показывает номер сети (Unsigned32).
NetworkName Показывает имя сети (максимум 243 символа).
CANopenManager Показывает, что устройство является менеджером CANopen (boolean, 1 = CANopen manager, 0 или если CANopenManager отсутствует, то = не manager).
LSS_SerialNumber Показывает серийный номер, соответствующий identity object sub 4 (Unsigned32).

Пример:

[DeviceComissioning]
NodeID=2
NodeName=DEVICE2
Baudrate=1000
NetNumber=42
NetworkName=very important subnet in a big network
LSS_SerialNumber=9912345

6.1. Чаще всего создание гибких устройств реализуется с помощью устройства соединителя шин (bus coupler device), которое может быть расширено модулями. Это базовое устройство автоматически детектирует присутствие модулей расширения. Эти методы обычно используют понятную и прямолинейную организацию. Расширение такого устройства приводит к изменяющемуся количеству данных обработки (process data) и данных конфигурации (configuration data). Применительно к CANopen это приводит к изменяющимся OD. Для расширения process data в OD обычно используют 2 метода.

В примере модулей ввода-вывода (I/O modules CiA401) используются последовательные sub-индексы. Например, первые 8 бит цифровых входов устройства создают объект 6000h 01h, вторые создают объект 6000h 02h, и так далее. Первое устройство цифровых выходов работает на 6200h 01h. Дополнительно здесь могут быть глобальные объекты, которые создаются только когда подсоединен как минимум один модуль определенного типа. Например CiA401 определяет объект "Global_Interrupt_Enable" 6423h, который может использоваться, если подсоединен как минимум один объект аналогового входа. Подсоединение в будущем аналоговых входов не будет дублировать этот объект.

Другой метод дан в CiA301 [3]. Здесь мульти-модульное устройство использует метод сдвига копии структуры OD на смещение 800h. Первый OD начинается с 6000h, второй с 6800h, и так далее. Объект 1000h определяет устройство как multi device module.

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

6.2. EDS

6.2.1. Назначение модулей расширения. EDS устройства bus coupler содержит список поддерживаемых модулей расширения. Для каждого типа модуля расширения должны быть описаны функции модуля в описании модуля (module description, MD). Количество поддерживаемых MD должно быть сохранено в EDS-секции [SupportedModules].

NrOfEntries Количество поддерживаемых модулей расширения (Unsigned16).

6.2.2. Объекты PDO. Должно использоваться заранее определенное отображение по умолчанию PDO, которое соответствует имеющемуся профилю. Каждый новый sub-индекс должен быть заполнен в соответствующем, предварительно определенном PDO. Таким способом может быть отображено до 8 байт цифровых входных данных, 8 байт цифровых выходных данных, 4 аналоговых входов и 4 аналоговых выходов. Остальные данные могут быть отображены на дополнительные PDO. Поскольку они не определены заранее, и поскольку их идентификаторы COB-ID должны быть помечены как недопустимые, то после старта (boot-up) их использование должно быть переключено в свободное состояние. В системах, использующих заранее определенный набор соединений (pre-defined connection set), эту задачу выполняет приложение, и будет известно подходящее использование этих дополнительных PDO. В более сложных системах должна быть создана конфигурация, включающая конфигурацию отображения. В этом случае менеджер конфигурации выполняет задачу по разрешению всех объектов PDO.

Использование заранее определенных PDO требует знания соответствующих записей отображения. Поскольку это отображение зависит от модулей расширения, то оно не может быть введена в EDS. Стандартный метод, описывающий все возможные случаи, получится слишком сложным. Чтобы оставить эту спецификацию максимально простой, дается только одно правило:

Если EDS содержит не пустой список модулей расширения, то он позволяет описать записи отображения с объектами, которые не обязательно существуют. Когда становится известной конкретная конфигурация модуля, список отображения должен быть сделан допустимым до первого не существующего отображенного объекта. Тогда sub-index 00h соответственно укорачивается.

Это правило не позволяет описать все случаи, но описывает широкий диапазон практических реализаций. Пример:

EDS для IO bus coupler содержит следующие описания: первое отображение TPDO для объектов от 6000h 01h до 6000h 08h. Третий TPDO от 6000h 09h до 6000h 10h. Должны быть добавлены два 16-битных модуля расширения. Тогда первый TPDO будет допустимым. Его отображение содержит записи от 6000h 01h до 6000h 04h. Sub-index 00h укорачивается на 4. Третий TPDO недопустимый.

6.3. Описание модуля. Описание модуля должно быть размещено в секциях с именами, которые начинаются на Mx, где x должно быть десятичным счетчиком, начинающимся с 1, до значения NrOfEntries из секции [SupportedModules], без лидирующего 0. Далее это всегда показано аббревиатурой Mx. Каждое описание модуля должно предоставить некоторые записи в секции MxModuleInfo:

Имя записи Функция
ProductName Показывает имя изделия (максимум 243 символа).
ProductVersion Показывает информацию о версии (Unsigned8).
ProductRevision Показывает информацию о ревизии (Unsigned8).
OrderCode Показывает специфичный код производителя (максимум 245 символов).

В необязательной секции [MxComments] может появиться текстовое описание модуля.

Имя записи Функция
Lines Показывает количество строк комментария (Unsigned16).
Line< номер строки > Показывает одну строку комментария (максимум 248 символов). Номер строки должен кодироваться десятичным числом.

Пример:

[M1Comments]
Lines=2
Line1=Module with 16 input lines
Line2=and 8 output lines.

Если требуется, устройство должно реализовать объекты по специальным фиксированным индексам, если подключен как минимум 1 модуль соответствующего типа. Эти объекты описаны в списке секции [MxFixedObjects]:

Имя записи Функция
NrOfEntries Показывает количество фиксированных объектов (Unsigned16).

Далее идут записи, пронумерованные десятичным значением N, начиная с 1:

1=0x6423
2=
N=...

Фиксированные объекты должны быть помещены в секциях MxFixedxxxx. Здесь xxxx должно показывать шестнадцатеричный индекс без префикса 0x и без любых лидирующих 0. Содержимое этих секций должно быть таким же, как указано в описаниях объекта главы 4.6.3.2.

Sub-объекты должны быть определены таким же способом. Именование секций sub-та должно быть MxFixedxxxxsubx. Здесь xxxx должно показывать шестнадцатеричный индекс без префикса 0x и x должен показывать шестнадцатеричный sub-индекс без префикса 0x и без лидирующих 0.

Если несколько модулей содержат одинаковые фиксированные объекты, то их атрибуты должны быть эквивалентны.

Секция [MxSubExtends] должна содержать список всех объектов, которые инстанцированы новыми sub-индексами.

Имя записи Функция
NrOfEntries Показывает количество расширенных объектов (Unsigned16).

За NrOfEntries должны идти записи с десятичными именами, начиная с 1:

1=0x6000
2=...

Объекты должны быть помещены в секциях [MxSubExtxxxx]. Здесь xxxx должно показывать шестнадцатеричный индекс без префикса 0x и без любых лидирующих 0. В этих секциях должны находиться те же записи, что и в стандартном описании объекта EDS-файла, как это приведено в главе 4.6.3.2. Дополнительные записи:

Count. Показывает количество (Unsigned8) расширенных sub-индексов с описанием, которое создается для каждого модуля.

Если для каждого подключенного модуля должно быть определено 1 или большее количество sub-индексов для построения нового sub-индекса, то Count должен быть этим числом. Например, 32-битный модуль создает 4 sub-индекса, каждый из которых имеет 8 бит: Count=4.

Если будут собраны несколько модулей, чтобы сформировать новый sub-индекс, то номер должен быть 0, за которым должна идти точка с запятой и количество бит, которые создаются для каждого модуля, чтобы построить новый sub-индекс. Например 2-битные модули с 8-битными объектами: первый sub-индекс создан на модулях 1..4, следующий на модулях 5..8, и так далее: Count=0;2. Эти объекты создаются, когда начинается новый байт: модуль 1 создает sub-index 1; модули 2-4 заполняют их; модуль 5 создает sub-индекс 2, и так далее.

ObjExtend. Показывает опциональную запись unsigned8. Если массив заполняется до конца, то может использоваться следующий объект. Например, в CiA401 объект 6020h адресует 128 одиночных входных линии. Линия 129 адресуется со следующего главного индекса 6021h. Значение для этой записи определяет максимальный sub-индекс, после которого должен использоваться следующий объект. Если здесь указано значение 0, или запись отсутствует, то следующий объект использоваться не должен.

Если несколько модулей содержат те же самые объекты расширения, то их атрибуты должны быть эквивалентны.

6.4. Файл DCF

Из информации EDS устройств bus coupler и описаний модулей расширения инструментарий конфигурирования может создавать корректный OD и записать его в DCF. Для этой цели не нужно делать изменения в спецификацию DCF.

Для упрощения обработки желательно сохранять информацию о том, из каких модулей состоит устройство. Это может быть сделано копированием секции [SupportedModules] в DCF, после чего создается список ссылок в секции [ConnectedModules]:

Имя записи Функция
NrOfEntries Показывает количество подключенных модулей (Unsigned16).

Далее идет список:

1=3
2=3
x=...

Здесь x должен показать десятичный счетчик списка, начиная с 1. Значение unsigned16 должно быть ссылкой на список [SupportedModules]. Соответствующие описания модулей должны быть сделаны по правилам EDS (имена секций должны начинаться с Mx, см. пункт 6.3).

Пример:

[SupportedModules]
NrOfEntries=4
 
[ConnectedModules]
NrOfEntries=3
1=2
2=2
3=4

В этом устройстве подключено 3 модуля. Первый и второй описаны в секциях, поименованных с M2..., третий описан в секциях, именованных с M4...

Примечание: порядок следования устройств важен, поскольку это определяет назначение объектов на физические линии.

6.5. Пример

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

EXAMPLE.EDS

[FileInfo]
FileName=example.eds
...
 
[DeviceInfo]
VendorName=XYZ
ProductName=DemoDevice
OrderCode=0
...
 
[SupportedModules]
NrOfEntries=2
 
[MandatoryObjects]
SupportedObjects=2
1=0x1000
2=0x1001
 
[1000]
ParameterName=Device Type
...
 
[OptionalObjects]
SupportedObjects=8
1=0x1008
2=0x1009
3=0x100a
4=0x1004
5=0x1400
6=0x1600
7=0x1800
8=0x1a00
...
 
[M1ModuleInfo]
ProductName=Digital Input Module
ProductVersion=1
ProductRevision=0
OrderCode=DI4711
[M1SubExtends]
NrOfEntries=1
1=0x6000
 
[M1SubExt6000]
ParameterName=ReadState8InputLines
DataType=5
DefaultValue=0
PDOMapping=1
AccessType=ro
Count=1
 
[M2ModuleInfo]
ProductName=Digital Output Module
ProductVersion=1
ProductRevision=0
OrderCode=DO0815
 
[M2SubExtends]
NrOfEntries=1
1=0x6200
 
[M2SubExt6200]
ParameterName=WriteState8OutputLines
DataType=5
DefaultValue=0
PDOMapping=1
AccessType=rww
Count=1

[Ссылки]

1. CiA 306 CANopen electronic device descriptionsite:can-cia.org.
2. Обзор протокола CANopen.
3CiA301: слой приложения и профиль коммуникации CANopen.

 

Добавить комментарий


Защитный код
Обновить

Top of Page