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].

Не обязательная запись 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.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.

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:

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

Пример:

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

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

Далее идут записи, пронумерованные десятичным значением 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 должны идти записи с десятичными именами, начиная с 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]:

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

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