Программирование ARM CiA301: слой приложения и профиль коммуникации CANopen Sat, October 12 2024  

Поделиться

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

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

CiA301: слой приложения и профиль коммуникации CANopen Печать
Добавил(а) microsin   

[6. Модель CANopen]

6.1. Эталонная модель

На рис. 1 показана общая модель концепции коммуникации CANopen, подобная эталонной модели сетей ISO-OSI (левая часть рисунка).

Примечание: это перевод стандарта CiA301 (DS301), оригинал см. в интернете или в архиве [4]. Есть также альтернативный перевод этого документа, который мне не очень нравится (см. файл doc-rus\CANopenDS301-rus.pdf в архиве [4]).

CiA301 reference model fig01

Рис. 1. Эталонная модель.

Application Layer (слой приложений, прикладной уровень): представляет концепцию конфигурирования и обмена данными реального времени, как и механизмы для синхронизации между устройствами (узлами) сети CANopen. Функциональность слоя приложения предоставляет возможность логически поделить приложения на отдельные сервисные объекты в этом слое. Сервисный объект предоставляет специфическую функциональность протокола и все связанные с этим службы. Эти службы описаны в спецификации на каждый сервисный объект.

Приложения взаимодействуют, вызывая службы сервисного объекта на прикладном уровне. Чтобы реализовать эти службы, этот объект обменивается данными через сеть CAN Network с сервисным объектом (объектами) другого узла по заданному протоколу. Этот протокол описан в спецификации сервисного объекта.

Service Primitives (примитивы службы): это способ, которым приложения взаимодействуют на прикладном уровне. Имеется 4 разных примитива:

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

CiA301 Service Types fig02

Рис. 2. Типы служб слоя приложений.

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

Локальная служба вовлекается только локальным сервисным объектом, т. е. без взаимодействия по сети. Приложение выдает запрос к своему локальному сервисному объекту, который выполняет запрошенную службу без обмена с сервисным объектом (объектами) другого узла (узлов) сети.
Неподтвержденная служба (unconfirmed service) это один или большее количество сервисных объектов других узлов сети. Приложение выдает запрос к своему локальному сервисному объекту. Этот запрос передается к сервисному объекту (объектам) других узлов сети, при этом к их приложению передается индикация. Результат не подтверждается обратно.
Подтвержденная служба (confirmed service) может вовлекать только один сервисный объект другого узла сети. Приложение выдает запрос к своему локальному сервисному объекту. Этот запрос передается к сервисному объекту (объектам) других узлов сети, при этом к их приложению передается индикация. Другое приложение выдает ответ, который передается к изначальному сервисному объекту как подтверждение для запрашивающего приложения.
Провайдер инициированной службы вовлекает только локальный сервисный объект. Сервисный объект (который будет поставщиком услуг) детектирует событие, не запрошенное требуемой службой. Тогда это событие показывается приложению.

Неподтвержденные и подтвержденные службы вместе называются удаленными (сетевыми) службами (remote-службами).

6.2. Модель устройства

6.2.1. Общее описание. Устройство (узел сети) CANopen структурируется следующим образом (см. рис. 3):

Communication (обмен сообщениями, коммуникация) – этот функциональный узел предоставляет объекты коммуникации и соответствующую функциональность для транспорта элементов данных через нижележащую сетевую структуру (шину).
Object Dictionary (словарь объектов, сокращенно OD) – это база данных, коллекция всех элементов данных, которые влияют на поведение объектов приложения, объекты коммуникации и машину состояний, используемые в этом устройстве.
Application (приложение) – представляет функциональность устройства в контексте взаимодействия с рабочим окружением.

CiA301 Device Model fig03

Рис. 3. Модель устройства.

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

6.2.2. Словарь объектов (Object Dictionary, OD). Наиболее важная часть профиля устройства это описание OD. OD по существу это группировка объектов, доступных через сеть заранее упорядоченным, строго определенным способом. Каждый объект в OD адресуется с использованием 16-битного индекса (не путать идентификаторами сети CAN!). Также существует 8-битный sub-индекс OD, адресующий подчиненный элемент объекта. Общая структура стандартного OD показана ниже. Эта организация довольно полно удовлетворяет другим индустриальным концепциям систем последовательной шины:

Таблица 1. Общая структура OD.

Индекс (hex) Объект
0000 Не используется
0001-001F Static Data Types (статические типы данных)
0020-003F Complex Data Types (сложные типы данных)
0040-005F Manufacturer Specific Complex Data Types (сложные типы данных, специфические для производителя устройства)
0060-007F Device Profile Specific Static Data Types (статические типы данных, специфические для профиля устройства)
0080-009F Device Profile Specific Complex Data Types (сложные типы данных, специфические для профиля устройства)
00A0-0FFF Зарезервировано для будущего использования
1000-1FFF Communication Profile Area (область профиля коммуникации)
2000-5FFF Manufacturer Specific Profile Area (область профиля, специфического для производителя)
6000-9FFF Standardised Device Profile Area (область стандартизованного профиля устройства)
A000-BFFF Standardised Interface Profile Area (область стандартизованного профиля интерфейса)
C000-FFFF Зарезервировано для будущего использования

Примечание: в этом описании термин entry, обозначающий информационную единицу словаря OD, переводится как "элемент" словаря, и иногда как "запись" словаря.

OD может содержать максимум 65536 элементов, адресуемых по 16-битному индексу (существует 8-битный sub-индекс, позволяющий адресовать дополнительные подчиненные записи в пределах одного элемента).

Static Data Type. Статические типы данных с индексами от 0001h до 001Fh содержат определения для стандартных типов наподобие BOOLEAN, INTEGER, floating point (число с плавающей точкой), string (строка) и т. д. Эти элементы добавлены в словарь только для ссылки, они не могут быть прочитаны или записаны (короче говоря, в обычном OD они просто отсутствуют).

Complex Data Type. Сложные типы данных с индексами от 0020h до 003Fh это заранее предопределенные структуры, которые состоят из стандартных типов данных, и они являются общими для всех устройств. В OD простых устройств эти записи отсутствуют.

Manufacturer Specific Complex Data Type. Сложные типы данных, специфичные для производителя устройства с индексами от 0040h до 005Fh это структуры, составленные из стандартных типов данных. Они являются специфическими для определенного устройства.

Device Profile. Профили устройства, которые могут содержать дополнительные типы данных, специфичных для их типа устройства. Статические типы данных, определенные устройством, перечислены по индексам 0060h .. 007Fh, а сложные по индексам 0080h .. 009Fh.

Устройство может опционально предоставить структуры поддерживаемых сложных типов данных (индексы 0020h .. 005Fh и 0080h .. 009Fh) для доступа на чтение по соответствующему индексу. Тогда sub-индекс 0 предоставляет количество элементов (адресуемых sub-индексами) по этому индексу, и последующие sub-индексы содержат типы данных, закодированные как UNSIGNED16 в соответствии с таблицей 39.

Communication Profile Area. Область профиля коммуникации с индексами от 1000h до 1FFFh содержит параметры, относящиеся к обмену по сети CAN. Эти элементы являются общими для всех устройств.

Standardised Device Drofile Area. Область стандартизированного профиля устройства с индексами от 6000h до 9FFFh, содержит все объекты данных, общие для его класса устройств, которые можно прочитать или записать через сеть. Профили устройства могут использовать записи от 6000h до 9FFFh для описания параметров устройства и его функциональности.

С этим диапазоном можно описать 8 разных устройств. В таком случае устройство называется как Multiple Device Modules (устройство с несколькими модулями). Multiple Device Modules составлены из сегментов профиля устройства, которых может быть до 8 штук. С помощью этой функции можно построить устройства с многочисленной функциональностью. Отличающиеся профили устройства сдвинуты по индексу друг относительно друга на 800h. Таким образом, диапазон индексов для Multiple Device Modules распределен следующим образом:

Диапазон индексов Устройство
6000h .. 67FFh
6800h .. 6FFFh
7000h .. 77FFh
7800h .. 7FFFh
8000h .. 87FFh
8800h .. 8FFFh
9000h .. 97FFh
9800h .. 9FFFh
device 0
device 1
device 2
device 3
device 4
device 5
device 6
device 7

Распространение PDO должно использоваться для каждого сегмента Multiple Device Module со смещением 64, например первый PDO второго сегмента получит номер 65. Таким способом поддерживается система максимум с 8 сегментами.

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

Оставшееся пространство OD с индексами от 2000h до 5FFFh полностью предназначено для поддержки функционала, специфического для производителя.

6.2.2.1. Использование индекса и sub-индекса. Для адресации всех элементов в словаре OD используется 16-битный индекс. В случае простой переменной индекс ссылается напрямую на её значение. Однако в случае сложных записей и массивов индекс адресует всю структуру данных.

Чтобы позволить получить доступ к отдельным полям структуры данных элемента словаря, определен sub-индекс. Для одиночных элементов OD, таких как UNSIGNED8, BOOLEAN, INTEGER32 и т. п. значение sub-индекса равно 0 (sub-индекс для таких простых элементов словаря присутствует неявно). Для сложных элементов словаря OD, таких как массивы или структуры с несколькими полями данных, sub-индексы ссылаются на поля этой структуры данных, на которую указывает главный индекс. К полям структуры осуществляется доступ через sub-индекс, поля могут представлять разные типы данных.

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

Коммуникационная модель поддерживает передачу синхронных и асинхронных сообщений. Методом передачи синхронного сообщения становится возможным осуществление координированного по всей сети запуска сбора и обработки. Синхронная передача сообщений поддерживается заранее определенными в стандарте коммуникационными объектами: сообщение синхронизации (SYNC), сообщение метки времени (time stamp). Синхронные сообщения передается по заранее определенному сообщению синхронизации, асинхронное сообщение может быть передано в любой момент времени.

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

Времена запрета могут быть назначены приложением в зависимости от его функциональности. Из-за этого различают 3 типа взаимоотношений коммуникации:

• Master/Slave (взаимоотношение между главным и подчиненным устройством, рис. 4 и 5).
• Client/Server (взаимоотношение клиент-сервер, рис. 6).
• Producer/Consumer (взаимоотношение продюсер - потребитель, рис. 7 и 8).

6.3.1. Взаимодействие Master/Slave. В любой момент времени только одно устройство в сети играет роль главного (Master), поддерживая для этого специфическую функциональность. Все другие устройства сети считаются подчиненными (Slave). Master выдает запрос, и адресуемое (или адресуемые) устройство (устройства) отвечает, если протокол подразумевает такое поведение.

CiA301 Unconfirmed Master Slave Communication fig04

Рис. 4. Обмен данными Master - Slave без подтверждения (Unconfirmed Communication).

CiA301 Confirmed Master Slave Communication fig05

Рис. 5. Обмен данными Master - Slave с подтверждением (Confirmed Communication).

Взаимодействие Master/Slave применяется в протоколе NMT, где в сети присутствует один главный узел (Master), и остальные устройства являются подчиненными (Slave). Мастер сети управляет состоянием подчиненных устройств (описание протокола NMT см. далее).

6.3.2. Взаимодействие Client/Server. Это взаимосвязь между одиночным клиентом и одиночным сервером. Клиент выдает запрос выгрузки или загрузки (upload/download), что вызывает срабатывание сервера для выполнения определенной задачи. После завершения этой задачи сервер отвечает подтверждением на запрос.

CiA301 Client Server Communication fig06

Рис. 6. Обмен типа клиент - сервер.

Взаимодействие Client/Server применяется в протоколе SDO, через который мастер сети может прочитать словарь (OD) подчиненного узла сети и/или изменить его (если это предусмотрено словарем узла).

6.3.3. Взаимодействие Producer/Consumer - модель Pull/Push. Это взаимосвязь типа генератор/потребитель, что вовлекает один генератор (продюсер) и потребителей, которых может 0 или больше. Модель push (проталкивание) характеризуется не подтверждаемой службой, которая запрашивается продюсером. Модель pull (выборка) характеризуется подтверждаемой службой, запрашиваемой потребителем.

CiA301 Push model fig07

Рис. 7. Модель Push.

CiA301 Pull model fig08

Рис. 8. Модель Pull.

Взаимодействие Producer/Consumer применяется при синхронизации узлов сети (передача объектов SYNC) и при обмене прикладными данными (объекты PDO).

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

7.1. Трансивер. Используется высокоскоростной трансивер по стандарту ISO 11898, с уровнями VCAN_H и VCAN_L +16V. Гальваническая изоляция для узлов сети является опциональной. Рекомендуется использовать трансивер, которые может выдерживать неправильное подключение (или ошибочное отключение) любого из проводов шины, включая превышение напряжений V+ до 30V.

7.2. Скорость следования бит (bit rate) и интервалы времени. Рекомендуется использовать скорости и интервалы(4), перечисленные в таблице 2. Устройство CANopen должно поддерживать как минимум один вариант скорости из этой таблицы.

Таблица 2. Рекомендуемые скорости передачи данных и параметры времени бита.

Bit rate (скорость бит)
Длина шины(1)
tb tq Ltq SP
1 мегабит/сек
25 м
1 мкс 8 125 нс 6tq (750 нс)
800 кбит/сек
50 м
1.25 мкс 10 125 нс 8tq (1 мкс)
500 кбит/сек
100 м
2 мкс 16 125 нс 14tq (1.75 мкс)
250 кбит/сек
250 м(2)
4 мкс 16 250 нс 14tq (3.5 мкс)
125 кбит/сек
500 м(2)
8 мкс 16 500 нс 14tq (7 мкс)
50 кбит/сек
1000 м(3)
20 мкс 16 1.25 мкс 14tq (17.5 мкс)
20 кбит/сек
2500 м(3)
50 мкс 16 3.125 мкс 14tq (43.75 мкс)
10 кбит/сек
5000 м(3)
100 мкс 16 6.25 мкс 14tq (87.5 мкс)

Здесь:

tp номинальное время бита.
tq количество квантов времени, приходящихся на бит.
Ltq длина кванта времени.
Sp место точки выборки (sample point).

Значения в таблице базируются на следующих предположениях:

Тактовая частота генератора 16 МГц ±0.1% (1000 ppm).
Режим анализа уровней сигнала (Sampling mode): одиночная выборка, SAM = 0.
Режим синхронизации: только по перепадам уровня от recessive к dominant, SYNC = 0.
Ширина интервала синхронизации (Synchronisation jump width): 1 * tq, SJW = 0.
Phase Segment 2: 2 * tq, TSEG2 = 1.

Примечания:

(1) Округленная оценка длины шины (худший случай) на основе задержки распространения 5 нс/м и общей эффективности работы устройства:

0.8 .. 1 мегабит/сек: 210 нс.
250 .. 500 килобит/сек: 300 нс (включая задержку 2*40 нс для схем оптической развязки).
125 килобит/сек: 450 нс (включая задержку 2*100 нс для схем оптической развязки).
10 .. 50 килобит/сек: 1.5 tq; эффективная задержка = задержка ((recessive -> dominant) + (dominant -> recessive)) / 2.

(2) Для шины длиной больше примерно 200 м рекомендуется использовать оптоизоляторы. Если оптоизоляторы размещаются между контроллером CAN и трансивером, то это влияет на максимальную длину шины - в зависимости от задержки распространения узлов оптической развязки. Например, отнимается 4 м от длины шины на 10 нс вводимой опторазвязкой задержки.

(3) Для шины, длина которой больше примерно 1 км, может потребоваться мост или репитер сигнала.

(4) Интервалы бит в таблице вычислены на базе тактовой частоты генератора 16 МГц. Если используется другой генератор, то количество квантов времени (tq) может быть другим. Тем не менее, расположение точки выборки сигнала (sample point) должно быть как можно ближе к рекомендуемой.

[8. Слой данных (DATA LINK LAYER)]

Описанные сети базируются на data link layer и его sub-слоях в соответствии с ISO 11898.

8.1. CAN Frame Type. Эта спецификация базируется на стандартных фреймах CAN (CAN Standard Frame) с шириной поля идентификатора 11 бит. Не требуется поддержка расширенного фрейма CAN (CAN Extended Frame) с шириной поля идентификатора 29 бит.

Однако определенные приложения могут потребовать использование расширенного фрейма с полем ID из 29 бит. Сеть CANopen может работать и в таком режиме, если он поддерживается всеми узлами сети.

[9. Слой приложения (APPLICATION LAYER)]

9.1.1. Общее описание типов данных и кодирования. Чтобы можно было обмениваться значимыми данными по сети CAN, формат этих данных и их значение должны быть известны продюсеру данных и потребителю (потребителям) данных. Спецификация CANopen моделирует эту концепцию типами данных.

Правила кодирования определяют представление значений типов данных и синтаксис переноса данных по сети CAN для этих представлений. Значения представлены как последовательности бит. Последовательности бит передаются по сети как последовательности октетов бит (байтов). Для цифровых типов данных принят стиль кодирования little endian, как показано на рис. 9.

номер октета 1. 2. k.
  b7..b0 b15..b8 b8k-1..b8k-8

Рис. 9. Синтаксис передачи и последовательность бит.

Приложения частот требуют типы данных, основанные на базовых типах. С использованием механизма составного типа данных (compound data type mechanism) список доступных типов данных может быть расширен. Например, некоторые общие расширенные типы данных определены как "Visible String" (видимая строка) или "Time of Day" (время дня) (см. 9.1.6.2 и 9.1.6.4). Составные типы данных являются средством реализовать определяемые пользователем типы "DEFTYPES" в терминологии этой спецификации, и не "DEFSTRUCTS" (см. таблицу 37: Object Dictionary Object Definitions).

[9.1.2. Определения типа данных]

Тип данных определяет взаимосвязь между значениями и кодированием данных для этого типа. Типам данных назначаются имена в их определениях типа. Используется следующий синтаксис данных и определений типа данных (см. EN 61131-3):

data_definition ::= type_name data_name
type_definition ::= constructor type_name
constructor ::= compound_constructor | basic_constructor
compound_constructor ::= array_constructor | structure_constructor
array_constructor ::= ‘ARRAY’ ‘[‘ length ‘]’ ‘OF’ type_name
structure_constructor ::= ‘STRUCT’ ‘OF’ component_list
component_list ::= component { ‘,’ component }
component ::= type_name component_name
basic_constructor ::= ‘BOOLEAN’ |
   ‘VOID’ bit_size |
   ‘INTEGER’ bit_size |
   ‘UNSIGNED’ bit_size |
   ‘REAL32’ |
   ‘REAL64’ |
   ‘NIL’
bit_size ::= ‘1’ | ‘2’ | < ... > | ‘64’
length ::= positive_integer
data_name ::= symbolic_name
type_name ::= symbolic_name
component_name ::= symbolic_name
symbolic_name ::= letter { [ ‘_’ ] ( letter | digit ) }
positive_integer ::= ( ‘1’ | ‘2’ | < ... > | ‘9’ ) { digit }
letter ::= ‘A’ | ‘B’ | < ... > | ‘Z’ | ‘a’ | ‘b’ | < ... > | ‘z’
digit ::= ‘0’ | ‘1’ | < ... > | ‘9’

Рекурсивные определения не разрешены. Тип данных определяется type_definition называется базовым, когда конструктор basic_constructor. Для составного типа соответственно используется compound_constructor или array_constructor, для структуры structure_constructor.

[9.1.3. Последовательности бит]

9.1.3.1. Определение последовательностей бит. Бит может принимать значения 0 или 1. Последовательность бит b это упорядоченный набор из 0 или большего количества бит. Если последовательность бит b содержит больше 0 бит, то она обозначается как bj, где j > 0. Предположим b0, ..., bn-1 будут битами, где n положительное число. Тогда

b = b0 b1 ... bn-1

называется последовательностью бит длиной |b| = n. Пустая последовательность бит длиной 0 обозначается буквой ε. Примеры последовательностей бит: 10110100, 1, 101.

Оператор инверсии (¬) на последовательности бит b = b0 b1 ... bn-1 дает последовательность бит

¬b = ¬b0 ¬b1 ... ¬bn-1

Здесь для бит ¬0 = 1 и ¬1 = 0.

Базовая операция на последовательностях бит - конкатенация (склеивание).

Предположим, у нас есть последовательности бит a = a0 ... am-1 и b = b0 ... bn-1. Тогда конкатенация a и b обозначается ab и будет равна

ab = a0 ... am-1 b0 ... bn-1

Пример: (10)(111) = 10111 является конкатенацией 10 и 111. Выполняется следующее равенство для произвольных последовательностей бит a и b:

|ab| = |a| + |b|

и

εa = aε = a

9.1.3.2. Синтаксис передачи последовательностей бит. Для передачи через сеть CAN последовательность бит реорганизуется в последовательность октетов. Для октетов используется шестнадцатеричная нотация. Предположим, b = b0 ... bn-1 будет последовательностью бит, где n ≤ 64. Обозначим k не отрицательного целого числа как 8(k - 1) < n < 8k. Тогда b преобразуется в k октетов, собранных как показано на рис. 9. Биты bi, где i ≥ n самых старших октетов содержат ничего не значащие биты. Октет 1 передается первым, и k передается последним. Таким образом, последовательность бит передается по сети CAN следующим образом:

b7, b6, ..., b0, b15, ..., b8, ...

Пример:

бит 9   ...     бит 0
       |                    |
    10  0001 1100
    2h   1h   Ch
              = 21Ch

Последовательность бит b = b0 .. b9 = 0011 1000 01 представляет число UNSIGNED10 со значением 21Ch, и оно передается в 2 октетах: сначала 1Ch, и затем 02h.

[9.1.4. Базовые типы данных]

Для базовых типов данных "type_name" равно строке связанного конструктора (наподобие символического имени), например:

BOOLEAN BOOLEAN

это определение типа для типа данных BOOLEAN.

9.1.4.1. NIL. Данные базового типа NIL представлены буквой ?.

9.1.4.2. Boolean. Данные базового типа BOOLEAN получают значения TRUE (истина, 1) или FALSE (ложь, 0). Значения представлены последовательностями бит длиной 1.

9.1.4.3. Void. Базовый тип VOIDn представлен последовательностями бит длиной n. Значение типа данных VOIDn не определено. Биты в последовательности данных VOIDn должны быть либо явно указаны, либо помечены "do not care" (не имеет значения). Тип данных VOIDn полезен для зарезервированных полей и для выравнивания компонентов составных значений по границам октетов.

9.1.4.4. Unsigned Integer (целое число без знака). Базовый тип данных UNSIGNEDn принимает не отрицательные значения целых чисел. Диапазон значений 0, ..., 2n-1. Данные представлены последовательностями бит длиной n. Последовательность бит

b = b0 ...bn-1

назначается значению

UNSIGNEDn(b) = bn-1*2n-1+ ...+ b1*21 + b0*20

Обратите внимание, что последовательность бит начинается слева самым младшим значащим байтом. Например, значение 266 = 10Ah с типом данных UNSIGNED16 передается по шине двумя октетами, при этом сначала передается 0Ah, и затем 01h.

Различные типы UNSIGNEDn передаются следующим образом:

номер октета 1. 2. 3. 4. 5. 6. 7. 8.
UNSIGNED8 b7..b0              
UNSIGNED16 b7..b0 b15..b8            
UNSIGNED24 b7..b0 b15..b8 b23..b16          
UNSIGNED32 b7..b0 b15..b8 b23..b16 b31..b24        
UNSIGNED40 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32      
UNSIGNED48 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40    
UNSIGNED56 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40 b55..b48  
UNSIGNED64 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40 b55..b48 b63..b56

Рис. 10. Примеры синтаксиса передачи типа данных UNSIGNEDn.

9.1.4.5. Signed Integer (целое число со знаком). Данные базового типа INTEGERn принимает целые значения, положительные и отрицательные, и 0. Диапазон значений составляет -2n-1, ..., 2n-1-1. Данные передается в последовательности бит длиной n. Последовательность бит

b = b0 .. bn-1

назначается значению

INTEGERn(b) = bn-2 * 2n-2 + ...+ b1 * 21 + b0 * 20 если bn-1 = 0 (положительное целое число), и с помощью арифметики дополнения до двух (two's complement arithmetic),

INTEGERn(b) = - INTEGERn(^b) - 1 если bn-1 = 1 (отрицательное целое число).

Обратите внимание, что последовательность бит начинается слева самым младшим значащим байтом. Например, значение -266 = FEF6h с типом данных INTEGER16 передается по шине двумя октетами, при этом сначала передается F6h, и затем FEh.

Различные типы INTEGERn передаются следующим образом:

номер октета 1. 2. 3. 4. 5. 6. 7. 8.
INTEGER8 b7..b0              
INTEGER16 b7..b0 b15..b8            
INTEGER24 b7..b0 b15..b8 b23..b16          
INTEGER32 b7..b0 b15..b8 b23..b16 b31..b24        
INTEGER40 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32      
INTEGER48 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40    
INTEGER56 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40 b55..b48  
INTEGER64 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40 b55..b48 b63..b56

Рис. 11. Примеры синтаксиса передачи типа данных INTEGERn.

9.1.4.6. Числа с плавающей точкой. Данные базовых типов данных REAL32 и REAL64 получают значения реальных чисел. Тип данных REAL32 представлен последовательностью из 32 бит. Кодирование значений REAL32 соответствует стандарту IEEE 754-1985 для чисел с плавающей точкой одинарной точности (single precision floating-point). Тип данных REAL64 представлен последовательностью 64 бит. Кодирование REAL64 соответствует стандарту IEEE 754-1985 Standard для чисел с плавающей точкой двойной точности (double precision floating-point).

Последовательность бит длиной 32 имеет либо конкретное значение (конечное ненулевое реальное число, ±0, ±_) или NaN (not-a-number, не число). Последовательность бит

b = b0 ... b31

назначает значение (конечное ненулевое реальное число)

REAL32(b) = (-1)S * 2E-127 * (1 + F)

Здесь:

S = b31 это знак числа.
E = b30 * 27 + … + b23 * 20, 0 < E < 255 это не смещенная экспонента числа (un-biased exponent).
F = 2-23 (b22 * 222 + … + b1 * 21 + b0 * 20) это дробная часть числа.

E = 0 используется для представления is used to represent ±0. E=255 используется для представления бесконечности и NaN.

Обратите внимание, что последовательность бит начинается слева самым младшим значащим битом.

Пример числа 6.25 в типа REAL32:

6.25 = 2E-127 (1 + F)

здесь

E =129 =27 +20 и

F= 2-1 +2-4 = 2-23 (222+219), так что число представлено следующим образом:

S E F
b31 b30 .. b23 b22 .. b0
0 100 0000 1 100 1000 0000 0000 0000 0000

6.25 = b0 .. b31 = 0000 0000 0000 0000 0001 0011 0000 0010

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

номер октета 1. 2. 3. 4.
REAL32 00h 00h C8h 40h
b7..b0 b15..b8 b23..b16 b31..b24

Рис. 12. Синтаксис передачи данных типа REAL32.

[9.1.5. Составные типы данных (Compound Data Types)]

Определения составных типов данных расширяются до уникального списка определений типа, включающих только основные типы данных. Соответственно составной тип данных 'type_name' это упорядоченный список компонентов данных, поименованных 'component_name_i' базового типа 'basic_type_i'.

Конструкторами составного типа данных являются ARRAY и STRUCT OF. Синтаксис:

STRUCT OF
   basic_type_1 component_name_1,
   basic_type_2 component_name_2,
   ...          ...
   basic_type_N component_name_N
type_name
 
ARRAY [ длина ] OF basic_type type_name

Последовательность бит, представляющая данные составного типа, получается конкатенацией последовательностей бит отдельных компонентов данных. Предположим, что компоненты 'component_name_i' представлены последовательностями бит b(i) для i = 1, ..., N. Тогда составной тип данных представлен склеенной последовательностью

b0(1) .. bn-1(1) .. bn-1(N).

Пример:

Рассмотрим тип данных

STRUCT OF
   INTEGER10 x,
   UNSIGNED5 u
NewData

Предположим, что x = -423 = 259h, и u = 30 = 1Eh. Пусть b(x) и b(u) обозначают последовательности бит, представляющие значения x и u. Тогда:

b(x) = b0(x) .. b9(x) = 1001101001
b(u) = b0(u) .. b4(u) = 01111
b(xu) = b(x) b(u) = b0(xu) .. b14(xu) = 1001101001 01111

Значение этой структуры будет передано в 2 октетах, сначала 59h, и затем 7Ah.

[9.1.6. Расширенные типы данных (Extended Data Types)]

Эти типы состоят и данных базовых типов и составных типов данных, определенных в следующих подсекциях.

9.1.6.1. Строка октетов (Octet String). Тип данных OCTET_STRINGlength определен ниже; здесь length это длина строки октетов.

ARRAY [ length ] OF UNSIGNED8 OCTET_STRINGlength

9.1.6.2. Видимая строка (Visible String). Тип данных VISIBLE_STRINGlength определен ниже. Допустимые значения типа данных VISIBLE_CHAR: 0h и диапазон от 20h до 7Eh (7-битный код ASCII для видимых символов). Данные представлены по стандарту ISO 646-1973(E) как символы, кодируемые 7 битами. Здесь length это длина видимой строки.

UNSIGNED8                            VISIBLE_CHAR
ARRAY [ length ] OF VISIBLE_CHAR     VISIBLE_STRINGlength

Символ 0h необходим для завершения строки.

9.1.6.3. Строка Unicode (Unicode String). Тип данных UNICODE_STRINGlength определен ниже; здесь length это длина строки unicode.

ARRAY [ length ] OF UNSIGNED16 UNICODE_STRINGlength

9.1.6.4. Время дня (Time of Day). Тип данных TIME_OF_DAY представляет абсолютное время. Он следует правилам определения и кодирования TIME_OF_DAY таким образом, что представляется последовательностью бит длиной 48.

Компонент ms это время в миллисекундах после полуночи. Компонент days это количество дней, начиная от даты 1 января 1984 года.

STRUCT OF
   UNSIGNED28 ms,
   VOID4 reserved,
   UNSIGNED16 days
TIME_OF_DAY

9.1.6.5. Time Difference (разница по времени). Тип данных TIME_DIFFERENCE представляет разницу (интервал) во времени. Он следует правилам кодирования таким образом, что TIME_DIFFERENCE представлен последовательностью бит длиной 48.

Разницы времени это суммы количества дней и миллисекунд. Компонент ms это количество миллисекунд. Компонент days это количество дней.

STRUCT OF
   UNSIGNED28 ms,
   VOID4 reserved,
   UNSIGNED16 days
TIME_DIFFERENCE

Обратите внимание, что компонент VOID4 reserved применен для выравнивания полей бит по границе байта. Это сделано для удобства доступа к значениям данных, чтобы не нужно было делать лишние сдвиги и маскирования последовательностей бит.

9.1.6.6 Domain. Домены могут использоваться для передачи блока данных произвольного размера от клиента к серверу и наоборот. Содержимое блока данных специфично для приложения, что не относится к области рассмотрения этого документа.

[9.2. Объекты коммуникации (Communication Objects)]

Объекты коммуникации описываются службами и протоколами. Все службы описываются в табулярной форме, которая содержит параметры каждого примитива службы, который определен для этой службы. Примитивы, которые определены для определенной службы, определяют тип службы, например, неподтвержденный (unconfirmed), подтвержденный (confirmed), и т. д. Как интерпретировать табулярную форму и какие типы служб существуют, определено в 6.3 (Communication Model).

Все службы подразумевают, что отсутствуют ошибки на уровнях Data Link и Physical Layer сети CAN. Эти ошибки обрабатываются приложением, и как это происходит, выходит за рамки обсуждения в этом документе.

9.2.1. Process Data Object (PDO). Передача данных в реальном времени осуществляется способом "Process Data Objects (PDO)". Передача объектов PDO выполняется без дополнительной нагрузки на протокол.

Объекты PDO соответствуют записям в словаре объектов (Object Dictionary, OD) устройства, и они предоставляют интерфейс (доступ) к объектам приложения. Тип данных и отображение объектов приложения к объекту (объектам) PDO осуществляется с помощью соответствующей структуры отображения по умолчанию, также находящейся в OD. Если поддерживается изменяемое отображение PDO для некоторого количества объектов PDO, и отображение объектов приложения к PDO может передаваться во время процесса конфигурации устройства (см. раздел "Процедура инициализации"), с помощью наложения служб SDO на соответствующие записи OD.

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

Есть 2 вида использования для объектов PDO. Первый это передача данных и второй это прием данных. Эти виды определены в объектах Transmit-PDO (TPDO) и объектах Receive-PDO (RPDO). Устройства, поддерживающие объекты TPDO, называются продюсерами PDO, и устройства, у которых есть приемные PDO (RPDO) называются потребителями PDO. Объекты PDO описываются параметром коммуникации PDO (PDO communication parameter 20h) и параметром отображения PDO (PDO mapping parameter 21h). Структура этих типов данных объяснена в 9.5.4. PDO communication parameter описывает коммуникационные возможности PDO. PDO mapping parameter содержит информацию о содержимом объектов PDO (переменных устройства). Индексы соответствующих элементов словаря OD вычисляются по следующим формулам:

RPDO communication parameter index = 1400h + номер_RPDO - 1
TPDO communication parameter index = 1800h + номер_TPDO - 1
RPDO mapping parameter index = 1600h + номер_RPDO - 1
TPDO mapping parameter index = 1A00h + номер_TPDO - 1

Для каждого PDO обязательна пара параметров: параметр коммуникации и параметр отображения. Вышеупомянутые записи OD описаны в 9.5 (Object Dictionary).

9.2.1.1. Transmission Modes. Различают следующие режимы передачи PDO:

• Синхронная передача
• Асинхронная передача

Чтобы синхронизировать устройства друг с другом, приложением синхронизации периодически передается объект синхронизации (объект SYNC). Объект SYNC представлен заранее определенным объектом коммуникации (см. 9.2.3). На рис. 13 показан принцип синхронной и асинхронной передачи. Синхронные PDO передаются в пределах заранее определенного окна времени, немедленно после объекта SYNC. Принцип синхронной передачи описан более подробно в 9.3.

CiA301 Synchronous and Asynchronous Transmission fig13

Рис. 13. Синхронная и асинхронная передача объектов PDO.

Параметр типа передачи объекта PDO задает как режим передачи, так и триггерный режим (см. ниже 9.2.1.2).

TPDO. Для синхронных TPDO тип передачи также задается частотой следования передач в форме множителя интервала появления объекта SYNC. Тип передачи 0 означает, что сообщение должно быть передано после появления SYNC, но не периодически, только если перед появлением SYNC произошло необходимое для сообщения событие. Тип передачи 1 означает, что сообщение обязательно передается с каждым объектом SYNC. Тип передачи n означает, что сообщение передается каждое n-ое появление объекта SYNC. Асинхронные TPDO передаются без какой-либо взаимосвязи с SYNC.

RPDO. Данные синхронных RPDO принятые после поступления SYNC, передаются в приложение с наступлением следующего SYNC, независимо от частоты передачи, указанной типом передачи. Данные асинхронных RPDO передаются приложению непосредственно.

9.2.1.2. Триггерные режимы. Различают режимы срабатывания приложений:

По событию (Event Driven). Передача сообщения срабатывает при наступлении события, специфичного для объекта. Для синхронных PDO это будет истечение времени указанного периода передачи, синхронизированное по приему объекта SYNC.

Для не циклически передаваемых синхронный PDO и асинхронных PDO срабатывание передачи сообщения определяется зависящим от устройства событием, определяемым профилем устройства.

По таймеру (Timer Driven). Передача сообщения срабатывает либо по наступлению специфического для устройства события, ли если истекло указанное время, если событие не наступило.

По запросу другого узла (Remotely requested). Передача асинхронных PDO инициируется при приеме запроса remote (RTR), который был инициирован любым другим устройством (PDO consumer).

9.2.1.3. Службы PDO. Передачи PDO следуют взаимодействию producer/consumer, как это описано в 6.3.3.

Атрибуты:

- PDO number: номер PDO [1..512] для каждого пользовательского типа на локальном устройстве.
- user type: тип пользователя, одно из значений {consumer, producer}.
- data type: тип данных, в соответствии с отображением PDO.
- inhibit-time: время запрета n*100 мкс, n ≥ 0

9.2.1.3.1. Write PDO. Для службы Write PDO (запись PDO) допустима модель push. Может быть 0 или большее количество потребителей (consumers) объекта PDO. У PDO всегда только один генератор (producer).

Через эту службу продюсер PDO отправляет данные отображенных объектов приложения к потребителю (потребителям) этих данных.

Таблица 3. Write PDO.

Параметр Запрос/индикация
Argument
   Номер PDO
   Данные
Наличие обязательно
   Наличие обязательно
   Наличие обязательно

9.2.1.3.2. Read PDO. Для службы Read PDO (чтение PDO) допустима модель pull. Может быть один или большее количество потребителей (consumers) объекта PDO. У PDO всегда только один генератор (producer).

Через эту службу потребитель PDO запрашивает у продюсера предоставить данные, отображенные на объекты приложения. Эта служба работает как подтверждаемая (confirmed). Параметр remote result подтвердит значение.

Таблица 4. Read PDO.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер PDO

Remote Result
   Данные
Наличие обязательно
   Наличие обязательно






Наличие обязательно

   Наличие обязательно

9.2.1.4. Протокол PDO.

Служба для запроса записи PDO является не подтверждаемой (unconfirmed). Продюсер PDO посылает данные процесса (process data) по сети в рамках PDO. Может быть 0..n потребителей PDO (consumers). На потребителе (потребителях) PDO будет показан прием допустимого PDO. На рис. 14 показан протокол Write PDO.

CiA301 Write PDO Protocol fig14

Рис. 14: Протокол Write PDO.

Process-Data: может быть до L байт данных приложения, в соответствии с отображением PDO. Если L превысит количество байт 'n', определенное реальной длиной отображения PDO, то только первые n байт будут использованы потребителем. Если L меньше n, то данные, принятые PDO, не обрабатываются, и будет выпущено сообщение аварии (Emergency message) с кодом ошибки 8210h, если поддерживается функционал Emergency.

Служба запроса чтения PDO является подтверждаемой (confirmed). Один или большее количество потребителей PDO передают фрейм remote (RTR) по сети. На приеме фрейма RTR продюсер PDO для запрашиваемого PDO передает этот PDO. Для всех потребителей PDO для этого PDO будет показан прием. Может быть 0..n потребителей PDO. Служба чтения является опциональной, и зависит от возможностей аппаратуры. Рис. 15 показывает протокол чтения PDO.

CiA301 Read PDO Protocol fig15

Рис. 15: Протокол Read PDO.

Process-Data: может быть до L байт данных приложения, в соответствии с отображением PDO. Если L превысит количество байт 'n', определенное реальной длиной отображения PDO, то только первые n байт будут использованы потребителем. Если L меньше n, то данные, принятые PDO, не обрабатываются, и будет выпущено сообщение аварии (Emergency message) с кодом ошибки 8210h, если поддерживается функционал Emergency.

С помощью сервисных объектов данных (SDO) предоставляется запись в OD устройства. Так как эти данные могут содержать данные произвольного размера, и тип данных SDO может быть использован для передачи нескольких наборов данных (каждый из которых может содержать произвольно большой блок данных) от клиента к серверу, и наоборот. Клиент может управлять через мультиплексор (индекс и sub-индекс словаря OD), какой набор данных должен передаваться. Содержимое набора данных определяется в OD.

Обычно SDO передается как последовательность сегментов. Перед передачей сегментов присутствует фаза инициализации, где клиент и сервер подготавливают самих себя к передаче сегментов. Для SDO также можно передавать набор данных до 4 байт включительно сразу на фазе инициализации. Этот механизм называется ускоренной передачей (expedited transfer).

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

Возможна выгрузка блока SDO (SDO Block Upload), с которой размер набора данных не выровнен по передаче блока, потому что подразумевается дополнительная нагрузка на протокол. В этих случаях на фазе инициализации может быть реализована поддержка отступа для сегментированной или ускоренной передачи. Поскольку предположение о минимальном размере набора данных, для которого блочная передача выигрывает по сравнению с другими типами передачи, зависит от различных параметров, клиент на фазе инициализации показывает это пороговое значение в байтах для сервера. Для блочной передачи используется схема Go-Back-n ARQ (Automatic Repeat Request, автоматический запрос повтора) для подтверждения каждого блока.

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

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

Для всех типов передач инициатива передачи находится на стороне клиента. Владельцем OD, к которому осуществляется доступ, является сервер SDO. Обе стороны - и клиент, и сервер могут взять инициативу по обрыву передачи SDO (abort).

С помощью SDO между устройствами устанавливается канал связи точка-точка (peer-to-peer). Устройство может поддерживать больше чем один объект SDO. В случае по умолчанию поддерживается один Server-SDO (SSDO), так называемый SDO по умолчанию (Default SDO).

Объекты SDO описываются записью параметра коммуникации SDO (SDO communication parameter record, 22h). Структура этого типа данных объясняется в 9.5.4. SDO communication parameter описывает возможности коммуникации для объектов Server-SDO и Client-SDOs (CSDO). Индексы соответствующих записей OD вычисляются по следующим формулам:

• SSDO communication parameter index = 1200h + номер_SSDO - 1
• CSDO communication parameter index = 1280h + номер_CSDO - 1

Для каждого SDO являются обязательными параметры коммуникации. Если существует только один SSDO, то параметры коммуникации могут быть опущены. Вышеописанные записи описаны в 9.5 (Object Dictionary).

9.2.2.1. Службы SDO. Для коммуникации SDO применяется модель клиент/сервер.

Атрибуты:

- SDO number: номер SDO [1..128] для каждого пользовательского типа локального устройства.
- user type: один из типов {client, server}.
- mux мультиплексор типа данных, содержащий индекс и sub-индекс типа: STRUCTURE OF UNSIGNED (16), UNSIGNED (8), с индексом, указывающим на запись в OD устройства, и sub-индексом, указывающим на компонент записи OD.
- transfer type: зависит от длины данных для передачи: expedited (ускоренная передача) для количества данных до 4 байт, и segmented (сегментированная) или block (блочная) для количества байт данных больше 4.
- data type: тип данных в соответствии со ссылающимся индексом и sub-индексом.

Следующие службы могут быть применены к SDO, в зависимости от требований приложения:

• SDO Download, что может быть разделено на
   - Initiate SDO Download (инициация загрузки SDO)
   - Download SDO Segment (загрузка сегмента SDO)
• SDO Upload, что может быть разделено на
   - Initiate SDO Upload (инициация выгрузки SDO)
   - Upload SDO Segment (выгрузка сегмента SDO)
• Abort SDO Transfer (обрыв передачи SDO)

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

Должна поддерживаться ускоренная передача (expedited transfer). Должна поддерживаться сегментированная передача, если поддерживаются объекты размером больше 4 байт. Опционально могут быть реализованы следующие службы SDO для выполнения блочной передачи с более рациональным использованием полосы шины для больших наборов данных:

• SDO Block Download (блочная загрузка SDO), что может быть разделено на
   - Initiate Block Download (инициация загрузки блока)
   - Download Block (загрузка блока)
   - End Block Download (окончание загрузки блока)
• SDO Block Upload (блочная выгрузка SDO), что может быть разделено на
   - Initiate Block Upload (инициация выгрузки блока)
   - Upload Block (выгрузка блока)
   - End Block Upload (окончание выгрузки блока)

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

В протоколе SDO Block Upload может быть реализована поддержка для переключения в протокол SDO Upload в 'Initiate SDO Block Upload', чтобы увеличить эффективность передачи для данных, размер которых не выравнивает использование нагрузки на протокол для протокола 'SDO Block Upload'.

Для обрыва блочной передачи SDO используется служба Abort SDO Transfer.

9.2.2.1.1. SDO Download. С помощью этой службы клиент SDO загружает данные на сервер (владелец OD). Для сервера показываются данные, мультиплексор (индекс и sub-индекс) набора данных, который загружается, и его размер (опционально только для сегментированной передачи).

Эта служба является подтверждаемой (confirmed). Параметр remote result будет показывать успех или ошибку запроса. В случае ошибки опционально подтверждается причина отказа.

Загрузка SDO состоит как минимум из службы Initiate SDO Download, и опционально службы Download SDO Segment (при длине данных > 4 байт).

Таблица 5. SDO Download.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
   Data
   Size
   Multiplexor

Remote Result
   Success
   Failure (ошибка)
      Причина ошибки
Наличие обязательно
   Обязательно
   Обязательно
   Не обязательно
   Обязательно

   









Наличие обязательно

   Выбор
   Выбор
      Не обязательно

9.2.2.1.2 Initiate SDO Download. Через эту службу клиент SDO запрашивает у сервера загрузку данных на сервер. Опционально серверу показывается размер данных для загрузки.

Серверу показывается мультиплексор набора данных, для которого инициируется загрузка, и тип передачи. В случает ускоренной загрузки (expedited download), данные набора идентифицируются по мультиплексору и размеру, которые показываются серверу.

Таблица 6. Initiate SDO Download.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
   Size
   Multiplexor
      Тип передачи
         Нормальная
         Ускоренная
            Данные

Remote Result
   Success
Наличие обязательно
   Обязательно
   Не обязательно
      Обязательно
      Обязательно
         Выбор
         Выбор
            Обязательно












Наличие обязательно

      Обязательно

Эта служба подтверждаемая (confirmed). Параметр remote result покажет успешность запроса. Случае отказа должен быть выполнен запрос Abort SDO Transfer. В случае успеха ускоренной (expedited) загрузки мультиплексированного DOMAIN, эта служба завершает загрузку набора данных, идентифицированного мультиплексором.

9.2.2.1.3. Download SDO Segment. Через эту службу клиент SDO предоставляет серверу данные следующего сегмента. Серверу показывается сегмент данных и опционально его размер. Параметр продолжения (continue parameter) показывает, будут ли еще загружены сегменты, или это был последний загруженный сегмент.

Таблица 7. Download SDO Segment.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
   Data
   Size
   Continue
      Есть еще сегменты
      Последний сегмент

Remote Result
   Success
Наличие обязательно
   Обязательно
   Обязательно
   Не обязательно
   Обязательно
      Выбор
      Выбор











Наличие обязательно

      Обязательно

Эта служба подтверждаемая (confirmed). Параметр remote result покажет успешность запроса. Случае отказа должен быть выполнен запрос Abort SDO Transfer. В случае успеха сервер принимает сегмент данных и готов принять следующий сегмент. Может быть самое большее одна служба Download SDO Segment, предназначенная для передачи SDO.

Перед этой службой должна быть успешно выполнена служба Initiate SDO Download с типом сегментированной передачи.

9.2.2.1.4. SDO Upload. Через эту службу клиент SDO выгружает данные из сервера. Серверу должен быть показан мультиплексор (индекс и sub-индекс) набора данных.

SDO upload состоит как минимум из службы Initiate SDO Upload и опционально из службы Upload SDO Segment (когда длина данных > 4 байт).

Таблица 8. SDO Upload.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
   Continue
   Multiplexor

Remote Result
   Success
      Data
      Size
   Failure (ошибка)
      Причина ошибки
Наличие обязательно
   Обязательно
   Обязательно













Наличие обязательно

   Выбор
      Обязательно
      Не обязательно
   Выбор
      Не обязательно

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

9.2.2.1.5. Initiate SDO Upload. Через эту службу клиент SDO запрашивает у сервера подготовиться к выгрузке данных для клиента. Серверу показывается мультиплексор (индекс и sub-индекс) набора данных, выгрузка которых инициируется.

Эта служба подтверждаемая (confirmed). Параметр remote result покажет успешность запроса. Случае отказа должен быть выполнен запрос Abort SDO Transfer. В случае успеха (опционально для сегментированной передачи) подтверждается размер выгруженных данных. В случае успешной ускоренной (expedited) выгрузки эта служба завершает выгрузку набора данных, обозначенных мультиплексором, и соответствующие данные подтверждаются.

Таблица 9. Initiate SDO Upload.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
   Multiplexor

Remote Result
   Success
      Size
         Multiplexor
         Тип передачи
            Обычный
            Ускоренный
               Data
Наличие обязательно
   Обязательно
   Обязательно













Наличие обязательно

   Обязательно
      Не обязательно
         Обязательно
         Обязательно
            Выбор
            Выбор
               Обязательно

9.2.2.1.6. Upload SDO Segment. Через эту службу клиент SDO запрашивает сервер предоставить данные следующего сегмента. Параметром продолжения (continue parameter) клиент показывает, должны ли быть еще выгружены данные, или это был последний выгруженный сегмент. Может быть самое большее одна служба Upload SDO Segment, предоставленная для SDO.

Эта служба подтверждаемая (confirmed). Параметр remote result покажет успешность запроса. Случае отказа должен быть выполнен запрос Abort SDO Transfer. В случае успеха подтверждается сегмент данных и опционально подтверждается его размер.

Перед этой службой должна успешно выполниться служба Initiate SDO Upload с типом сегментированной передачи.

Таблица 10. Upload SDO Segment.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO

Remote Result
   Success
      Data
      Size
      Продолжить
         Есть еще сегменты
         Последний сегмент
Наличие обязательно
   Обязательно
   Обязательно










Наличие обязательно

   Обязательно
      Обязательно
      Не обязательно
      Обязательно
         Выбор
         Выбор

9.2.2.1.7. Abort SDO Transfer. Эта служба обрывает выгрузку или загрузку SDO, выбранную ссылкой на её номер. Опционально показывается причина обрыва. Эта служба является не подтверждаемой (unconfirmed). Служба может быть выполнена в любой момент времени обеими сторонами обмена, и клиентом, и сервером SDO. Если у клиента есть не не выполненная, подтвержденная служба SDO, для подтверждения этой службы показывается abort.

Таблица 11. Abort SDO Transfer.

Параметр Запрос/индикация
Argument
   Номер SDO
   Multiplexor
   Причина
Наличие обязательно
   Обязательно
   Обязательно
   Обязательно

9.2.2.1.8. SDO Block Download. Через эту службу клиент SDO загружает данные на сервер SDO (владелец OD), используя протокол блочной передачи. Серверу показываются данные, мультиплексор (индекс и sub-индекс) набора данных, который загружается, и опционально их размер.

Эта служба подтверждаемая (confirmed). Параметр remote result покажет успешность или отказ запроса. В случае отказа опционально подтверждается причина ошибки.

Таблица 12. SDO Block Download.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
   Data
   Size
      Multiplexor

Remote Result
   Success
   Failure
      Причина ошибки
Наличие обязательно
   Обязательно
   Обязательно
   Не обязательно
      Обязательно











Наличие обязательно

   Выбор
   Выбор
      Не обязательно

9.2.2.1.9. Initiate SDO Block Download. Через эту службу клиент SDO запрашивает сервер SDO (владельца OD) подготовиться к загрузке данных на сервер. Серверу показывается мультиплексор набора данных, для которых выполняется инициация, и опционально размер загружаемых данных в байтах.

Клиент, как и сервер, показывают свою возможность и/или требование проверить целостность передачи с помощью контрольной суммы в момент окончания загрузки блока (End SDO Block Download).

Таблица 13. Initiate SDO Block Download.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
   Size
   Поддержка CRC
      да
      нет
   Multiplexor

Remote Result
   Success
   Поддержка CRC
      да
      нет
   Размер блока
Наличие обязательно
   Обязательно
   Не обязательно
   Обязательно
      Выбор
      Выбор
   Обязательно















Наличие обязательно

   Обязательно
   Обязательно
      Выбор
      Выбор
   Обязательно

Эта служба подтверждаемая (confirmed). Параметр Remote Result покажет успешность запроса, количество сегментов в блоке, которое сервер SDO в состоянии принять, и свою возможность и/или требование проверить целостность данных с помощью контрольной суммы. В случае отказа должен быть выполнен запрос Abort SDO Transfer.

9.2.2.1.10. Download SDO Block. С помощью этой службы клиент SDO предоставляет данные следующего блока для сервера SDO. Для сервера показываются данные блока с помощью последовательности сегментов. Каждый сегмент состоит из данных и последовательного номера, начиная с 1, который увеличивается на 1 с каждым сегментом, вплоть до blksize. Параметр blksize оговаривается между сервером и клиентом в протоколе 'Initiate Block Download', и он может быть изменен сервером на каждом подтверждении передачи блока. Параметр продолжения (continue parameter) показывает, должен ли сервер оставаться на фазе 'Download Block', или должен перейти к фазе 'End Download Block'.

Таблица 14. Download SDO Block.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
   Data
   Продолжить
      Есть еще сегменты
      Последний сегмент

Remote Result
   Success
      Ackseq
      Размер блока
Наличие обязательно
   Обязательно
   Обязательно
   Обязательно
      Выбор
      Выбор












Наличие обязательно

   Обязательно
      Обязательно
      Обязательно

Эта служба подтверждаемая (confirmed). Параметр Remote Result покажет успешность запроса. В случае успеха параметр ackseq покажет последовательный номер последнего сегмента, который успешно принял сервер. Если этот номер не соответствует последовательному номеру последнего сегмента, отправленного клиентом во время передачи этого блока, то клиент должен повторно передать все сегменты, отброшенные сервером в момент передачи следующего блока. В случае фатального отказа, должен быть выполнен запрос Abort SDO Transfer. В случае успеха сервер должен подтвердить все принятые данные сегментов и быть готовым к поступлению следующего блока. Для передачи SDO может быть самое большее одна служба Download SDO Block.

Перед этой службой должна быть успешно выполнена служба 'Initiate SDO Block Download'.

9.2.2.1.11. End SDO Block Download. Через эту службу завершается загрузка блока SDO (SDO Block Download). Серверу показывается количество байт, не содержащих допустимые данные в последних переданных сегментах.

Если сервер, как и клиент, показал свою возможность (или запросил её) проверки целостности данных контрольной суммой на фазе 'Initiate SDO Block Download' то клиент показывает серверу эту контрольную сумму. Сервер также должен сгенерировать контрольную сумму для сравнения с контрольной суммой, сгенерированной клиентом.

Таблица 15. End SDO Block Download.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
   Valid_data
   CRC

Remote Result
   Success
Наличие обязательно
   Обязательно
   Обязательно
   Обязательно, если объявлена поддержка








Наличие обязательно

   Обязательно

Эта служба подтверждаемая (confirmed). Параметр Remote Result покажет успешность запроса (с совпадением контрольных сумм, если о её проверке договорились клиент и сервер), и загрузка набора данных завершается. В случае отказа должен быть выполнен запрос Abort SDO Transfer.

9.2.2.1.12. SDO Block Upload. Через эту службу клиент SDO выгружает данные с сервера SDO (владельца OD) с помощью протокола выгрузки блока SDO (SDO block upload). Серверу показываются данные, мультиплексор (индекс и sub-индекс) набора данных, которые выгружаются на сервер, и опционально серверу показывается их размер.

Эта служба подтверждаемая (confirmed). Параметр Remote Result покажет успешность или отказ запроса. В случае отказа опционально подтверждается причина ошибки. В случае успеха подтверждаются данные и опционально их размер.

Таблица 16. SDO Block Upload.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
      Multiplexor

Remote Result
   Success
      Data
      Size
   Failure (ошибка)
      Причина ошибки
Наличие обязательно
   Обязательно
      Обязательно











Наличие обязательно

   Выбор
      Обязательно
      Не обязательно
   Выбор
      Не обязательно

9.2.2.1.13. Initiate SDO Block Upload. Через эту службу клиент SDO запрашивает сервер SDO (владелец OD) подготовиться к выгрузке данных для клиента. Серверу показывается мультиплексор данных, для которых инициируется выгрузка, и количество сегментов, которое клиент SDO может принять.

Серверу показывается значение порога переключения протокола (protocol switch threshold). Если количество байт, которое должно быть выгружено, меньше или равно этому значению, то сервер может опционально завершить эту передачу данных c 'SDO Upload Protocol', как это описано в 9.2.2.1.4.

Клиент, как и сервер, показывает свою возможность и/или запрашивает необходимость проверки целостности данных с помощью контрольной суммы на фазе 'End SDO Block Upload'.

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

Таблица 17. Initiate SDO Block Upload.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
   Blksize
   Поддержка CRC
      да
      нет
   Multiplexor
   Порог

Remote Result
   Success
      Поддержка CRC
         да
         нет
      Size
Наличие обязательно
   Обязательно
   Обязательно
   Обязательно
      Выбор
      Выбор
   Обязательно
   Обязательно
















Наличие обязательно

   Обязательно
      Обязательно
         Выбор
         Выбор
      Не обязательно

Эта служба подтверждаемая (confirmed). В случае отказа должен быть выполнен запрос Abort SDO Transfer. В случае успеха клиенту опционально показывается размер выгруженных данных в байтах. Если размер данных, которые выгружаются, меньше или равно порогу, то сервер может продолжить работу по протоколу SDO block upload. В этом случае параметр Remote Result и будущий протокол работают в соответствии с описанием в 9.2.2.2.14.

9.2.2.1.14. Upload SDO Block. Через эту службу клиент SDO выгружает данные следующего блока с сервера SDO. Клиенту показывается блок данных с помощью следующих друг за другом сегментов. Каждый сегмент состоит из данных сегмента и последовательного номера, начинающегося с 1, и увеличивающегося на 1 с каждым сегментом, вплоть до blksize. Параметр blksize оговаривается между сервером и клиентом в протоколе 'Initiate Block Upload', и он может быть изменен клиентом с каждым подтверждением передачи блока. Параметр continue показывает клиенту, должен ли он оставаться на фазе 'Upload Block', или следует перейти к фазе 'End Upload Block'.

Таблица 18. Upload SDO Block.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
   Data
   Продолжить
      Есть еще сегменты
      Последний сегмент

Remote Result
   Success
      Ackseq
      Blksize
Наличие обязательно
   Обязательно
   Обязательно
   Обязательно
      Выбор
      Выбор












Наличие обязательно

   Обязательно
      Обязательно
      Обязательно

Эта служба подтверждаемая (confirmed). Параметр Remote Result покажет успешность запроса. В случае успеха параметр ackseq покажет последовательный номер последнего сегмента, который успешно принял клиент. Если этот номер не соответствует последовательному номеру последнего сегмента, отправленного сервером во время передачи этого блока, то сервер должен повторно передать все сегменты, отброшенные клиентом в момент передачи следующего блока. В случае фатального отказа должен быть выполнен запрос Abort SDO Transfer. В случае успеха клиент должен подтвердить все принятые данные сегментов, и быть готовым к поступлению следующего блока. Для передачи SDO может быть самое большее одна служба Download SDO Block.

Перед этой службой должна быть успешно выполнена служба 'Initiate SDO Block Upload'.

9.2.2.1.15. End SDO Block Upload. Через эту службу завершается выгрузка блока (SDO Block Upload). Клиенту показывается количество байт, не содержащих допустимые данные в последних переданных сегментах.

Если сервер, как и клиент, показал свою возможность (или запросил её) проверки целостности данных контрольной суммой на фазе 'Initiate SDO Block Upload' то сервер показывает клиенту эту контрольную сумму. Клиент также должен сгенерировать эту контрольную сумму для сравнения с контрольной суммой, сгенерированной сервером.

Таблица 19. End SDO Block Upload.

Параметр Запрос/индикация Ответ/подтверждение
Argument
   Номер SDO
   Valid_data
   CRC

Remote Result
   Success
Наличие обязательно
   Обязательно
   Обязательно
   Обязательно, если объявлена поддержка








Наличие обязательно

   Обязательно

Эта служба подтверждаемая (confirmed). Параметр Remote Result покажет успешность запроса (с совпадением контрольных сумм клиента и сервера, если это запрашивалось), и загрузка набора данных завершается. В случае отказа должен быть выполнен запрос Abort SDO Transfer.

9.2.2.2. Протоколы SDO. Для SDO определены 6 подтверждаемых служб (SDO Download, SDO Upload, Initiate SDO Upload, Initiate SDO Download, Download SDO Segment и Upload SDO Segment), и одна не подтверждаемая служба (Abort SDO Transfer), которые осуществляют стандартную сегментированную/ускоренную (standard segmented/expedited) передачу. 8 подтверждаемых служб определены для SDO (SDO Block Download, SDO Block Upload, Initiate SDO Upload, Initiate SDO Block Download, Download SDO Segment, Upload SDO Segment, End SDO Upload и End SDO Block Download) и одна не подтверждаемая служба, которые осуществляют опциональную блочную передачу.

CiA301 Download SDO Protocol fig16

Рис. 16. Протокол Download SDO.

Этот протокол используется для реализации службы SDO Download. Объекты SDO загружаются как последовательность 0 или большего количества служб Download SDO Segment, перед которым была служба Initiate SDO Download. Эта последовательность завершается через:

• Запросом/индикацией Initiate SDO Download с e-битом, установленным 1, за которым идет ответ/подтверждение Initiate SDO Download, показывающее успешное завершение ускоренной (expedited) последовательности загрузки.
• Запросом/подтверждением Download SDO Segment с c-битом, установленным в 1, показывающим успешное завершение обычной (не ускоренной) последовательности загрузки.
• Запросом/индикацией Abort SDO Transfer, показывающим не успешное завершение последовательности загрузки.
• Новым запросом/индикацией Initiate Domain Download, показывающим завершение по ошибке последовательности загрузки и запуск новой последовательности загрузки.

Если при загрузке следующих друг за другом сегментов бит toggle не изменился, то содержимое последнего сегмента игнорируется. Если о такой ошибке сообщено приложению, то приложение может принять решение оборвать загрузку (abort).

Этот протокол используется при реализации службы Initiate SDO Download для объектов SDO.

CiA301 Initiate SDO Download Protocol fig17

Рис. 17. Протокол Initiate SDO Download.

• ccs: client command specifier (команда клиента)
1: initiate download request (инициировать запрос загрузки)

• scs: server command specifier (команда сервера)
3: initiate download response (инициировать ответ на загрузку)

• n: допустимо только если e = 1 и s = 1, иначе 0. Если допустимо, то это показывает количество байт в d, которое не содержит данных. Байты [8-n, 7] не содержат данных.

• e: тип передачи
0: normal transfer (нормальная передача)
1: expedited transfer (ускоренная передача)

• s: индикатор размера
0: размер набора данных не показан
1: указан размер набора данных

• m: multiplexor. Он представляет индекс/sub-индекс данных для передачи объектом SDO.

• d: data (данные)
e = 0, s = 0: d зарезервирован для будущего использования.
e = 0, s = 1: d содержит количество байт для загрузки. Байт 4 содержит младшие биты, и байт 7 содержит старшие биты.
e = 1, s = 1: d содержит данные для загрузки, длина которых равна 4-n. Кодирование данных зависит от типа данных. К данным ссылаются по индексу и sub-индексу.
e = 1, s = 0: d содержит не указанное количество байт для загрузки.

• X: не используется, всегда 0.

• reserved: зарезервировано для будущего использования, всегда 0.

Этот протокол используется для реализации службы Download SDO Segment (загрузка сегмента SDO).

CiA301 Download SDO Segment Protocol fig18

Рис. 18. Протокол Download SDO Segment.

• ccs: client command specifier (команда клиента)
0: download segment request (запрос на загрузку сегмента)

• scs: server command specifier (команда сервера)
1: download segment response (ответ на загрузку сегмента)

• seg-data: здесь могут быть максимум 7 байт данных сегмента для загрузки. Кодирование этих байт зависит от данных, которые были запрошены индексом и sub-индексом.

• n: показывает количество байт в seg-data, которые не содержат данных сегмента. Байты [8-n, 7] не содержат данных сегмента. n = 0, если не показан размер сегмента.

• c: показывает, должны ли быть ещё сегменты для загрузки.
0: будут еще сегменты для загрузки
1: больше не будет сегментов для загрузки

• t: бит toggle. Этот бит должен переключаться с каждым последующим загружаемым сегментом. В первом сегменте бит toggle устанавливается в 0. Бит toggle будет совпадать для сообщения запроса и для сообщения ответа.

• X: не используется, здесь всегда 0.

• reserved: зарезервировано для будущего использования, всегда 0.

CiA301 Upload SDO Protocol fig19

Рис. 19. Протокол Upload SDO.

Этот протокол используется для реализации службы SDO Upload (выгрузка SDO). SDO выгружается как последовательность 0 или большего количества служб Upload SDO Segment, перед которыми предшествовала служба Initiate SDO Upload. Последовательность выгрузки прерывается следующим:

• Ответ/подтверждение на Initiate SDO Upload, где бит e установлен в 1, что показывает успешное завершение ускоренной (expedited) последовательности выгрузки.
• Ответ/подтверждение на Upload SDO Segment, где бит c установлен в 1, показывая тем самым успешное завершение обычной (не ускоренной) последовательности выгрузки.
• Запрос/индикация Abort SDO Transfer, что показывает не успешное завершение последовательности выгрузки.
• Новый запрос/индикация Initiate SDO Upload, что показывает не успешное завершение текущей последовательности выгрузки и запуск новой последовательности.

Если при выгрузке следующих друг за другом сегментов бит toggle не поменялся, то содержимое последнего сегмента игнорируется. Если такая ошибка сообщена приложению, то приложение может принять решение прервать (abort) выгрузку.

Этот протокол используется для реализации службы Initiate SDO Upload (инициировать выгрузку SDO).

CiA301 Initiate SDO Upload Protocol fig20

Рис. 20: Протокол Initiate SDO Upload.

• ccs: client command specifier (команда клиента)
2: initiate upload request (запрос инициации выгрузки)

• scs: server command specifier (команда сервера)
2: initiate upload response (ответ на команду инициировать выгрузку)

• n: допустимо только если e = 1 и s = 1, иначе 0. Если допустимо, то показывает количество байт, которое не содержит данные. Байты [8-n, 7] не содержат данные сегмента.

• e: тип передачи
0: normal transfer (обычная передача)
1: expedited transfer (ускоренная передача)

• s: индикатор размера
0: размер набора данных не показан
1: показан размер набора данных

• m: multiplexor. Он представляет индекс / sub-индекс данных для передачи объектом SDO.

• d: data (данные)
e = 0, s = 0: d зарезервировано для использования в будущем.
e = 0, s = 1: d содержит количество байт для выгрузки. Байт 4 содержит младшие биты, и байт 7 старшие биты.
e = 1, s = 1: d содержит длину данных 4-n для выгрузки кодирование зависит от типа данных, к которым было обращение по индексу и sub-индексу.
e = 1, s = 0: d содержит не указанное количество байт для выгрузки.

• X: не используется, здесь всегда 0.

• reserved: зарезервировано для будущего использования, всегда 0.

Этот протокол используется для реализации службы Upload SDO Segment (выгрузка сегмента SDO).

CiA301 Upload SDO Segment Protocol fig21

Рис. 21: Протокол Upload SDO Segment.

• ccs: client command specifier (команда клиента)
3: download segment request (запрос на выгрузку сегмента)

• scs: server command specifier (команда сервера)
3: download segment response (ответ на выгрузку сегмента)

• t: бит toggle. Этот бит должен переключаться с каждым последующим выгружаемым сегментом. В первом сегменте бит toggle устанавливается в 0. Бит toggle будет совпадать для сообщения запроса и для сообщения ответа.

• c: показывает, должны ли быть ещё сегменты для выгрузки.
0: будут еще сегменты для выгрузки
1: больше не будет сегментов для выгрузки

• seg-data: здесь могут быть максимум 7 байт данных сегмента для выгрузки. Кодирование этих байт зависит от данных, которые были запрошены индексом и sub-индексом.

• n: показывает количество байт в seg-data, которые не содержат данных сегмента. Байты [8-n, 7] не содержат данных сегмента. n = 0, если не показан размер сегмента.

• X: не используется, здесь всегда 0.

• reserved: зарезервировано для будущего использования, всегда 0.

Этот протокол используется для реализации службы Abort SDO Transfer (обрыв передачи SDO).

CiA301 Abort SDO Transfer Protocol fig22

Рис. 22. Протокол Abort SDO Transfer.

• cs: спецификатор команды
4: abort transfer request (оборвать запрос передачи)

• X: не используется, всегда 0

• m: multiplexor. Он представляет индекс и sub-индекс SDO.

• d: содержит 4 байта кода обрыва (abort code), которые сообщают о причине.

Код abort закодирован как значение UNSIGNED32.

Таблица 20. Коды SDO abort.

Abort code Описание
0503 0000h Бит toggle не переключился.
0504 0000h Таймаут протокола SDO.
0504 0001h Спецификатор команды клиента/сервера не допустим или не известен.
0504 0002h Недопустимый размер блока (только для блочного режима).
0504 0003h Недопустимый номер последовательности (только для блочного режима).
0504 0004h Ошибка CRC (только для блочного режима).
0504 0005h Недостаточно памяти.
0601 0000h Не поддерживаемый доступ к объекту.
0601 0001h Попытка чтения объекта, предназначенного только для записи.
0601 0002h Попытка записи объекта, предназначенного только для чтения.
0602 0000h Объект не существует в OD.
0604 0041h Объект не может быть отображен на PDO.
0604 0042h Количество и длина объектов для отображения превысила бы длину PDO.
0604 0043h Общая причина несовместимости параметра.
0604 0047h Общая внутренняя несовместимость в устройстве.
0606 0000h Доступ неудачен из-за аппаратной ошибки.
0607 0010h Не соответствует тип данных, не соответствует параметр длины службы.
0607 0012h Не соответствует тип данных, длина параметра службы слишком велика.
0607 0013h Не соответствует тип данных, длина параметра службы слишком мала.
0609 0011h Sub-индекс не существует.
0609 0030h Превышен диапазон параметра (только для доступа на запись).
0609 0031h Значение параметра слишком велико.
0609 0032h Значение параметра слишком мало.
0609 0036h Максимальное значение меньше, чем минимальное.
0800 0000h Общая ошибка.
0800 0020h Данные не могут быть переданы или сохранены в приложении.
0800 0021h Данные не могут быть переданы или сохранены в приложении из-за локального управления.
0800 0022h Данные не могут быть переданы или сохранены в приложении из-за текущего состояния устройства.
0800 0023h Динамическая генерация OD потерпела неудачу, или OD не существует (например, OD генерируется из файла, и генерация сорвалась из-за ошибки файла).

Не перечисленные коды abort зарезервированы.

CiA301 SDO Block Download Protocol fig23

Рис. 23. Протокол SDO Block Download.

Этот протокол используется для реализации службы SDO Block Download. Объекты SDO загружаются как последовательность служб Download SDO Block, перед которой запускается служба Initiate SDO Block Download. Последовательность SDO Download Block завершается:

• загруженным сегментом, где c-бит установлен в 1, показывая этим завершение последовательности загрузки блока, или

• запросом/индикацией Abort SDO Transfer, показывающими не успешное завершение последовательности загрузки.

Вся служба SDO Block Download завершается службой End SDO Block Download. Если клиент, как и сервер, показал возможность генерировать CRC во время службы Initiate SDO Block Download, то сервер сгенерировал CRC на принятых данных. Если эта CRC отличается от CRC, которую сгенерировал клиент, то сервер покажет это индикацией Abort SDO Transfer.

Этот протокол используется для реализации службы Initiate SDO Block Download.

CiA301 Initiate SDO Block Download Protocol fig24

Рис. 24. Протокол Initiate SDO Block Download.

• ccs: спецификатор команды клиента
6: загрузка блока

• scs: спецификатор команды сервера
5: загрузка блока

• s: индикатор размера
0: размер набора данных не показан
1: указан размер набора данных

• cs: sub-команда клиента
0: initiate download request (запрос на инициацию загрузки)

• ss: sub-команда сервера
0: initiate download response (ответ на инициацию загрузки)

• cc: поддержка CRC клиентом
cc = 0: клиент не поддерживает генерацию CRC по данным
cc = 1: клиент поддерживает генерацию CRC по данным

• sc: поддержка CRC сервером
sc = 0: сервер не поддерживает генерацию CRC по данным
sc = 1: сервер поддерживает генерацию CRC по данным

• m: multiplexor. Он представляет индекс/sub-индекс данных для передачи объектом SDO.

• size: загружаемый размер в байтах
s = 0: size резервируется для использования в будущем, всегда 0
s = 1: size содержит количество байт для загрузки. Байт 4 содержит младший байт, и байт 7 старший байт.

• blksize: количество сегментов на блок, 0 < blksize < 128.

• X: не используется, всегда 0

• reserved: резервировано для использования в будущем, всегда 0

Этот протокол используется для реализации службы Block Download (загрузка блока).

CiA301 Download SDO Block Segment fig25

Рис. 25. Протокол Download SDO Block Segment.

• scs: server command specifier (команда сервера)
5: block download (загрузка блока)

• ss: server subcommand (sub-команда сервера)
2: block download response (ответ на загрузку блока)

• c: показывает, есть ли еще сегменты для загрузки
0: есть еще сегменты для загрузки
1: больше нет сегментов для загрузки, вход в фазу загрузки End SDO block download (окончание загрузки блока)

• seqno: последовательный номер сегмента, 0 < seqno < 128.

• seg-data: как минимум 7 байт данных загружаемого сегмента.

• ackseq: последовательный номер последнего сегмента, который был принят во время последней загрузки блока. Если ackseq установлен в 0, то сервер показывает клиенту, что сегмент с последовательным номером 1 не был корректно принят, и все сегменты должны быть повторно переданы клиентом.

• blksize: количество сегментов на блок, которое должен использовать клиент при последующей загрузке блока, 0 < blksize < 128.

• X: не используется, всегда 0

• reserved: резервировано для использования в будущем, всегда 0

Этот протокол используется для реализации службы End SDO Block Download.

CiA301 End SDO Block Download Protocol fig26

Рис. 26. Протокол End SDO Block Download.

• ccs: client command specifier (команда клиента)
6: загрузка блока

• scs: server command specifier (команда сервера)
5: загрузка блока

• cs: client subcommand (sub-команда клиента)
1: запрос окончания загрузки блока

• ss: server subcommand (sub-команда сервера)
1: ответ на окончание загрузки блока

• n: показывает количество байт в последнем сегменте последнего блока, которое не содержит данных. Байты [8-n, 7] не содержат данные сегмента.

• crc: 16-битная контрольная сумма (Cyclic Redundancy Checksum, CRC) для всего набора данных. Алгоритм генерации CRC описан в 9.2.2.2.16. CRC допустима только если в протоколе Initiate Block Download поля cc и sc установлены в 1, иначе CRC должна быть установлена в 0.

• X: не используется, всегда 0

• reserved: резервировано для использования в будущем, всегда 0

CiA301 Upload SDO Block Protocol fig27

Рис. 27. Протокол Upload SDO Block.

Этот протокол используется для реализации службы SDO Block Upload, которая начинается со службы Initiate SDO Block Upload. Клиент может показать пороговое значение для сервера, которое минимальное значение в байтах для увеличения производительности передачи с помощью использования протокола SDO Block Upload вместо протокола SDO Upload. Если размер набора данных меньше или равен этому значению, то сервер может продолжить с нормальной или ускоренной (expedited) передачей протокол SDO Block Upload.

Иначе объекты SDOs выгружаются как последовательность Upload SDO Block служб. Последовательность SDO Upload Block завершается:

• выгруженным сегментом в блоке с c-битом, установленным в 1, показывая тем самым завершение последовательности выгрузки блока.

• запросом/индикацией Abort SDO Transfer, которые показывают не успешное завершение последовательности выгрузки.

Вся служба SDO Block Upload завершается службой End SDO Block Upload. Если клиент, как и сервер, показал возможность генерировать CRC во время службы Initiate SDO Block Upload, то клиент сгенерировал CRC на принятых данных. Если эта CRC отличается от CRC, которую сгенерировал сервер, то клиент покажет это индикацией Abort SDO Transfer.

Этот протокол используется для реализации службы Initiate SDO Block Upload. Если значение параметра порога переключения протокола (Protocol Switch Threshold), показанный клиентом в первом запросе, оказался меньше или равным размеру набора данных для выгрузки, то сервер может продолжить выгрузку с протоколом SDO Upload, как это описано в 9.2.2.2.4.

CiA301 Initiate SDO Block Upload Protocol fig28

Рис. 28. Протокол Initiate SDO Block Upload.

• ccs: client command specifier (команда клиента)
5: block upload (выгрузка блока)

• scs: server command specifier (команда сервера)
6: block upload (выгрузка блока)

• cs: client subcommand (sub-команда клиента)
0: запрос инициации выгрузки
3: старт выгрузки

• ss: server subcommand (sub-команда сервера)
0: ответ на инициацию выгрузки

• m: multiplexor. Он представляет индекс/sub-индекс данных для передачи объектом SDO.

• cc: поддержка CRC клиентом
cc = 0: клиент не поддерживает генерацию CRC по данным
cc = 1: клиент поддерживает генерацию CRC по данным

• sc: поддержка CRC сервером
sc = 0: сервер не поддерживает генерацию CRC по данным
sc = 1: сервер поддерживает генерацию CRC по данным

• pst: Protocol Switch Threshold (порог переключения протокола) в байтах, чтобы поменять протокол передачи SDO.
pst = 0: изменение протокола не разрешено.
pst > 0: если размер данных в байтах для выгрузки меньше или равно pst, то сервер может опционально переключиться на протокол SDO Upload путем передачи сервером ответа 'SDO Upload Protocol', как это описано в 9.2.2.2.4.

• s: индикатор размера
0: размер набора данных не показан
1: показан размер набора данных

• size: выгружаемый размер в байтах
s = 0: size резервирован для будущего использования, всегда 0
s = 1: size содержит количество байт для выгрузки. Байт 4 содержит младший байт, байт 7 содержит старший байт.

• blksize: количество сегментов на блок, 0 < blksize < 128.

• X: не используется, всегда 0

• reserved: резервировано для использования в будущем, всегда 0

Этот протокол используется для реализации службы SDO Block Upload.

CiA301 Upload SDO Block Segment Protocol fig29

Рис. 29. Протокол Upload SDO Block Segment.

• ccs: client command specifier (команда клиента)
5: block upload (выгрузка блока)

• cs: client subcommand (sub-команда клиента)
2: block upload response (ответ на выгрузку блока)

• c: показывает, есть ли еще сегменты для выгрузки
0: есть еще сегменты для выгрузки
1: больше нет сегментов для выгрузки, вход в фазу End block upload

• seqno: последовательный номер сегмента, 0 < seqno < 128.

• seg-data: самое большее 7 байт данных сегмента для выгрузки.

• ackseq: последовательный номер последнего сегмента, который был успешно принят во время последней выгрузки блока. Если ackseq установлен в 0, то клиент показывает серверу, что сегмент с последовательным номером 1 не было принят корректно, и все сегменты должны быть повторно переданы сервером.

• blksize: количество сегментов на блок, которое должно использоваться сервером для следующей выгрузке блока, 0 < blksize < 128.

• X: не используется, всегда 0

• reserved: резервировано для использования в будущем, всегда 0

Этот протокол используется для реализации службы End SDO Block Upload.

CiA301 End SDO Block Upload Protocol fig30

Рис. 30: Протокол End SDO Block Upload.

• ccs: client command specifier (команда клиента)
5: block upload (выгрузка блока)

• scs: server command specifier (команда сервера)
6: block upload (выгрузка блока)

• cs: client subcommand (sub-команда клиента)
1: запрос окончания выгрузки блока

• ss: server subcommand (sub-команда сервера)
1: ответ на окончание выгрузки блока

• n: показывает количество байт в последнем сегменте, последнего блока, которое не содержит данных. Байты [8-n, 7] не содержат данные сегмента.

• crc: 16-битная контрольная сумма (Cyclic Redundancy Checksum, CRC) всего набора данных. Алгоритм для генерации CRC описан в 9.2.2.2.16. CRC допустима только если в службе Initiate Block Upload поля cc и sc установлены в 1, иначе CRC должна быть установлена в 0.

• X: не используется, всегда 0

• reserved: резервировано для использования в будущем, всегда 0

Чтобы проверить корректность выгрузки/загрузки блока SDO, клиент и сервер вычисляют контрольную сумму (CRC) значением которой обмениваются в протоколе End SDO Block Download/End SDO Block Upload. Накопление CRC происходит по полиному x^16 + x^12 + x^5 + 1, с начальным значением 0.

9.2.3. Объект синхронизации (SYNC). Объект синхронизации периодически и широковещательно передается SYNC-продюсером всем узлам сети. Этот SYNC предоставляет базовые такты для сети. Период времени между SYNC-ами указаны стандартным параметром периода цикла коммуникации (см. Object 1006h: Communication Cycle Period), который может быть записан инструментом конфигурирования в устройства приложения во время процесса их загрузки (boot-up process). Здесь может присутствовать джиттер (дрожание интервала) времени в передаче SYNC продюсером, соответствующий приблизительно латентности из-за того, что некоторые другие сообщения могут быть переданы перед SYNC.

Чтобы гарантировать достаточно точный доступ по времени к шине CAN, сообщению SYNC дается очень высокий идентификатор приоритета (1005h). Устройства, которые работают синхронно, могут использовать объект SYNC для синхронизации своих собственных процессов по сигналам продюсера синхронизации. Как именно будет осуществляться синхронизация зависит от самого устройства, и обсуждение этого вопроса выходит за рамки нашего обсуждения. Устройства, которые требуют более точной базы времени, могут использовать механизм синхронизации высокого разрешения, описанный в 9.3.2.

9.2.3.1. Службы SYNC. Передача SYNC следует push-модели producer/consumer, как это описано в 6.3.3. Эта служба является не подтверждаемой.

Атрибуты:

- user type: тип пользователя, одно из значений {consumer, producer}
- data type: тип данных, nil

9.2.3.2. Протокол SYNC. Определена одна не подтверждаемая служба (Write SYNC).

CiA301 SYNC Protocol fig31

Рис. 31. Протокол SYNC.

SYNC не переносит в себе никаких данных (L=0). Идентификатор объекта SYNC размещен по индексу объекта 1005h в словаре OD устройства.

9.2.4. Time Stamp Object (TIME). С помощью объекта метки времени (Time Stamp Object) для устройств предоставляется общий эталон времени. Он содержит значение типа TIME_OF_DAY. Идентификатор объекта TIME находится в OD по индексу 1012h.

9.2.4.1. Службы TIME. Передача объекта Time Stamp следует push-модели producer/consumer, как это описано в 6.3.3. Эта служба не подтверждаемая.

Атрибуты:

- user type: тип пользователя, одно из значений {consumer, producer}
- data type: тип данных, TIME_OF_DAY

9.2.4.2. Протокол TIME. Определена одна не подтверждаемая служба (Write TIME).

CiA301 TIME Protocol fig32

Рис. 32. Протокол TIME.

Time Stamp: 6 байт данных объекта Time Stamp.

9.2.5.1. Использование объекта EMCY. Объекты Emergency (авария) срабатывают при возникновении ошибки, обнаруженной устройством, и они передаются продюсером аварии (emergency producer) устройства. Объекты аварии подходят для оповещений об ошибках наподобие прерываний. Объект EMCY передается только один раз на событие ошибки (error event). Больше не должны передаваться объекты EMCY, пока не появятся новые ошибки устройства. Объект EMCY может быть не принят никем, либо одним или большим количеством потребителей. Реакция потребителя (потребителей) EMCY не задана, и не попадает в область рассмотрения этого документа. Заданы смысловые значения кодов ошибки аварии (таблица 21) и регистр ошибки (error register, таблица 48). Дополнительная специфическая информация устройства и условия возникновения аварии не попадают в область рассмотрения этой спецификации.

Таблица 21. Emergency Error Codes (коды ошибок аварии).

Error code
(hex)
Значение
00xx Error Reset or No Error (сброс ошибки или нет ошибки)
10xx Generic Error (обычная ошибка)
20xx
21xx
22xx
23xx
Current (ток)
   на входе устройства
   внутри устройства
   на выходе устройства
30xx
31xx
32xx
33xx
Voltage (напряжение)
   Mains Voltage (главное напряжение)
   внутри устройства
   на выходе
40xx
41xx
42xx
Temperature (температура)
   Ambient Temperature (окружающего воздуха)
   Device Temperature (устройства)
50xx Device Hardware (аппаратура устройства)
60xx
61xx
62xx
63xx
Device Software (программное обеспечение устройства)
   Internal Software (внутреннее)
   User Software (пользовательское)
   Data Set (набор данных)
70xx Additional Modules (дополнительные модули)
80xx
81xx
8110
8120
8130
8140
8150
82xx
8210
8220
Monitoring (слежение)
   Communication (за обменом данными)
      CAN Overrun (переполнение данных, потеря объектов)
      CAN in Error Passive Mode (ошибка пассивного режима)
      Life Guard Error or Heartbeat Error (ошибка проверки узлов сети)
      Recovered from bus off (восстановление после отключения шины)
      Transmit COB-ID collision (коллизия идентификаторов передачи)
   Protocol Error (ошибка протокола)
      PDO not processed due to length error (PDO не обработан из-за ошибки длины)
      PDO length exceeded (превышена длина PDO)
90xx External Error (внешняя ошибка)
F0xx Additional Functions (дополнительные функции)
FFxx Device specific (ошибка, специфическая для устройства)

Объект аварии не обязателен. Если устройство поддерживает объект аварии, то оно должно поддерживать как минимум 2 кода ошибки 00xx и 10xx. Все другие коды ошибки являются необязательными.

Устройство может иметь одно из двух состояний аварии (emergency states, рис. 33). В зависимости от переходов между состояниями будут отправляться объекты аварии. Связи между машиной состояний ошибок и машиной состояний NMT определена в профилях устройства.

0. После инициализации устройство входит в состояние без ошибки, если не было определено ни одной ошибки. Не будет отправлено сообщение об ошибке.

1. Устройство определило внутреннюю ошибку, которая показывается в первых 3 байтах сообщения аварии (error code и error register). Устройство входит в состояние ошибки (error state). Передается объект аварии с соответствующим кодом ошибки (error code) и регистром ошибки (error register). Код ошибки заполняется в объект 1003H (заранее определенное поле ошибки).

2. Одна, но не все причины ошибки были переданы. Может быть отправлено сообщение ошибки, содержащее код ошибки 0000 (Error reset) вместе с оставшимися ошибками в регистре ошибки и в специфическом для производителя поле ошибки.

3. Произошла новая ошибка на устройстве. Устройство остается в состоянии ошибки, и передает объект аварии с соответствующим кодом новой ошибки. Код новой ошибки заполняется на вершине массива кодов ошибок (1003H). Это дает гарантию, что коды ошибки будут сортированы по времени возникновения (самая старая ошибка получит самый большой sub-индекс, см. Object 1003H).

4. Все ошибки исправлены. Устройство входит в состояние без ошибок, и передает объект аварии с кодом ошибки (reset error / no error).

CiA301 Emergency State Transition Diagram fig33

Рис. 33. Диаграмма перехода между состояниями аварии.

9.2.5.2. Emergency Object Data. Телеграмма аварии состоит из 8 байтов с данными, показанными на рис. 34.

Байт 0 1 2 3 4 5 6 7
Содержимое Emergency Error Code
(см. таблицу 21)
Регистр ошибки
(объект 1001h)
Поле ошибки, специфическое для производителя

Рис. 34. Emergency Object Data (данные объекта аварии).

9.2.5.3. Emergency Object Services. Передача объекта аварии следует push-модели nbgf "producer – consumer", как описано в 6.3.3. Для объекта аварии заданы следующие атрибуты:

user type:    notifying device: producer
              receiving devices: consumer

data type:    STRUCTURE OF
              UNSIGNED(16) emergency_error_code,
              UNSIGNED(8) error_register,
              ARRAY (5) of UNSIGNED(8) manufacturer_specific_error_field

inhibit time: Application specific

9.2.5.4. Emergency Object Protocol. Определена одна не подтверждаемая служба (Write EMCY).

CiA301 Emergency Object Protocol fig35

Рис. 35: Протокол Emergency Object.

Не допускается запрашивать объект аварии через запрос RTR.

Система управления сетью (Network Management, NMT) ориентирована на узлы сети, и следует модели master-slave. Объекты NMT используются для запуска служб NMT. Через службы NMT узлы инициализируются, запускаются, мониторятся, сбрасываются или останавливаются. Все узлы по отношению к NMT считаются подчиненными. NMT Slave уникально идентифицируется в сети по своему Node-ID (значение в диапазоне 1..127).

NMT требует, чтобы одно из устройств в сети выполняло функцию NMT.

9.2.6.1. Службы NMT

9.2.6.1.1. Module Control Services. С помощью службы управления модулями NMT master управляет состоянием устройств NMT slave. Атрибут состояния может быть одним из значений {STOPPED, PRE-OPERATIONAL, OPERATIONAL, INITIALISING}. Module Control Services могут быть выполнены над одним определенным узлом или над всеми узлами сети одновременно. NMT master управляет своей собственной машиной состояний NMT через локальные службы, зависящие от реализации. Module Control Services, кроме службы Start Remote Node, могут быть инициированы локальным приложением.

Start Remote Node

Через эту службу NMT Master устанавливает состояние выбранных узлов NMT Slaves в состояние OPERATIONAL.

Таблица 22. Start Remote Node (запуск дальнего узла).

Параметр Индикация/запрос
Argument
   Node-ID (идентификатор узла)
   All (все узлы)
Наличие обязательно
   выбор
   выбор

Эта служба не подтверждаемая, и её наличие обязательно. После завершения службы состояние выбранных узлов сети (remote nodes) будет OPERATIONAL.

Stop Remote Node

Через эту службу NMT Master устанавливает состояние выбранных узлов NMT Slaves в состояние STOPPED.

Таблица 23. Stop Remote Node (остановка дальнего узла).

Параметр Запрос/индикация
Argument
   Node-ID (идентификатор узла)
   All (все узлы)
Наличие обязательно
   выбор
   выбор

Эта служба не подтверждаемая, и её наличие обязательно. После завершения службы состояние выбранных узлов сети (remote nodes) будет STOPPED.

Enter Pre-Operational

Через эту службу NMT устанавливает состояние выбранного узла NMT Slave (или узлов) в состояние PREOPERATIONAL.

Таблица 24. Enter Pre-Operational (вход в предварительное рабочее состояние).

Параметр Запрос/индикация
Argument
   Node-ID (идентификатор узла)
   All (все узлы)
Наличие обязательно
   выбор
   выбор

Эта служба не подтверждаемая, и её наличие обязательно. После завершения службы состояние выбранных узлов сети (remote nodes) будет PRE-OPERATIONAL.

Reset Node

Через эту службу NMT переводит состояние выбранного узла NMT Slave (или узлов) из любого состояния в промежуточное состояние "сброс приложения".

Таблица 25. Reset Node (сброс узла).

Параметр Запрос/индикация
Argument
   Node-ID (идентификатор узла)
   All (все узлы)
Наличие обязательно
   выбор
   выбор

Эта служба не подтверждаемая, и её наличие обязательно. После завершения службы состояние выбранных узлов сети (remote nodes) будет RESET APPLICATION.

Reset Communication

Через эту службу NMT переводит состояние выбранного узла NMT Slave (или узлов) из любого состояния в промежуточное состояние "сброс обмена данными". После завершения этой службы выбранные узлы сети будут в состоянии RESET COMMUNICATION.

Таблица 26. Reset Communication (сброс обмена данными).

Параметр Запрос/индикация
Argument
   Node-ID (идентификатор узла)
   All (все узлы)
Наличие обязательно
   выбор
   выбор

Эта служба не подтверждаемая, и её наличие обязательно для всех устройств.

9.2.6.1.2. Error Control Services. Через службы контроля ошибок NMT определяет отказы в сети CAN. Локальные ошибки на узле могут, например, приводить к сбросу или изменению состояния узла. Определение локальных ошибок не попадает в область рассмотрения этой спецификации.

Службы Error Control реализованы по принципу периодической отправки сообщений устройством. Имеется 2 варианта выполнения Error Control.

Так называемая защита (guarding) достигается передачей запросов guarding (протокол Node guarding) от устройства NMT Master. Если устройство NMT Slave не отвечает в определенный интервал времени (node life time, время жизни узла), или если неожиданно поменялся статус коммуникации NMT Slave, то NMT Master информирует свое приложение об этом событии.

Если поддерживается Life guarding (устройство NMT slave защищает устройство NMT master), то slave-устройство использует время защиты (guard time) и множитель времени жизни (lifetime factor) из своего OD, чтобы определить время жизни узла. Если NMT Slave оказался не защищен за это время жизни, то NMT Slave оповещает свое локальное приложение об этом событии. Если параметры guard time и life time factor равны 0 (значения по умолчанию), то NMT Slave не защищает NMT Master.

Защита запускается для slave, когда принят первый запрос на передачу для его guarding-идентификатора. Это может произойти на фазе загрузки (boot-up) или позже.

Механизм heartbeat устанавливается через циклическую передачу сообщения от heartbeat-продюсера. Одно или большее количество устройств в сети знают об этом сообщении подтверждения работоспособности. Если цикл heartbeat был нарушен для heartbeat-продюсера, то локальное приложение heartbeat-потребителя будет оповещено об этом событии.

Реализация либо системы guarding, либо heartbeat является обязательной.

Node Guarding Event. Через эту службу провайдер службы NMT показывает, что произошла ошибка сетевого узла, ли она была разрешена для узла, идентифицированного по Node-ID.

Таблица 27. Node Guarding Event (событие защиты узла).

Параметр Индикация
Argument
   Node-ID (идентификатор узла)
   State (состояние узла)
      Occurred (произошло)
      Resolved (обработано)
Наличие обязательно
   обязательно
   обязательно
      выбор
      выбор

Эта служба инициируется провайдером и является опциональной.

Life Guarding Event. Через эту службу провайдер службы NMT на устройстве NMT Slave показывает, что произошла ошибка сетевого узла, или она была исправлена.

Таблица 28. Life Guarding Event (событие охраны жизнеспособности узла).

Параметр Индикация
Argument
   State (состояние узла)
      Occurred (произошло)
      Resolved (обработано)
Наличие обязательно
   обязательно
      выбор
      выбор

Эта служба инициируется провайдером и является опциональной.

Heartbeat Event. Через эту службу потребитель Heartbeat показывает, что произошла ошибка heartbeat, или эта ошибка была исправлена на узле, идентифицированном по Node-ID.

Таблица 29. Heartbeat Event (событие сердцебиения).

Параметр Индикация
Argument
   Node-ID (идентификатор узла)
   State (состояние узла)
      Occurred (произошло)
      Resolved (обработано)
Наличие обязательно
   обязательно
   обязательно
      выбор
      выбор

Эта служба инициируется провайдером и является опциональной.

9.2.6.1.3. Bootup Service

Bootup Event. Через эту службу устройство NMT показывает, что его локальное состояние перешло из INITIALISING в состояние PRE-OPERATIONAL.

Таблица 30. Bootup Event (событие загрузки узла).

Параметр Индикация
Argument
   отсутствует
Наличие обязательно
 

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

9.2.6.2. Протоколы NMT

9.2.6.2.1. Протоколы Module Control

Протокол Start Remote Node. Этот протокол используется для реализации службы Start Remote Node.

CiA301 Start Remote Node Protocol fig36

Рис. 36. Протокол Start Remote Node.

• cs: NMT command specifier (команда NMT)
1: start

Протокол Stop Remote Node. Этот протокол используется для реализации службы Stop Remote Node.

CiA301 Stop Remote Node Protocol fig37

Рис. 37. Протокол Stop Remote Node.

• cs: NMT command specifier (команда NMT)
2: stop

Протокол Enter Pre-Operational. Этот протокол используется для реализации службы Enter Pre-Operational.

CiA301 Enter Pre Operational Protocol fig38

Рис. 38. Протокол Enter Pre-Operational.

• cs: NMT command specifier (команда NMT)
128: войти в состояние PRE-OPERATIONAL

Протокол Reset Node. Этот протокол используется для реализации службы Reset Node.

CiA301 Reset Node Protocol fig39

Рис. 39. Протокол Reset Node.

cs: NMT command specifier (команда NMT)
129: Reset Node (сброс узла)

Протокол Reset Communication. Этот протокол используется для реализации службы Reset Communication.

CiA301 Reset Communication Protocol fig40

Рис. 40. Протокол Reset Communication.

cs: NMT command specifier (команда NMT)
130: Reset Communication (сброс обмена данными)

9.2.6.2.2. Протоколы Error Control

Протокол Node Guarding. Этот протокол используется для определения сетевых ошибок (remote errors). Каждое устройство NMT Slave использует один remote COB-ID для протокола Node Guarding. Этот протокол реализует инициируемые провайдером службы Error Control.

CiA301 Node Guarding Protocol fig41

Рис. 41. Протокол Node Guarding.

Примечание *: если произошла ошибка защиты (guarding error).

s: состояние NMT
   4: STOPPED
   5: OPERATIONAL
   127: PRE-OPERATIONAL

t: toggle bit. Значение этого бита должно каждый раз меняться между двумя соседними ответами от NMT Slave. Значение бита toggle первого ответа после активизации протокола Guarding будет равно 0. Toggle Bit в протоколе guarding сбрасывается в 0 только когда передан reset_communication (никакие другие переходы между состояниями узла не сбрасывают бит toggle). Если принят ответ с тем же самым значением бита toggle, как и в предыдущем ответе, то тогда новый ответ обрабатывается как пропуск сообщения ответа.

NMT Master опрашивает каждый узел NMT Slave с регулярными интервалами времени. Этот интервал называется guard time, и он может отличаться для каждого NMT Slave. Ответ от NMT Slave содержит его состояние. Параметр времени жизни (node life time) узла дается как guard time, умноженное на life time factor. Время жизни узла может отличаться для каждого NMT Slave. Если NMT Slave не был опрошен в свой интервал времени life time, будет показана ошибка дальнего узла (remote node error) через службу Life Guarding Event. Ошибка remote node error показывается через службу Node guarding event, если:

• Запрос RTR не был подтвержден за время node life time.
• Состояние, сообщенное NMT slave, не соответствует ожидаемому.

Если была индикация, что произошла ошибка remote error, и ошибки в протоколе guarding исчезли, то это будет показано как исправление remote error с помощью служб Node Guarding Event и Life Guarding Event.

Для интервала guard time и для life time factor имеются значения по умолчанию, заданные в соответствующих элементах OD.

Протокол Heartbeat. Этот протокол определяет службу контроля ошибок (Error Control Service) без необходимости посылать фреймы RTR. Продюсер Heartbeat циклически передает сообщение Heartbeat. Один или большее количество потребителей Heartbeat принимают эту индикацию. Взаимодействие между продюсером и потребителем конфигурируется через OD. Потребитель Heartbeat защищает прием Heartbeat в пределах интервала Heartbeat Consumer Time. Если сообщение Heartbeat не было принято в этом интервале, то генерируется Heartbeat Event, сообщающее об ошибке.

CiA301 Heartbeat Protocol fig42

Рис. 42. Протокол Heartbeat.

r: зарезервировано (всегда 0)

s: состояние продюсера Heartbeat
   0: BOOTUP
   4: STOPPED
   5: OPERATIONAL
   127: PRE-OPERATIONAL

Если Heartbeat Producer Time сконфигурировано на устройстве, то протокол Heartbeat немедленно начинает работу. Если устройство запускается со значением для Heartbeat Producer Time, не равным 0, то протокол Heartbeat запускается в момент перехода из состояния INITIALISING в состояние PRE-OPERATIONAL. В этом случае сообщение Bootup считается как первое сообщение heartbeat. Не разрешено для одного устройства использовать оба механизма защиты одновременно, Guarding Protocol и Heartbeat Protocol. Если интервал Heartbeat Producer Time не равен 0, то для защиты используется протокол Heartbeat.

9.2.6.2.3. Протокол Bootup. Этот протокол используется для сигнала о том, что устройство NMT slave вошло в состояние узла PRE-OPERATIONAL перед тем, как оно было в состоянии INITIALISING. Протокол использует тот же идентификатор, что и протоколы контроля ошибок.

CiA301 Bootup Protocol fig43

Рис. 43. Протокол Bootup.

Передается 1 байт данных со значением 0.

[9.3. Синхронизация потребителя SYNC]

9.3.1. Передача синхронных сообщений PDO. Синхронность передачи сообщения (полезной нагрузки протокола) означает, что передача сообщения фиксирована по времени относительно передачи специального сообщения синхронизации (SYNC). Синхронное сообщение передается в указанном окне времени относительно появления сообщения SYNC, и самое большее передается 1 раз за каждый период SYNC.

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

Обычно синхронный PDO с командным значением будет принят перед SYNC. Потребляющее SYNC устройство будет активировано на базе этого синхронного PDO в момент следующего сообщения SYNC. Прием SYNC также запросит устройство, работающее в циклическом режиме, оцифровать свои данные обратной связи и передать впоследствии синхронное PDO с актуальным значением как можно скорее. В зависимости от своих возможностей, устройство также может быть параметризировано с периодом времени окна синхронизации после сообщения SYNC, в котором гарантируется, что поступило её управляющее значение. Таким образом, это может обеспечить любую обработку том на управляющем значении, которое требовалось, чтобы управление было применено на следующем сообщении SYNC.

CiA301 Bus Synchronisation and Actuation fig44

Рис. 44. Синхронизация и активация шины.

CiA301 Bus Synchronisation and Sampling fig45

Рис. 45. Синхронизация шины и оцифровка данных (Sampling).

9.3.2. Не обязательный протокол точной синхронизации (Optional High Resolution Synchronisation Protocol). Сообщение синхронизации не несет в себе данных, и его просто генерировать. Однако джиттер этого SYNC зависит от скорости шины, потому что даже очень высокоприоритетное сообщение SYNC будет ждать момента окончания передачи текущего сообщения на шине, чтобы получить к ней доступ.

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

SYNC-продюсер меток времени генерирует их прерыванием в момент t1 путем успешной передачи сообщения SYNC (это занимает время до t2). После этого (в момент t4) он сообщает сообщение метки времени, содержащее скорректированную метку времени (t1) для индикации успешной передачи SYNC. Потребитель SYNC, который берет локальные метки времени (t3) на приеме (t1) SYNC, теперь может сравнить свою скорректированную метку времени (t1) с принятой в сообщении метки времени, поступившем от SYNC-продюсера. Разница между этими значениями определяет величину времени, на которую нужно подстроить свою локальную тактовую частоту. С этим протоколом критичны по времени только локальные задержки (t2-t1 в продюсере SYNC и t3-t1 в потребителе SYNC). Эти задержки зависят от локальных параметров (таких как задержки обработки прерывания и задержки аппаратуры) на узлах, которые можно определить один раз заранее. Точность этого определения специфична для определенной реализации, она формирует ограничивающий фактор точности синхронизации (или подстройки тактов). Имейте в виду, что только каждый узел может знать свою собственную задержку, так как сообщение метки времени содержит скорректированное значение t1, а не t2.

Метка времени (time-stamp) закодирована как UNSIGNED32 с разрешающей способностью 1 микросекунда. Это означает, что счетчик времени перезапускается (начинает счет от нуля) через каждые 72 минуты. Это конфигурируется путем отображения на PDO метки времени высокого разрешения.

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

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

CiA301 Optional High Resolution Synchronisation Protocol fig46

Рис. 46. Не обязательный протокол High Resolution Synchronisation.

[9.4. Инициализация сети и загрузка системы (System Boot-Up)]

9.4.1. Процедура инициализации. На рис. 47 показан общий алгоритм процесса инициализации сети, управляемый приложением мастера NMT или конфигурирующим приложением.

CiA301 Flow Chart Network Initialisation fig47

Рис. 47. Диаграмма процесса инициализации сети.

На шаге A устройства находятся в состоянии узла PRE-OPERATIONAL, в которое они входят автоматически после включения питания. В этом состоянии устройства доступны через их Default-SDO при использовании идентификаторов, которые были назначены в соответствии с принципом Predefined Connection Set. На этом шаге конфигурация параметров устройства осуществляется на всех узлах, которые поддерживают конфигурацию параметра.

Это осуществляется специальным конфигурирующим приложением или инструментарием, которое находится на узле, являющемся клиентом для объектов SDO по умолчанию. Для устройств, которые поддерживают эти функции выбора и/или конфигурирования объектов PDO, отображение объектов приложения (PDO mapping), конфигурирование дополнительных SDO и опционально установку идентификаторов COB-ID, все это конфигурирование может быть осуществлено через объекты SDO по умолчанию.

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

Если приложение требует синхронизации всех или некоторых узлов сети, то подходящие механизмы могут быть инициированы на опциональном шаге B. Это может использоваться для гарантии, что все узлы засинхронизированы объектом SYNC перед входом в состояние OPERATIONAL на шаге D. Первая передача объекта SYNC начинается в пределах 1 цикла синхронизации после входа в состояние PRE-OPERATIONAL. На шаге C может быть активирован механизм контролирования узлов Node guarding (если он поддерживается), с использованием параметров guarding, которые были сконфигурированы на шаге A.

С шагом D все узлы разрешены для обмена через свои объекты PDO.

9.4.2. Машина состояний NMT

9.4.2.1. Обзор. На рис. 48 показана диаграмма состояний устройства. Устройства входят в состояние PRE-OPERATIONAL сразу после завершения своей инициализации. Во время этого состояния возможна параметризация устройства и выделение ID через SDO (например, с помощью инструментария конфигурирования). Затем узлы могут быть сразу переключены в состояние OPERATIONAL.

Машина состояний NMT определяет поведение блока функции обмена данными (Communication function unit, см. 6.2). Машина состояний приложения вместе с машиной состояния NMT зависит от устройства, и попадает в область действия профилей устройства.

Минимальная процедура загрузки (Boot-Up) состоит из одной телеграммы CAN: широковещательного (broadcast) сообщения Start_Remote_Node.

CiA301 Device State Diagram fig48

Рис. 48. Диаграмма состояний устройства (узла сети CANopen).

Таблица 31. Условия перехода между состояниями с выдачей NMT-сообщений.

(1) В состояние инициализации после включения питания / сброса устройство CANopen входит самостоятельно (без команды от Master).
(2) Инициализация завершена - автоматический вход в состояние PRE-OPERATIONAL (без команды от Master).
(3), (6) Индикация в сеть (NMT-сообщение) Start Remote Node ("сетевой узел запустился").
(4), (7) Индикация в сеть Enter PRE-OPERATIONAL ("вход в предварительное рабочее состояние, готовность к работе").
(5), (8) Индикация в сеть Stop Remote Node ("сетевой узел остановлен").
(9),(10),(11) Индикация в сеть Reset Node ("сброс узла").
(12),(13),(14) Индикация в сеть Reset Communication ("сброс коммуникаций").

Примечание: "Индикация в сеть" означает отправку устройством соответствующего NMT-сообщения, которое обычно регистрируется мастером сети CANopen.

9.4.2.2. Состояния

Состояние "Инициализация" делится на три sub-состояния (см. рис. 49), чтобы позволить выполнить полный или частичный сброс узла.

1. Initialising: это первое sub-состояние устройство, в которое оно входит после включения питания или аппаратного сброса. После завершения базовой инициализации узла устройство само входит в состояние Reset_Application.

2. Reset_Application: в этом состоянии устанавливаются в свое состояние "после включения питания" параметры (power-on values), относящиеся либо к специальному профилю устройства производителя, либо к стандартизованному профилю устройства. После установки этих настроек устройство автоматически входит в состояние Reset_Communication.

3. Reset_Communication: в этом состоянии устанавливаются в параметры профиля коммуникации в свои значения "после включения питания" (power-on values). После этого состояние Инициализации завершается, и устройство запускает службу "write boot-up" (короче говоря, выдает в сеть NMT-сообщение boot-up) и входит в состояние PRE-OPERATIONAL.

Значения "после включения питания" это значения настроек, которые были сохранены последний раз (если устройство имеет энергонезависимую память для хранения настроек), или настройки, установленные перемычками. Если сохранение не поддерживается, или не было выполнено, или если сбросу предшествовала команда restore_default (объект OD 1011H), то the power-on values будут соответствовать настройкам по умолчанию в соответствии со спецификациями коммуникации и профиля устройства.

CiA301 Initialisation state structure fig49

Рис. 49. Структура состояния инициализации.

(1) В состояние инициализации после включения питания / сброса устройство CANopen входит самостоятельно (без команды от Master).
(2) Инициализация завершена - автоматический вход в состояние PRE-OPERATIONAL (без команды от Master).
(9),(10),(11) Индикация в сеть Reset Node ("сброс узла").
(12),(13),(14) Индикация в сеть Reset Communication ("сброс коммуникаций").
(15) Инициализация завершена, в состояние Reset Application (сброс приложения) узел входит самостоятельно.
(16) Сброс приложения завершен, в состояние Reset Communication ("сброс коммуникаций") устройство входит самостоятельно.

В состоянии PRE-OPERATIONAL возможен обмен данными через объекты SDO. Объекты PDO не существуют, поэтому обмен PDO не разрешен. Конфигурирующим приложением (обычно это мастер сети CANopen) может быть выполнено конфигурирование объектов PDO, параметров устройства и также выделение в нем объектов приложения (отображение переменных приложения на объекты PDO, так называемое PDO-mapping). Узел сети устройства может быть переключен по NMT-команде в состояние Operational (запрос мастера сети Start Remote Node).

В состоянии OPERATIONAL активны все коммуникационные объекты устройства (SDO, PDO, TIME, SYNC). Переход в OPERATIONAL создает все объекты PDO; конструктор использует параметры, как это описано в OD. Возможен доступ к OD через SDO. Однако аспекты реализации машины состояний приложения могут потребовать ограничить доступ к определенным объектам во время рабочего состояния, потому что объект может содержать программу приложения, и его нельзя изменять во время выполнения.

После переключения устройства в состояние Stopped оно принудительно останавливает весь свой обмен (кроме протоколов защиты сети node guarding или heartbeat, в зависимости от того, что из этого активно). Кроме того, это состояние может использоваться для достижения определенного поведения приложения. Определение этого поведения попадает в область действия спецификации профилей устройства.

9.4.2.3. Взаимосвязь состояния и объекта коммуникации (Communication Object). Таблица 32 показывает взаимоотношение между состояниями коммуникации и объектами коммуникации. Службы на перечисленных объектах коммуникации могут быть выполнены только если устройства, вовлеченные в коммуникацию, находятся в подходящих состояниях коммуникации.

Таблица 32. Состояния и объекты коммуникации.

Объекты Состояния:
INITIALISING PRE-OPERATIONAL OPERATIONAL STOPPED
PDO     X  
SDO   X X  
SYNC   X X  
TIMESTAMP   X X  
EMCY   X X  
Boot-Up X      
NMT   X X X

9.4.2.4. Переходы между состояниями могут быть вызваны:

• Приемом объекта NMT, используемого для служб управления модулем (Module Control Services).
• Аппаратным сбросом.
• Службы управления модулем инициированы локально событиями приложения, как это определено в профилях устройства.

9.4.3. Pre-Defined Connection Set (заранее определенный набор соединений). Чтобы уменьшить усилия по конфигурированию простых сетей определена обязательная схема распределения идентификаторов по умолчанию. Эти идентификаторы доступных в состоянии PRE-OPERATIONAL после инициализации (если не были сохранены модификации). Объекты SYNC, TIME STAMP, EMERGENCY и PDO могут быть удалены и заново созданы с новыми идентификаторами с помощью динамического распределения (dynamic distribution) под управлением мастера сети. Устройство должно предоставить соответствующие идентификаторы только для поддерживаемых объектов коммуникации. Схема выделения ID профиля по умолчанию (таблицы 33 и 34) содержит функциональную часть, которая определяет приоритет объекта и часть идентификатора узла (Node-ID), которые позволяют отделять друг от друга устройства с одинаковой функциональностью. Это дает возможность обмена peer-to-peer между одним мастером и до 127 подчиненными устройствами. Это также поддерживает широковещание (broadcasting) для не подтверждаемых объектов NMT, SYNC и TIME-STAMP. Широковещание показывается установкой Node-ID в значение 0. Заранее определенный набор соединения (pre-defined connection set) поддерживает один объект emergency, один SDO и максимум 4 объекта приема PDO (RPDO) и 4 передачи PDO (TPDO), и объекты NMT.

CiA301 Identifier allocation scheme pre defined connection set fig50

Рис. 50. Схема выделения идентификаторов для для заранее определенного набора соединений (pre-defined connection set).

Таблицы 33 и 34 показывают поддерживаемые объекты и их выделенные COB-ID.

Таблица 33. Объекты широковещания для Pre-defined Connection Set.

Объект Код функции (BIN) Результирующий COB-ID Индекс параметров коммуникации в OD
NMT 0000 0 -
SYNC 0001 128 (80h) 1005h, 1006h, 1007h
TIME STAMP 0010 256 (100h) 1012h, 1013h

Таблица 34. Объекты точка-точка (Peer-to-Peer) для Pre-defined Connection Set.

Объект Код функции (BIN) Результирующий COB-ID Индекс параметров коммуникации в OD
EMCY 0001 129 (81h) – 255 (FFh) 1014h, 1015h
TPDO1 (передача) 0011 385 (181h) – 511 (1FFh) 1800h
RPDO1 (прием) 0100 513 (201h) – 639 (27Fh) 1400h
TPDO2 (передача) 0101 641 (281h) – 767 (2FFh) 1801h
RPDO2 (прием) 0110 769 (301h) – 895 (37Fh) 1401h
TPDO3 (передача) 0111 897 (381h) – 1023 (3FFh) 1802h
RPDO3 (прием) 1000 1025 (401h) – 1151 (47Fh) 1402h
TPDO4 (передача) 1001 1153 (481h) – 1279 (4FFh) 1803h
RPDO4 (прием) 1010 1281 (501h) – 1407 (57Fh) 1403h
SDO (передача) 1011 1409 (581h) – 1535 (5FFh) 1200h
SDO (прием) 1100 1537 (601h) – 1663 (67Fh) 1200h
NMT Error Control 1110 1793 (701h) – 1919 (77Fh) 1016h, 1017h

Таблица 34 должна рассматриваться с точки зрения устройств. Pre-defined connection set всегда применим к стандартному фрейму CAN с 11-битным идентификатором, даже если в сети присутствуют расширенные (extended) фреймы CAN.

Запрещенные COB-ID. Любые COB-ID, перечисленные в таблице 35, запрещены для использования. Такие запрещенные идентификаторы объекта (restricted COB-ID) не должны использоваться в качестве COB-ID любым конфигурируемым объектом коммуникации, ни для SYNC, ни для TIME-STAMP, ни для EMCY, ни для PDO и SDO.

Таблица 35. Запрещенные (restricted) COB-ID.

COB-ID Каким объектом используется
0 (000h) NMT
1 (001h) Зарезервировано
257 (101h) – 384 (180h) Зарезервировано
1409 (581h) – 1535 (5FFh) SDO по умолчанию (передача)
1537 (601h) – 1663 (67Fh) SDO по умолчанию (прием)
1760 (6E0h) Зарезервировано
1793 (701h) – 1919 (77Fh) NMT Error Control
2020 (780h) – 2047 (7FFh) Зарезервировано

[9.5. Object Dictionary (OD)]

9.5.1. Общая структура OD. В этой секции детализирована структура словаря объектов (OD) и записей, которые являются общими для всех устройств. Формат записей OD показан в таблице 36.

Таблица 36. Формат заголовков OD.

Индекс (hex) Объект (символическое имя) Имя       Тип    Атрибут M/O

Полный OD состоит из 6 столбцов, показанных выше.

Индекс. Столбец Index обозначает позицию объекта внутри OD. Это работает как адрес для ссылки на нужное поле данных словаря OD. Здесь не указан sub-индекс. Этот sub-индекс используется для навигации к полям данных сложного объекта словаря, такого как массив (array) или запись (record).

Объект. Этот столбец содержит имя объекта (Object Name) в соответствии с таблицей 37 (см. ниже), и используется для обозначения, какой объект по какому определенному индексу находится в OD. Используются следующие определения:

Таблица 37. Определения объекта (Object Definitions) для OD.

Имя объекта Комментарии Код объекта
NULL Элемент словаря без полей данных. 0
DOMAIN Переменная большого размера, например код выполняемой программы. 2
DEFTYPE Обозначает определение типа, такое так Boolean, UNSIGNED16, float и т. п. 5
DEFSTRUCT Определяет новый тип записи, например структура PDOmapping в позиции 21h. 6
VAR Одиночное значение, такое как UNSIGNED8, Boolean, float, Integer16, видимая строка и т. д. 7
ARRAY Объект, состоящий из множества полей данных, где каждое поле это простая переменная, и все поля одинакового базового типа, например массив чисел UNSIGNED16 и т. п. Sub-индекс 0 имеет тип UNSIGNED8, так что он не является частью данных массива ARRAY. 8
RECORD Объект, состоящий из нескольких полей данных, где поля данных могут быть любой комбинацией простых переменных (типы этих переменных отличаются). Sub-индекс 0 имеет тип UNSIGNED8, так что он не является частью данных RECORD. 9

Имя. Столбец имени предоставляет простое текстовое описание функции определенного объекта.

Тип. Столбец Тип дает информацию о типе объекта. Типы включают предопределенные типы: BOOLEAN, число с плавающей точкой, число без знака (UNSIGNED), число со знаком, видимую строку, октетную строку, время дня, интервал времени и DOMAIN (см. 9.1). Это также включает предопределенный сложный тип данных PDOMapping, и может также другие типы, определенные либо производителем, либо это могут быть типы, специфичные для устройства. Нельзя определить записи из записей, массивы из записей или записей с массивами в качестве полей этой записи. В случае, когда объект является массивом или записью, используется sub-индекс для ссылки на одно поле данных в объекте.

Атрибут. Столбец атрибута определяет права доступа к определенному объекту - с точки зрения от шины в устройство. Атрибуты могут быть:

Таблица 38. Атрибуты доступа (Access Attributes) для объектов данных (Data Objects).

Атрибут Описание
rw Доступ на чтение и запись (Read, Write).
wo Доступ только на запись (Write Only).
ro Доступ только на чтение (Read Only).
Const Доступ только на чтение, значение является константой.

Не обязательные объекты, перечисленные в OD с атрибутом rw (чтение и запись) могут быть реализованы как read only (только чтение).

Исключения определены в подробной спецификации объекта.

M/O. Столбец M/O определяет, является ли объект обязательным (Mandatory) или опциональным, т. е. не обязательным (Optional). Обязательный объект должен быть реализован в устройстве. Опциональный объект не нужно реализовывать в устройстве. Однако поддержка определенных объектов или их функций может потребовать реализации связанных объектов. В этом случае подобные зависимости описаны в подробной спецификации объекта.

9.5.2. Компоненты словаря. Общая топология OD показана в таблице 39.

Индексы 01h - 1Fh содержат стандартные типы данных, индексы 20h - 23h содержат заранее определенные сложные типы данных. Диапазон индексов 24h - 3Fh пока не определен, однако он зарезервирован для будущих стандартных структур данных.

Диапазон индексов 40h - 5Fh свободен для производителей, чтобы определять собственные сложные типы данных. Диапазон 60h - 7Fh содержит стандартные типы данных, специфичные для профиля устройства. В диапазоне 80h – 9Fh определены сложные типы данных, специфичные для профиля устройства. Диапазон A0h – 25Fh зарезервирован для определений типов данных для устройств с несколькими модулями (Multiple Device Modules) подобно элементам 60h – 9Fh. Диапазон 360h – FFFh зарезервирован для будущих расширений. Диапазон 1000h - 1FFFh содержит элементы OD, относящиеся к коммуникации.

Эти параметры называются элементами коммуникации, их спецификация общая для всех типов устройств, независимо от профиля, который использует устройство. Объекты в диапазоне 1000h - 1FFFh, которые не определены в этом документе, зарезервированы для будущего использования. Диапазон 2000h - 5FFFh свободен для определения профиля, специфичного для производителя.

Диапазон 6000h - 9FFFh содержит параметры стандартизованного профиля устройства. Диапазон A000h - FFFFh зарезервирован для будущего использования.

9.5.3. Спецификация типа данных элемента словаря. Статические типы данных помещаются в OD только для цели определения. Однако индексы 0001h - 0007h могут быть отображены также, чтобы определить соответствующее пространств в RPDO как не используемое в этом устройстве (оно не имеет значения, do not care). Индексы 0009h - 000Bh, 000Fh не могут быть отображены в PDO.

Порядок типов данных следующий:

Таблица 39. Типы данных OD.

Индекс Объект Имя
0001 DEFTYPE BOOLEAN
0002 DEFTYPE INTEGER8
0003 DEFTYPE INTEGER16
0004 DEFTYPE INTEGER32
0005 DEFTYPE UNSIGNED8
0006 DEFTYPE UNSIGNED16
0007 DEFTYPE UNSIGNED32
0008 DEFTYPE REAL32
0009 DEFTYPE VISIBLE_STRING
000A DEFTYPE OCTET_STRING
000B DEFTYPE UNICODE_STRING
000C DEFTYPE TIME_OF_DAY
000D DEFTYPE TIME_DIFFERENCE
000E Зарезервировано
000F DEFTYPE DOMAIN
0010 DEFTYPE INTEGER24
0011 DEFTYPE INTEGER32
0012 DEFTYPE REAL64
0013 DEFTYPE INTEGER48
0014 DEFTYPE INTEGER56
0015 DEFTYPE INTEGER64
0016 DEFTYPE UNSIGNED24
0017 Зарезервировано
0018 DEFTYPE UNSIGNED40
0019 DEFTYPE UNSIGNED48
001A DEFTYPE UNSIGNED56
001B DEFTYPE UNSIGNED64
001C-001F Зарезервировано
0020 DEFSTRUCT PDO_COMMUNICATION_PARAMETER
0021 DEFSTRUCT PDO_MAPPING
0022 DEFSTRUCT SDO_PARAMETER
0023 DEFSTRUCT IDENTITY
0024-003F Зарезервировано
0040-005F DEFSTRUCT Сложные типы данных, специфичные для производителя.
0060-007F DEFTYPE Стандартные типы данных, специфические для профиля устройства (0).
0080-009F DEFSTRUCT Сложные типы данных, специфические для профиля устройства (0).
00A0-00BF DEFTYPE Стандартные типы данных, специфические для профиля устройства (1).
00C0-00DF DEFSTRUCT Сложные типы данных, специфические для профиля устройства (1).
00E0-00FF DEFTYPE Стандартные типы данных, специфические для профиля устройства (2).
0100-011F DEFSTRUCT Сложные типы данных, специфические для профиля устройства (2).
0120-013F DEFTYPE Стандартные типы данных, специфические для профиля устройства (3).
0140-015F DEFSTRUCT Сложные типы данных, специфические для профиля устройства (3).
0160-017F DEFTYPE Стандартные типы данных, специфические для профиля устройства (4).
0180-019F DEFSTRUCT Сложные типы данных, специфические для профиля устройства (4).
01A0-01BF DEFTYPE Стандартные типы данных, специфические для профиля устройства (5).
01C0-01DF DEFSTRUCT Сложные типы данных, специфические для профиля устройства (5).
01E0-01FF DEFTYPE Стандартные типы данных, специфические для профиля устройства (6).
0200-021F DEFSTRUCT Сложные типы данных, специфические для профиля устройства (6).
0220-023F DEFTYPE Стандартные типы данных, специфические для профиля устройства (7).
0240-025F DEFSTRUCT Сложные типы данных, специфические для профиля устройства (7).

Представления типов данных описаны в 9.1. Каждому устройству не нужно поддерживать все определенные типы данных. Устройство должно поддерживать только типы данных, которые используются в объектах диапазона индексов 1000h - 9FFFh словаря OD.

Заранее определенные типы данных размещаются после стандартных типов данных. В настоящее время определено 4 типа: запись параметров коммуникации PDO (PDO CommPar record, PDO_COMMUNICATION_PARAMETER), запись отображения PDO (PDO Mapping record, PDO_MAPPING), запись параметра SDO (SDO Parameter record, SDO_PARAMETER) и запись идентичности (Identity record, IDENTITY). Они размещаются по индексам 20h, 21h, 22h и 23h.

Для устройств или профилей устройств, которые предоставляют Multiple Device Modules, например наподобие контроллеров нескольких осей, механизм DEFTYPE / DEFSTRUCT расширен для каждого виртуального устройства со смещением 40h для определения до 7 дополнительных виртуальных устройств.

Устройство может опционально предоставить длину стандартных тиров данных, закодированную как UNSIGNED32 с доступом на чтение по индексу, который относится к типу данных. Например индекс 000Ch (Time of Day, время дня) содержит значение 30h=48, так как тип данных "Time of Day" закодирован последовательностью из 48 бит. Если длина переменная (например 000Fh = Domain), то элемент содержит 0h.

Для поддерживаемых сложных типов данных устройство может опционально предоставить структуру такого типа данных с доступом на чтение по соответствующему индексу типа данных. Sub-индекс 0 тогда содержит количество элементов по этому индексу, не считая sub-индексов 0 и 255, и следующие sub-индексы, которые идут за нулевым sub-индексом, содержат тип данных в соответствии с таблицей 39 закодированный как UNSIGNED8. Элемент по индексу 20h, описывающий структуру коммуникационного параметра PDO (PDO Communication Parameter), тогда выглядит следующим образом (см. также объекты 1400h – 15FFh):

Таблица 40. Пример сложного типа данных.

Sub-индекс Значение Описание
0h 04h 4 sub-индекса, которые идут ниже
1h 07h UNSIGNED32
2h 05h UNSIGNED8
3h 06h UNSIGNED16
4h 05h UNSIGNED8

Стандартные (простые) и сложные типы данных, специфичные для производителя, можно попытаться отличить друг от друга чтением sub-индекса 1h: при сложном типе данных устройство вернет значение, и sub-индекс 0h содержит количество sub-индексов, которые идут за ним. При стандартном типе данных устройство оборвет передачу SDO, так как нет доступного sub-индекса 1h.

Обратите внимание, что некоторые элементы типа данных UNSIGNED32 должны иметь характер структуры (например элемент PDO COBID, см. рис. 65).

9.5.3.1. Организация структурированных записей OD. Если элемент OD (индекс) содержит несколько sub-индексов, тогда sub-индекс 0 этого элемента описывает самое большое значение доступного sub-индекса для sub-индексов, которые идут далее, не рассматривая FFh. Этот элемент закодирован как UNSIGNED8. Sub-индекс FFh описывает структуру элемента предоставлением типа данных и типа объекта элемента. Он закодирован как UNSIGNED32, и организован следующим образом:

Биты 31-16 15-8 7-0
Значение Зарезервировано (значение: 0000h) Тип данных (см. таблицу 39) Объект (см. таблицу 37)
Закодировано как - UNSIGNED8 UNSIGNED8

Рис. 51. Структура sub-индекса FFh.

Поддержка sub-индекса FFh является необязательной. Если он поддерживается всюду в OD, и также предоставлена структура сложного типа данных, то это разрешает выгрузить всю структуру OD.

9.5.4. Спецификация заранее определенных сложных типов данных (Predefined Complex Data Types). Эта секция описывает структуру предопределенных сложных типов данных, используемых для коммуникации. Диапазон значений и их смысл объясняется в подробном описании объектов, использующих эти типы данных.

Индекс Sub-индекс Описание поля записи Тип данных
0020h 0h Количество поддерживаемых полей записи UNSIGNED8
  1h COB-ID UNSIGNED32
  2h Тип передачи UNSIGNED8
  3h Время запрета (inhibit time) UNSIGNED16
  4h Зарезервировано UNSIGNED8
  5h Таймер события (event time) UNSIGNED16

Индекс Sub-индекс Описание поля записи Тип данных
0021h 0h Количество отображенных объектов в PDO UNSIGNED8
  1h 1-й объект для отображения UNSIGNED32
  2h 2-й объект для отображения UNSIGNED32
  ... ... ...
  40h 64-й объект для отображения UNSIGNED32

Индекс Sub-индекс Описание поля записи Тип данных
0022h 0h Количество поддерживаемых элементов UNSIGNED8
  1h COB-ID client -> server UNSIGNED32
  2h COB-ID server -> client UNSIGNED32
  3h ID узла клиента SDO, которым он отвечает серверу UNSIGNED8

Индекс Sub-индекс Описание поля записи Тип данных
0023h 0h Количество поддерживаемых элементов UNSIGNED8
  1h Vendor-ID (идентификатор производителя) UNSIGNED32
  2h Product code (код изделия) UNSIGNED32
  3h Номер ревизии UNSIGNED32
  4h Серийный номер UNSIGNED32

[9.6. Спецификация профиля коммуникации (Communication Profile)]

9.6.1. Подробная спецификация объекта. Структура элементов OD описана таким способом: все устройство, интерфейс и профили приложения, базирующиеся на этом профиле коммуникации, должны следовать этой структуре.

Таблица 45. Формат описания объекта.

ОПИСАНИЕ ОБЪЕКТА

Индекс Индекс профиля
Name Имя параметра
Object Code Переменная классификация
Data Type Тип данных классификации
Category Опционально или обязательно

Object Code должен быть одним из определенных ранее в ОПИСАНИИ ОБЪЕКТА таблицы 45. Для лучшей читаемости описание объекта дополнительно содержит символическое имя объекта (Object Name).

Таблица 46. Формат описания значения объекта (Object Value).

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-Index Количество описываемых sub-индексов. Поле используется только для массивов (Arrays), записей (Records) и структур (Structures).
Description Описательное имя для sub-индекса. Поле используется только для массивов, записей и структур.
Data Type Классификация типа данных. Поле используется только для записей и структур.
Entry Category Указывает является элемент не обязательным (Optional) или обязательным (Mandatory), если объект присутствует.
Access Доступ: Read Only (ro), или Read/Write (rw), или Write Only (wo), или Const. В состоянии OPERATIONAL доступ к элементам OD может быть ограничен, например установлен в ro.
PDO Mapping Отображение PDO: Optional/Default/No - может ли этот объект быть отображен на PDO.
Optional: объект может быть отображен на PDO.
Default: объект является частью отображения по умолчанию (см. профиль устройства).
No: объект не должен быть отображен на PDO.
Value Range Диапазон возможных значений, или имя типа данных для полного диапазоне.
Default Value No: не определено этой спецификацией.
Value: значение по умолчанию объекта после инициализации устройства.

Для простых переменных это описание значения появляется один раз, без поля sub-индекса и категории элемента. Для сложных типов данных описание значения должно быть определено для каждого элемента (sub-индекса).

9.6.2. Обзор элементов OD для коммуникации. Таблица 47 дает обзор по элементам OD, определенным профилем коммуникации:

Таблица 47. Стандартные объекты.

Индекс Объект Имя Тип Acc.(1) M/O
1000h VAR Device type (тип устройства). UNSIGNED32 ro M
1001h VAR Error register (регистр ошибки). UNSIGNED8 ro M
1002h VAR Manufacturer status register (регистр состояния производителя). UNSIGNED32 ro O
1003h ARRAY Pre-defined error field (предварительно определенное поле ошибки). UNSIGNED32 ro O
1004h Зарезервировано по соображениям совместимости.
1005h VAR COB-ID SYNC (CAN-идентификатор объекта синхронизации). UNSIGNED32 rw O
1006h VAR Communication cycle period (период цикла коммуникации). UNSIGNED32 rw O
1007h VAR Synchronous window length (длина окна синхронизации). UNSIGNED32 rw O
1008h VAR Manufacturer device name (имя устройства производителя). VISIBLE-STRING const O
1009h VAR Manufacturer hardware version (версия аппаратуры производителя). VISIBLE-STRING const O
100Ah VAR Manufacturer software version (версия ПО производителя). VISIBLE-STRING const O
100Bh Зарезервировано по соображениям совместимости.
100Ch VAR Guard time (интервал протокола защиты узла). UNSIGNED16 rw O
100Dh VAR Life time factor (множитель для вычисления времени жизни). UNSIGNED8 rw O
100Eh Зарезервировано по соображениям совместимости.
100Fh Зарезервировано по соображениям совместимости.
1010h ARRAY Store parameters (параметры хранилища). UNSIGNED32 rw O
1011h ARRAY Restore default parameters (восстановление параметров по умолчанию). UNSIGNED32 rw O
1012h VAR COB-ID TIME (идентификатор CAN объекта TIME). UNSIGNED32 rw O
1013h VAR High resolution time stamp (метка времени точного протокола синхронизации). UNSIGNED32 rw O
1014h VAR COB-ID EMCY (идентификатор CAN объекта аварии). UNSIGNED32 rw O
1015h VAR Inhibit Time EMCY (время запрета аварии). UNSIGNED16 rw O
1016h ARRAY Consumer heartbeat time (время протокола heartbeat потребителя). UNSIGNED32 rw O
1017h VAR Producer heartbeat time (время протокола heartbeat продюсера). UNSIGNED16 rw O
1018h RECORD Identity Object (объект идентификации). Identity (23h) ro M
1019h Зарезервировано
::::: ::::: ::::: ::::: ::::: :::::
11FFh Зарезервировано
Параметры сервера SDO
1200h RECORD 1-й параметр сервера SDO SDO Parameter (22h) ro O
1201h RECORD 2-й параметр сервера SDO SDO Parameter (22h) rw M/O**
::::: ::::: ::::: ::::: ::::: :::::
127Fh RECORD 128-й параметр сервера SDO SDO Parameter (22h) rw M/O**
Параметры клиента SDO
1280h RECORD 1-й параметр клиента SDO SDO Parameter (22h) ro O
1281h RECORD 2-й параметр клиента SDO SDO Parameter (22h) rw M/O**
::::: ::::: ::::: ::::: ::::: :::::
12FFh RECORD 128-й параметр клиента SDO SDO Parameter (22h) rw M/O**
1300h   Зарезервировано      
::::: ::::: ::::: ::::: ::::: :::::
13FFh   Зарезервировано      
Параметр коммуникации RPDO (PDO приема)
1400h RECORD Параметр 1-го RPDO. PDO CommPar (20h) rw M/O*
1401h RECORD Параметр 2-го RPDO. PDO CommPar (20h) rw M/O*
::::: ::::: ::::: ::::: ::::: :::::
15FFh RECORD Параметр 512-го RPDO. PDO CommPar (20h) rw M/O*
Параметр отображения RPDO (PDO приема)
1600h RECORD Отображение 1-го RPDO. PDO Mapping (21h) rw M/O*
1601h RECORD Отображение 2-го RPDO. PDO Mapping (21h) rw M/O*
::::: ::::: ::::: ::::: ::::: :::::
17FFh RECORD Отображение 512-го RPDO. PDO Mapping (21h) rw M/O*
Параметр коммуникации TPDO (PDO передачи)
1800h RECORD Параметр 1-го TPDO. PDO CommPar (20h) rw M/O*
1801h RECORD Параметр 2-го TPDO. PDO CommPar (20h) rw M/O*
::::: ::::: ::::: ::::: ::::: :::::
19FFh RECORD Параметр 512-го TPDO. PDO CommPar (20h) rw M/O*
Параметр отображения TPDO (PDO передачи)
1A00h RECORD Отображение 1-го TPDO. PDO Mapping (21h) rw M/O*
1A01h RECORD Отображение 2-го TPDO. PDO Mapping (21h) rw M/O*
::::: ::::: ::::: ::::: ::::: :::::
1BFFh RECORD Отображение 512-го TPDO. PDO Mapping (21h) rw M/O*

Примечания:

M/O: столбец M/O означает обязательное наличие элемента OD (M, Mandatory) или не обязательное (O, Optional), либо может быть одно из двух в зависимости от некоторых условий.
(1): Тип доступа (Access type), перечисленный здесь, может меняться для определенных sub-индексов. См. подробную спецификацию объекта.

* Если устройство поддерживает PDO, то в OD обязательно наличие элементов соответствующего параметра коммуникации PDO (PDO communication parameter) и параметра отображения PDO (PDO mapping). Эти элементы могут быть только для чтения.
** Если устройство поддерживает SDO, то соответствующие параметры SDO в OD являются обязательными.

9.6.3. Подробная спецификация объектов, специфичных для профиля коммуникации (Communication Profile)

Содержит информацию о типе устройства. Объект с индексом 1000h описывает тип устройства и его функциональность. Он составлен из 16-битного поля, которое описывает используемый профиль устройства, и второго 16-битного поля, которое дает дополнительную информацию о функциональности устройства. Параметр Additional Information (дополнительная информация) зависит от профиля устройства. Её спецификация не попадает в рамки рассмотрения этого документа, она определена в стандарте соответствующего профиля устройства. Значение 0000h показывает, что устройство не следует стандартизированному профилю устройства. Для устройств с несколькими модулями (multiple device modules) параметр Additional Information содержит FFFFh, и номер профиля устройства, на который ссылается объект 1000h, это профиль устройства для первого из устройств в OD. Все другие устройства для многомодульных устройств идентифицируют свои профили в объектах 67FFh + x * 800h, где x = внутреннему номеру устройства (0 – 7). Эти элементы описывают тип устройства предшествующего устройства.

MSB                                                                                           LSB

Дополнительная информация       Номер профиля устройства       

Рис. 52. Структура параметра Device Type.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1000h
Name device type (тип устройства)
Object Code VAR
Data Type UNSIGNED32
Category Mandatory (наличие обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) ro
PDO Mapping No
Value Range UNSIGNED32
Default Value No

Этот объект является регистром ошибки для устройства. В этом байте устройство может отобразить внутренние ошибки. Этот элемент OD обязателен для всех устройств. Он является частью объекта аварии (Emergency object).

ОПИСАНИЕ ОБЪЕКТА

INDEX 1001h
Name error register (регистр ошибки)
Object Code VAR
Data Type UNSIGNED8
Category Mandatory (наличие обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) ro
PDO Mapping Optional (не обязательно)
Value Range UNSIGNED8
Default Value No

Таблица 48. Структура Error Register (M = Mandatory, O = Optional).

Бит M/O Что бит означает
0 M generic error (общая ошибка)
1 O current (ошибка тока)
2 O voltage (ошибка напряжения)
3 O temperature (ошибка температуры)
4 O communication error (недогрузка/overrun, состояние ошибки/error state)
5 O device profile specific (ошибка, относящаяся к профилю устройства)
6 O зарезервировано (здесь всегда 0)
7 O manufacturer specific (ошибка, специфичная для производителя)

Если установлен в лог. 1 определенный бит, то произошла соответствующая ошибка. Есть только один обязательный вид ошибки - общая ошибка (generic error), о ней можно сигнализировать в любой ошибочной ситуации.

Этот объект является общим регистром состояния, используемый для целей производителя устройства. В этом документе определены только размер и место расположения этого объекта.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1002h
Name manufacturer status register (регистр состояния, предоставленный производителем)
Object Code VAR
Data Type UNSIGNED32
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) ro
PDO Mapping Optional (не обязательно)
Value Range UNSIGNED32
Default Value No

Этот объект содержит ошибки, которые случились с устройством, и о которых сигнализирует объект аварии (Emergency Object). При этом обеспечивается история ошибок.

1. Элемент по индексу 0 содержит количество реальных ошибок, которые записаны в массиве, начиная с sub-индекса 1.

2. Каждая новая ошибка сохраняется по sub-индексу 1, и более старые смещаются вниз по списку.

3. Запись 0 в sub-индекс 0 удаляет всю историю ошибок (очищает массив). Нельзя записывать значения больше 0. Это должно привести к сообщению аварийного завершения (abort message, error code: 0609 0030h).

4. Номера ошибки имеют тип UNSIGNED32 (см. таблицу Таблица 7-18), и они составлены из 16-битного кода ошибки и 16-битного информационного поля, специфичного для производителя. Код ошибки содержится в младших 2 байтах (LSB), и дополнительная информация заключена в старших 2 байтах (MSB). Если этот объект поддерживается, то он должен состоять как минимум из 2 элементов: элемент длины по sub-индексу 0h и как минимум один элемент ошибки по sub-индексу 1h.

MSB                                                                                           LSB

Дополнительная информация       Код ошибки                              

Рис. 53. Структура предопределенного поля ошибки.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1003h
Name pre-defined error field (предварительно определенное поле ошибки)
Object Code ARRAY
Data Type UNSIGNED32
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) number of errors (количество ошибок)             
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range 0 - 254
Default Value 0
Sub-индекс 1h
Description (описание) standard error field (стандартное поле ошибки)
Entry Category Optional (наличие не обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range UNSIGNED32
Default Value No
Sub-индекс 2h - FEh
Description (описание) standard error field (стандартное поле ошибки)
Entry Category Optional (наличие не обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range UNSIGNED32
Default Value No

Индекс 1005h определяет COB-ID объекта синхронизации (Synchronisation Object, SYNC). Кроме того, он определяет, генерирует ли устройство сообщения SYNC. Структура этого объекта показана на рис. 54 и в таблице 49.

                              MSB                                                                                   LSB

Биты 31 30 29 28-11 10-0
11-битный CAN-ID X 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-битный ID
29-битный CAN-ID X 0/1 1 29-битный ID

Рис. 54. Структура элемента SYNC COB-ID.

Таблица 49. Описание элемента SYNC COB-ID.

Бит Значение Что означает
31 (MSB) X Не имеет значения
30 0 Устройство не генерирует сообщение SYNC
1 Устройство генерирует сообщение SYNC
29 0 11-битный ID (CAN 2.0A)
1 29-битный ID (CAN 2.0B)
28 - 11 0 Тут все нули, если бит 29 == 0
X Если бит 29 == 1, то здесь находятся биты 28..11 для 29-битного SYNC COB-ID
10 - 0 (LSB) X Биты 10..0 SYNC COB-ID

Биты 29, 30 могут быть статическими (не изменяемыми). Если устройство не может генерировать сообщения SYNC, то в ответ на попытку установить бит 30 будет выдан ответ сообщением abort (abort code: 0609 0030h). Устройства, поддерживающие только стандартный фрейм CAN, либо игнорируют попытки изменить бит 29, или отвечают сообщением abort message (abort code: 0609 0030h). Первая передача объекта SYNC начинается с 1 цикла синхронизации после установки бита 30 в 1. Не разрешено менять биты 0-29, в то время как объекты существуют (бит 30=1).

ОПИСАНИЕ ОБЪЕКТА

INDEX 1005h
Name COB-ID SYNC (идентификатор CAN объекта/сообщения синхронизации)
Object Code VAR
Data Type UNSIGNED32
Category Conditional (зависит от условия): Mandatory (обязательно), если поддерживается обмен PDO на основе синхронизации.

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32
Default Value 80h или 8000 0080h

Этот объект определяет период цикла коммуникации в микросекундах. Этот период определяет интервал SYNC. Он равен 0, если не используется. Если период цикла коммуникации был изменен на новое значение, не равное 0, то передача объекта синхронизации возобновится в пределах 1 цикла синхронизации с новым значением.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1006h
Name communication cycle period (период цикла коммуникации)
Object Code VAR
Data Type UNSIGNED32
Category Conditional (зависит от условия): Mandatory (обязательно) для продюсеров сообщений SYNC.

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32
Default Value 0

Содержит длину окна времени для синхронных PDO в микросекундах. Равен 0, если не используется.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1007h
Name synchronous window length (размер окна синхронизации)
Object Code VAR
Data Type UNSIGNED32
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32
Default Value 0

Содержит имя производителя устройства.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1008h
Name manufacturer device name (название производителя устройства)
Object Code VAR
Data Type Visible String (видимая строка)
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) const
PDO Mapping No
Value Range No
Default Value No

Содержит описание версии аппаратуры производителя.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1009h
Name manufacturer hardware version (версия аппаратуры производителя)
Object Code VAR
Data Type Visible String (видимая строка)
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) const
PDO Mapping No
Value Range No
Default Value No

Содержит описание версии программного обеспечения производителя.

ОПИСАНИЕ ОБЪЕКТА

INDEX 100Ah
Name manufacturer software version (версия ПО производителя)
Object Code VAR
Data Type Visible String (видимая строка)
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) const
PDO Mapping No
Value Range No
Default Value No

Объекты с индексами 100Ch и 100Dh включают в себя защитное время (guard time) в миллисекундах, и множитель времени жизни (life time factor). Множитель времени жизни, умноженный на защитное время, дает время жизни (life time) для протокола Life Guarding. Этот параметр равен 0, если не используется.

ОПИСАНИЕ ОБЪЕКТА

INDEX 100Ch
Name guard time (защитное время)
Object Code VAR
Data Type UNSIGNED16
Category Conditional (зависит от условия): Mandatory (обязательно), если heartbeat не поддерживается.

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) rw
ro, если не поддерживается life guarding
PDO Mapping No
Value Range UNSIGNED16
Default Value 0

Множитель времени жизни (Life Time Factor), умноженный на защитное время (Guard Time, см. объект 100Ch), дает время жизни (life time) для протокола Life Guarding. Этот параметр равен 0, если не используется.

ОПИСАНИЕ ОБЪЕКТА

INDEX 100Dh
Name life time factor (множитель для вычисления времени жизни)
Object Code VAR
Data Type UNSIGNED8
Category Conditional (зависит от условия): Mandatory (обязательно), если heartbeat не поддерживается.

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) rw
ro, если не поддерживается life guarding
PDO Mapping No
Value Range UNSIGNED8
Default Value 0

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

Sub-индекс 0 содержит самый большой поддерживаемый sub-индекс.
Sub-индекс 1 относится ко всем параметрам, которые можно сохранить в устройстве.
Sub-индекс 2 относится к параметрам, которые связаны с обменом данными (диапазон индексов 1000h - 1FFFh параметров коммуникации, специфических для производителя).
Sub-индекс 3 относится к параметрам, связанным с приложением (индексы 6000h - 9FFFh параметров, специфичных для приложения производителя).
По sub-индексам 4 - 127 производители могут сохранять свой собственный индивидуальный выбор параметров.
Sub-индексы 128 - 254 зарезервированы для будущего использования.

Чтобы избежать ошибки распознания параметров хранения, сохранение запускается только тогда, когда специальная сигнатура записана по соответствующему sub-индексу. Такой сигнатурой является слово "save".

                             MSB                 LSB

ISO 8859 (ASCII) e v a s
hex 65h 76h 61h 73h

Рис. 55. Сигнатура доступа на запись хранилища.

При приеме корректной сигнатуры в соответствующем sub-индексе устройство сохраняет параметр и подтверждает передачу SDO (инициирует ответ на загрузку). Если сохранение было неудачным, то устройство ответит сообщением Abort SDO Transfer (код abort: 0606 0000h).

Если записана ошибочная сигнатура, то устройство отклонит сохранение и ответит Abort SDO Transfer (код abort: 0800 002xh).

При доступе на чтение по соответствующему sub-индексу устройство предоставит информацию о своем функционале хранилища в следующем формате:

          MSB                                        LSB

Биты 31-2 1 0
  Зарезервировано (==0) 0/1 0/1

Рис. 56. Сигнатура доступа на чтение хранилища.

Таблица 50. Структура доступа на чтение.

Бит Значение Что означает
31 - 2 0 Зарезервировано (==0)
1 0 Устройство не сохраняет параметры автономно
1 Устройство само сохраняет параметры
0 0 Устройство не сохраняет параметры по команде
1 Устройство сохраняет параметры по команде

Автономное сохранение означает, что устройство запишет сохраняемые параметры энергонезависимым способом без запроса пользователя.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1010h
Name store parameters (сохранение параметров)
Object Code ARRAY
Data Type UNSIGNED32
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) largest subindex supported (самый большой поддерживаемый sub-индекс)
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 1h – 7Fh
Default Value No
Sub-индекс 1h
Description (описание) save all parameters (сохранение всех параметров)                                   
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (рис. 55 для доступа на запись, рис. 56 на чтение)
Default Value No
Sub-индекс 2h
Description (описание) save communication parameters (сохранение параметров коммуникации)  
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (рис. 55 для доступа на запись, рис. 56 на чтение)
Default Value No
Sub-индекс 3h
Description (описание) save application parameters (сохранение параметров приложения)           
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (рис. 55 для доступа на запись, рис. 56 на чтение)
Default Value No
Sub-индекс 4h - 7Fh
Description (описание) сохранение параметров производителя                                                   
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (рис. 55 для доступа на запись, рис. 56 на чтение)
Default Value No

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

Sub-индекс 0 содержит самый большой поддерживаемый sub-индекс.
Sub-индекс 1 относится ко всем параметрам, которые можно восстановить.
Sub-индекс 2 относится к параметрам, которые связаны с обменом данными (диапазон индексов 1000h - 1FFFh параметров коммуникации, специфических для производителя).
Sub-индекс 3 относится к параметрам, связанным с приложением (индексы 6000h - 9FFFh параметров, специфичных для приложения производителя).
По sub-индексам 4 - 127 производители могут восстанавливать свой собственный индивидуальный выбор параметров.
Sub-индексы 128 - 254 зарезервированы для будущего использования.

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

                             MSB                  LSB

ISO 8859 (ASCII) d a o l
hex 64h 61h 6Fh 6Ch

Рис. 57. Записываемая сигнатура восстановления параметров.

При приеме корректной сигнатуры в соответствующем sub-индексе устройство восстановит свои параметры по умолчанию и подтвердит передачу SDO (инициирует ответ на загрузку). Если восстановление прошло неудачно, устройство ответит Abort SDO Transfer (код abort: 0606 0000h). Если записана ошибочная сигнатура, устройство отклонит восстановление параметров по умолчанию и ответит Abort SDO Transfer (код abort: 0800 002xh).

Значения по умолчанию станут достоверными после сброса устройства(сброс узла для sub-индексов 1h – 7Fh, сброс коммуникации для sub-индекса 2h), или после выключения и последующего включения питания.

CiA301 restore procedure fig58

Рис. 58. Процедура восстановления.

При доступе на чтение по соответствующему sub-индексу устройство предоставит информацию по своей возможности восстановления параметров в следующем формате:

           MSB                                LSB

Биты 31-1 0
  Зарезервировано (==0) 0/1

Рис. 59. Структура доступа на чтение восстановления значений по умолчанию.

Таблица 51. Структура доступа на чтение восстановления.

Бит Значение Что означает
31 - 1 0 Зарезервировано (==0)
0 0 Устройство не восстанавливает параметры по умолчанию
1 Устройство восстанавливает параметры

ОПИСАНИЕ ОБЪЕКТА

INDEX 1011h
Name restore default parameters (восстановление параметров по умолчанию)
Object Code ARRAY
Data Type UNSIGNED32
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) largest subindex supported (самый большой поддерживаемый sub-индекс)
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 1h – 7Fh
Default Value No
Sub-индекс 1h
Description (описание) restore all parameters (восстановление всех параметров)                         
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (рис. 57)
Default Value No
Sub-индекс 2h
Description (описание) восстановление параметров коммуникации по умолчанию                       
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (рис. 57)
Default Value No
Sub-индекс 3h
Description (описание) восстановление параметров приложения по умолчанию                          
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (рис. 57)
Default Value No
Sub-индекс 4h - 7Fh
Description (описание) восстановление параметров производителя по умолчанию                      
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (рис. 57)
Default Value No

Индекс 1012h определяет COB-ID объекта метки времени (Time-Stamp Object, TIME). Кроме того, это определяет, является ли устройство потребителем TIME, или оно генерирует TIME. Структура этого объекта показана на рис. 60 и в таблице 52.

                              MSB                                                                                    LSB

Биты 31 30 29 28-11 10-0
11-битный CAN-ID 0/1 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-битный ID
29-битный CAN-ID 0/1 0/1 1 29-битный ID

Рис. 60. Структура элемента TIME COB-ID.

Таблица 52. Описание элемента TIME COB-ID.

Бит Значение Что означает
31 (MSB) 0 Устройство не потребляет сообщение TIME
1 Устройство потребляет сообщение TIME
30 0 Устройство не генерирует сообщение TIME
1 Устройство генерирует сообщение TIME
29 0 11-битный ID (CAN 2.0A)
1 29-битный ID (CAN 2.0B)
28 - 11 0 Тут все нули, если бит 29 == 0
X Если бит 29 == 1, то здесь находятся биты 28..11 для 29-битного TIME COB-ID
10 - 0 (LSB) X Биты 10..0 TIME COB-ID

Биты 29, 30 могут быть статическими (не изменяемыми). Если устройство не может генерировать сообщения TIME, то попытка установить бит 30 вызовет в ответ сообщение abort (код abort: 0609 0030h). Устройства, поддерживающие только стандартный тип фрейма CAN, в ответ на попытку установить бит 29 отвечают сообщением abort message (abort code: 0609 0030h). Не разрешено менять биты 0-29, хотя объект существует (бит 30=1).

ОПИСАНИЕ ОБЪЕКТА

INDEX 1012h
Name COB-ID time stamp message (идентификатор CAN объекта/сообщения метки времени)
Object Code VAR
Data Type UNSIGNED32
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32
Default Value 100h

Этот объект содержит метку времени с разрешающей способностью 1 мкс (см. 9.3.2). Она может быть отображена на PDO, чтобы определить сообщение метки времени высокого разрешение (обратите внимание, тип данных стандартного сообщения метки времени TIME фиксирован). Для метки времени высокой точности должно быть специальное применение.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1013h
Name high resolution time stamp (метка времени высокой точности)
Object Code VAR
Data Type UNSIGNED32
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) rw
PDO Mapping Optional (не обязательно)
Value Range UNSIGNED32
Default Value 0

Индекс 1014h задает COB-ID Emergency Object (EMCY, объект аварии). Структура этого объекта показана на рис. 61.

                              MSB                                                                                    LSB

Биты 31 30 29 28-11 10-0
11-битный CAN-ID 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-битный ID
29-битный CAN-ID 0/1 0 1 29-битный ID

Рис. 61. Структура элемента идентификатора EMCY.

Таблица 53. Description of EMCY COB-ID entry.

Бит Значение Что означает
31 (MSB) 0 EMCY существует / допустим
1 EMCY не существует / недопустим
30 0 Зарезервировано (здесь всегда 0)
29 0 11-битный ID (CAN 2.0A)
1 29-битный ID (CAN 2.0B)
28 - 11 0 Тут все нули, если бит 29 == 0
X Если бит 29 == 1, то здесь находятся биты 28..11 для 29-битного EMCY COB-ID
10 - 0 (LSB) X Биты 10..0 EMCY COB-ID

Устройства, поддерживающие только стандартный тип фрейма CAN, при попытке установить бит 29 ответят сообщением abort (abort code: 0609 0030h). Если объект EMCY существует (когда бит 31==0), не разрешается менять биты 0-29.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1014h
Name COB-ID Emergency message (идентификатор CAN объекта/сообщения аварии)
Object Code VAR
Data Type UNSIGNED32
Category Conditional (зависит от условия): Mandatory (обязательно), если поддерживается EMCY.

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) ro, опционально rw
PDO Mapping No
Value Range UNSIGNED32
Default Value 80h + Node-ID

С помощью этого элемента можно настроить время запрета/подавления (inhibit time) для сообщения EMCY. Если этот элемент существует в OD, то он должен быть записываемым. Время задается в единицах 100 мкс.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1015h
Name Inhibit Time EMCY (время запрета передачи EMCY)
Object Code VAR
Data Type UNSIGNED16
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED16
Default Value 0

Этот параметр определяет ожидаемое время цикла сердцебиения для потребителя (Heartbeat Time), поэтому оно должно быть больше, чем соответствующее время сердцебиения продюсера, который генерирует этот heartbeat. Мониторинг запускается после приема первого heartbeat. Если consumer heartbeat == 0, то соответствующий элемент не используется. Время должно быть числом, кратным 1 мс.

                              MSB                                                                     LSB

Биты 31-24 23-16 15-0
Значение зарезервировано (==0) Node-ID heartbeat time
Закодировано как - UNSIGNED8 UNSIGNED16

Рис. 62. Структура элемента Consumer Heartbeat Time.

При попытке сконфигурировать несколько времен consumer heartbeat, не равных 0 для одного и того же Node-ID, устройство оборвет загрузку SDO с выдачей abort code 0604 0043h.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1016h
Name Consumer Heartbeat Time (время потребителя heartbeat)
Object Code ARRAY
Data Type UNSIGNED32
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) number entries (количество записей в массиве)              
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 1 – 127
Default Value No
Sub-индекс 1h
Description (описание) Consumer Heartbeat Time (время потребителя heartbeat)
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (рис. 62)
Default Value 0
Sub-индекс 2h – 7Fh
Description (описание) Consumer Heartbeat Time (время потребителя heartbeat)
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (рис. 62)
Default Value No

Этот параметр определяет время цикла сердцебиения. Heartbeat time равно 0, если это не используется. Время должно быть указано значением, кратным 1 мс.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1017h
Name Producer Heartbeat Time (время поставщика heartbeat)
Object Code VAR
Data Type UNSIGNED16
Category Conditional (зависит от условия): Mandatory (обязательно, если не поддерживается node guarding)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED16
Default Value 0

Объект с индексом 1018h содержит общую информацию об устройстве. Vendor ID (sub-индекс 1h) содержит уникальное значение, выделенное каждому производителю. Код продукта Product code (sub-индекс 2h), зависящий от производителя, идентифицирует определенную версию устройства. Номер ревизии Revision number (sub-индекс 3h), зависящий от производителя, состоит из major-номера ревизии и minor-номера ревизии. Номер major идентифицирует определенное поведение в CANopen. Если функциональность CANopen расширена, то major revision инкрементируется. Номер minor revision идентифицирует разные версии с одинаковым поведением CANopen.

MSB                                                                                                                                         LSB

major revision number (старший номер ревизии) minor revision number (младший номер ревизии)

Рис. 63. Структура Revision number.

Серийный номер Serial number (sub-индекс 4h), зависящий от производителя, идентифицирует определенное устройство.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1018h
Name Identity Object (объект идентификации)
Object Code RECORD
Data Type Identity
Category Mandatory (наличие обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) number entries (количество полей в записи)              
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 1 .. 4
Default Value No
Sub-индекс 1h
Description (описание) Vendor ID (идентификатор производителя)               
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range UNSIGNED32
Default Value No
Sub-индекс 2h
Description (описание) Product code (код изделия)                                       
Entry Category Optional (наличие не обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range UNSIGNED32
Default Value No
Sub-индекс 3h
Description (описание) Revision number (номер ревизии)                             
Entry Category Optional (наличие не обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range UNSIGNED32
Default Value No
Sub-индекс 4h
Description (описание) Serial number (серийный номер)                               
Entry Category Optional (наличие не обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range UNSIGNED32
Default Value No

Чтобы описать используемые в устройстве объекты SDO, введен тип данных параметра SDO. Этот тип данных имеет индекс 22h в OD. Его структура описана в 9.5.4.

Примечание переводчика: обычно сервер SDO присутствует в подчиненных узлах CANopen (slave), чтобы можно было читать/записывать любые элементы OD. Таким образом, чаще всего сервер SDO используется в slave-устройствах для их конфигурирования, однако иногда SDO применяют для передачи прикладных данных или перепрошивки firmware устройства. В этой спецификации указано, что наличие сервера на подчиненном устройстве является обязательным, однако мне попадались устройства, у которых не было вообще поддержки сервера SDO. Логически это выглядит допустимым для простейших устройств CANopen, которые не позволяют менять свою конфигурацию и читать её. В таком случае для мастера сети CANopen должно быть предоставлено полное описание этого подчиненного устройства в виде соответствующего файла *.eds. Если выкинуть объекты SDO, то код устройства CANopen можно кардинально упростить.

Количество поддерживаемых элементов в записи объекта SDO указано по sub-индексу 0h. Значения по sub-индексам 1h и 2h задают COB-ID для этого SDO. Sub-индекс 3h предоставляет сервер SDO в случае, если запись описывает SDO для которого это устройство клиент, и дает клиенту SDO, если запись описывает SDO, для которого это устройство сервер.

                              MSB                                                                                    LSB

Биты 31 30 29 28-11 10-0
11-битный CAN-ID 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-битный ID
29-битный CAN-ID 0/1 0 1 29-битный ID

Рис. 64: Структура элемента SDO COB-ID.

Таблица 54. Описание SDO COB-ID.

Бит Значение Что означает
31 (MSB) 0 SDO существует / допустим
1 SDO не существует / недопустим
30 0 Зарезервировано (здесь всегда 0)
29 0 11-битный ID (CAN 2.0A)
1 29-битный ID (CAN 2.0B)
28 - 11 0 Тут все нули, если бит 29 == 0
X Если бит 29 == 1, то здесь находятся биты 28..11 для 29-битного SDO COB-ID
10 - 0 (LSB) X Биты 10..0 SDO COB-ID

SDO допустим, только если оба бита SDO-valid равны 0. Устройства, поддерживающие только стандартный тип фрейма, при попытке установить бит 29 ответят сообщением abort message (abort code: 0609 0030h). Эти объекты содержат параметры для объектов SDO, для которых это устройство является сервером. Если устройство поддерживает больше одного сервера SDO, то объект SDO по умолчанию должен находиться по индексу 1200h как первый сервер SDO. Этот элемент имеет доступ только для чтения2. Все дополнительные объекты сервера SDO по умолчанию недопустимы (invalid bit - см. таблицу 54), описание находится в последующих индексах. Не разрешено менять COB-ID, когда SDO существует.

Описание клиента SDO (sub-индекс 3h) является необязательным. Это не доступно для SDO по умолчанию (нет sub-индекса 3h по индексу 1200h), поскольку этот элемент только для чтения.

Примечание 2: должно гарантироваться, что идентификаторы COB-ID для SDO не могут быть изменены записью в OD.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1200h - 127Fh
Name Server SDO parameter (параметр сервера SDO)
Object Code RECORD
Data Type SDO Parameter
Category Conditional (зависит от условия):
   индекс 1200h: Optional (не обязательно)
   индексы 1201h - 127Fh: Mandatory (обязательно) для каждого дополнительно
      поддерживаемого сервера SDO

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) number entries (количество полей в записи)                          
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range Индекс 1200h: 2
Индексы 1201h .. 127F: 2 - 3
Default Value No
Sub-индекс 1h
Description (описание) COB-ID Client->Server (прием)                                              
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) Индекс 1200h: ro,
индексы 1201h .. 127Fh: rw
PDO Mapping No
Value Range UNSIGNED32 (таблица 54)
Default Value Индекс 1200h: 600h+Node-ID,
индексы 1201h .. 127Fh: запрещено
Sub-индекс 2h
Description (описание) COB-ID Server -> Client (передача)                                       
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) Индекс 1200h: ro,
индексы 1201h .. 127Fh: rw
PDO Mapping No
Value Range UNSIGNED32 (таблица 54)
Default Value Индекс 1200h: 580h+Node-ID,
индексы 1201h .. 127Fh: запрещено
Sub-индекс 2h
Description (описание) Node-ID of the SDO client (идентификатор узла клиента SDO)
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range 1h – 7Fh
Default Value No

Эти объекты содержат параметры для объектов SDO, для которых это устройство является клиентом. Если этот элемент поддерживается, то должны быть в наличии и все sub-индексы. Элементы начинаются с индекса 1280h. Эти элементы описаны в описании Server SDO Parameter. Все объекты клиента SDO по умолчанию недопустимы (invalid bit – см. таблицу 54).

ОПИСАНИЕ ОБЪЕКТА

INDEX 1280h - 12FFh
Name Client SDO parameter (параметр клиента SDO)
Object Code RECORD
Data Type SDO Parameter
Category Conditional (зависит от условия): Mandatory (обязательно) для каждого поддерживаемого клиента SDO

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) number entries (количество полей в записи)                          
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 3
Default Value 3
Sub-индекс 1h
Description (описание) COB-ID Client->Server (передача)                                          
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (таблица 54)
Default Value запрещено
Sub-индекс 2h
Description (описание) COB-ID Server -> Client (прием)                                             
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (таблица 54)
Default Value запрещено
Sub-индекс 3h
Description (описание) Node-ID of the SDO server (идентификатор узла сервера SDO)
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32 (таблица 54)
Default Value No

Здесь содержаться коммуникационные параметры для объектов PDO, которые устройство может принимать. Тип коммуникационного параметра PDO (PDO communication parameter, 20h) описан в 9.5.4. Sub-индекс 0h содержит количество достоверных элементов в записи коммуникации. Это значение равно как минимум 2. Если поддерживается время запрета (inhibit time), то значение будет 3. По sub-индексу 1h размещается COB-ID для PDO. Этот элемент должен быть определен как UNSIGNED32, чтобы обслужить как 11-битные идентификаторы CAN (CAN 2.0A), так и 29-битные идентификаторы CAN (CAN 2.0B). Элемент должен быть интерпретирован, как определено на рис. 65 и в таблице 55.

                              MSB                                                                                 LSB

Биты 31 30 29 28-11 10-0
11-битный CAN-ID 0/1 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-битный ID
29-битный CAN-ID 0/1 0/1 1 29-битный ID

Рис. 65. Структура элемента PDO COB-ID.

Таблица 55. Описание записи PDO COB-ID.

Бит Значение Что означает
31 (MSB) 0 PDO существует / допустим
1 PDO не существует / недопустим
30 0 Для этого PDO разрешен RTR
1 Для этого PDO не разрешен RTR
29 0 11-битный ID (CAN 2.0A)
1 29-битный ID (CAN 2.0B)
28 - 11 0 Тут все нули, если бит 29 == 0
X Если бит 29 == 1, то здесь находятся биты 28..11 для 29-битного PDO COB-ID
10 - 0 (LSB) X Биты 10..0 PDO COB-ID

Бит PDO valid/not valid (допустим/не допустим) позволяет выбрать, какие PDOs используются в рабочем состоянии (operational). Могут быть объекты PDO, полностью сконфигурированные (например по умолчанию), но не используемые, и тогда они устанавливаются в состояние "not valid" (удалены). Эта функция нужна для устройств, которые поддерживают больше чем 4 RPDO или 4 TPDO, потому что каждое устройство имеет только идентификаторы по умолчанию для первых четырех RPDO/TPDO. Устройства, поддерживающие только стандартный тип фрейма CAN, или которые не поддерживают фреймы Remote, при попытке установить бит 29 в 1 или бит 30 в 0 отвечает сообщением abort (abort code: 0609 0030h).

Не разрешено менять биты 0-29, в то время как PDO существует (бит 31=0). Тип передачи (sub-индекс 2) определяет характер передачи/приема PDO (см. 9.2.1.1). Таблица 56 описывает использование этой записи. При попытке поменять значение типа передачи на значение, которое не поддерживается устройством, будет сгенерировано сообщение abort (abort code: 0609 0030h).

Таблица 56. Описание типа передачи.

Тип передачи Символ синхронизации передачи PDO
Циклический Не циклический Синхронный Асинхронный RTR
0   x x    
1..240 x   x    
241..251 Зарезервировано
252     x   x
253       x x
254       x  
255       x  

Синхронный тип (Synchronous, типы передач 0-240 и 252) означает, что передача PDO должна быть связана с объектом SYNC, как это описано в 9.3. Преимущественно устройства используют SYNC как триггер для вывода или активации на базе предыдущего синхронного RPDO, соответственно для обновления данных, передаваемых при следующем синхронном TPDO. Подробности этого механизма зависят от типа устройства, что определено в профиле устройства, если это применимо.

Асинхронный тип (Asynchronous) означает, что передача PDO не связана с объектом SYNC. Тип передачи 0 означает, что сообщение должно передаваться синхронно с объектом SYNC, но не периодически.

Значение между 1 и 240 означает, что PDO передается синхронно и циклически. Тип передачи показывает количество появлений SYNC, которое нужно для срабатывания передач PDO. RPDO всегда срабатывают по следующему SYNC при приема данных, независимо от типов передачи 0 - 240.

Типы передачи 252 и 253 означают, что PDO передается только в ответ на RTR (remote transmission request, запрос передачи от другого узла сети). При типе передачи 252 данные обновляются (но не отправляются) немедленно после приема объекта SYNC. При типе передачи 253 данные обновляются в момент приема RTR (могут накладываться аппаратные и программные ограничения). Эти значения допустимы только для объектов TPDO. Тип передачи 254 для объектов TPDO означает, что событие приложения зависит от производителя (той части OD, которая зависит от производителя устройства). Тип передачи 255 означает, что событие приложения определено в профиле устройства. Объекты RPDO с таким типом выполняют срабатывание обновления отображенных данных в момент приема. Sub-индекс 3h содержит время запрета inhibit (этот элемент может отсутствовать). Это время задает минимальный интервал между передачами PDO. Значение задается в единицах 100 мкс. Не разрешено менять это значение, когда PDO существует (бит 31 у sub-индекса 1 равен 0).

Sub-индекс 4h зарезервирован. Он не должен быть реализован, в этом случае доступы на чтение или запись приведут к выдаче Abort SDO Transfer (abort code: 0609 0011h).

В режиме 254/255 дополнительно может использоваться время события (event time) для TPDO. Если существует таймер события (event timer) для TPDO (значение не равно 0), то истечение таймера считается событием. Таймер события истекает на интервалах, нацело делящихся на 1 мс, как это определено в элементе по sub-индексуindex 5h для TPDO. Это событие будет приводить к передаче этого TPDO в дополнение к событиям, определенным другим способом. Момент наступления события устанавливает таймер. Независимый от типа передачи таймер события RPDO используется для распознавания истечения RPDO.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1400h - 15FFh
Name receive PDO parameter (параметр PDO приема, RPDO)
Object Code RECORD
Data Type PDO CommPar
Category Conditional (зависит от условия): Mandatory (обязательно) для каждого поддерживаемого PDO

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) largest sub-index supported (самый большой поддерживаемый sub-индекс)
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 3
Default Value 2 – 5
Sub-индекс 1h
Description (описание) COB-ID used by PDO (идентификатор CAN, используемый этим PDO)         
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
rw, если поддерживается изменяемый COB-ID
PDO Mapping No
Value Range UNSIGNED32 (таблица 55)
Default Value Индекс 1400h: 200h + Node-ID,
индекс 1401h: 300h + Node-ID,
индекс 1402h: 400h + Node-ID,
индекс 1403h: 500h + Node-ID,
индекс 1404h – 15FFh: запрещено
Sub-индекс 2h
Description (описание) transmission type (тип передачи)                                                              
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
rw, если поддерживается изменяемый тип передачи
PDO Mapping No
Value Range UNSIGNED8 (таблица 56)
Default Value Зависит от профиля устройства
Sub-индекс 3h
Description (описание) inhibit time (время запрета. Не используется для RPDO)                            
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED16
Default Value No
Sub-индекс 4h
Description (описание) compatibility entry (элемент совместимости)                                               
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED8
Default Value No
Sub-индекс 5h
Description (описание) event timer (таймер события)                                              
Entry Category Optional (наличие не обязательно). Не используется для RPDO                 
Access (тип доступа) rw
PDO Mapping No
Value Range 0 если не используется
UNSIGNED16
Default Value No

Содержит отображение для объектов PDO, которые устройство может принять. Тип параметра отображения PDO (PDO mapping parameter, 21h) описан в 9.5.4. Как обычно, sub-index 0h содержит количество допустимых элементов записи отображения. Это количество также равно количеству переменных приложения, которые должны быть переданы/приняты вместе с соответствующим PDO. The sub-indices from 1h to number of entries contain the information about the mapped application variables. Эти элементы описывают содержимое PDO их индексом, sub-индексом и длиной (рис. 66). Все 3 значения кодируются шестнадцатеричным числом. Элемент длины (length) содержит длину объекта в битах (1..40h). Этот параметр может использоваться для проверку общей длины отображения, он обязателен.

Структура элементов по sub-индексам 1h – 40h следующая:

MSB                                                                                                                       LSB

Индекс (16 бит)                                     sub-индекс (8 bit)     длина объекта (8 бит)

Рис. 66. Структура элемента PDO Mapping.

Если изменение PDO не может быть выполнено (например длина PDO превышена или клиент SDO попытался отобразить объект, который не может быть отображен), то устройство отвечает службой Abort SDO Transfer.

Sub-индекс 0 определяет допустимое количество объектов, которые имеют отображение. Для изменения отображения PDO сначала PDO должен быть удален, sub-индекс 0 должен быть установлен в 0 (отображение деактивировано). Затем объекты могут быть отображены заново. Когда отображается новый объект путем записи sub-индекса между 1 и 64, устройство может проверить, существует ли объект, указанный по индексу / sub-индексу. Если объект не существует, или объект не может быть отображен, то передача SDO должна быть оборвана службой Abort SDO Transfer с одним из кодов abort 0602 0000h или 0604 0041h.

После того, как все объекты отображены, sub-индекс 0 устанавливается в достоверное число отображенных объектов. В завершении будет создан PDO путем записи его коммуникационного параметра (communication parameter COB-ID). Когда sub-индекс 0 устанавливается в значение >0, устройство может проверить на допустимость новое отображение PDO перед тем, как передать ответ службе SDO. Если была определена ошибка, то устройство должно передать службу Abort SDO Transfer с одним из кодов abort 0602 0000h, 0604 0041h или 0604 0042h.

Когда читается sub-индекс 0, то будет возвращено актуальное количество отображенных объектов.

Если отображены типы данных (индексы 1h-7h), то они служат "фиктивными записями" (dummy entries). Соответствующие данные в PDO не оцениваются в устройстве. Эта опциональная функция полезна например для передачи данных для некоторых устройств, использующих один и тот же PDO, когда на каждом устройстве задействована своя часть от этого PDO. Невозможно создавать dummy mapping для TPDO.

Устройство, которое поддерживает динамическое отображение объектов PDO (dynamic mapping PDO), должно поддерживать это в состоянии PRE-OPERATIONAL. Если поддерживается динамическое отображение во время состояния OPERATIONAL, то клиент SDO отвечает за целостность данных.

CiA301 Principle PDO mapping fig67

Рис. 67. Принцип отображения PDO.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1600h – 17FFh
Name receive PDO mapping (отображение на PDO приема, RPDO)
Object Code RECORD
Data Type PDO Mapping (отображение объектов на PDO)
Category Conditional (зависит от условия): Mandatory (обязательно) для каждого поддерживаемого PDO

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) количество отображенных на PDO объектов приложения   
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
rw, если поддерживается динамическое отображение
PDO Mapping No
Value Range 0: деактивировано
1 – 64: активировано
Default Value зависит от профиля устройства
Sub-индекс 1h – 40h
Description (описание) отображение на PDO n-ного объекта приложения
Entry Category Conditional, зависит от количества и размера привязанных
к этому PDO объектов.
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32
Default Value зависит от профиля устройства

Содержит параметры коммуникации для объектов PDO, которые устройство может передать. Тип коммуникационного параметра PDO (PDO communication parameter, 20h) описан в 9.5.4. Подробное описание элементов сделано в секции для Receive PDO Communication Parameter (1400h – 15FFh).

ОПИСАНИЕ ОБЪЕКТА

INDEX 1800h - 19FFh
Name transmit PDO parameter (параметр PDO передачи, TPDO)
Object Code RECORD
Data Type PDO CommPar
Category Conditional (зависит от условия): Mandatory (обязательно) для каждого поддерживаемого PDO

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) largest sub-index supported (самый большой поддерживаемый sub-индекс)
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 3
Default Value 2 – 5
Sub-индекс 1h
Description (описание) COB-ID used by PDO (идентификатор CAN, используемый этим PDO)         
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
rw, если поддерживается изменяемый COB-ID
PDO Mapping No
Value Range UNSIGNED32 (таблица 65)
Default Value Индекс 1800h: 180h + Node-ID,
индекс 1801h: 280h + Node-ID,
индекс 1802h: 380h + Node-ID,
индекс 1803h: 480h + Node-ID,
индекс 1804h – 18FFh: запрещено
Sub-индекс 2h
Description (описание) transmission type (тип передачи)                                                              
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
rw, если поддерживается изменяемый тип передачи
PDO Mapping No
Value Range UNSIGNED8 (таблица 55)
Default Value Зависит от профиля устройства
Sub-индекс 3h
Description (описание) inhibit time (время запрета)                                                                      
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED16
Default Value Зависит от профиля устройства
Sub-индекс 4h
Description (описание) зарезервировано                                                                                     
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED8
Default Value No
Sub-индекс 5h
Description (описание) event timer (таймер события)                                                                    
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range 0 если не используется
UNSIGNED16
Default Value Зависит от профиля устройства

Содержит отображение для объектов PDO, которые устройство может передать. Тип параметра отображения PDO (PDO mapping parameter, 21h) описан в 9.5.4. Подробное описание элементов сделано в секции для Receive PDO Mapping Parameter (1600h – 17FFh).

ОПИСАНИЕ ОБЪЕКТА

INDEX 1A00h - 1BFFh
Name transmit PDO mapping (отображение на PDO передачи, TPDO)
Object Code RECORD
Data Type PDO Mapping (отображение объектов на PDO)
Category Conditional (зависит от условия): Mandatory (обязательно) для каждого поддерживаемого PDO

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) количество отображенных на PDO объектов приложения   
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
rw, если поддерживается динамическое отображение
PDO Mapping No
Value Range 0: деактивировано
1 – 64: активировано
Default Value зависит от профиля устройства
Sub-индекс 1h – 40h
Description (описание) отображение на PDO n-ного объекта приложения
Entry Category Conditional, зависит от количества и размера привязанных
к этому PDO объектов.
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32
Default Value зависит от профиля устройства

[10. Рекомендации по реализации]

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

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

Таймауты. Так как COB-ы могут быть проигнорированы, может быть так, что ответ подтверждаемой службы никогда не поступит. Чтобы разобраться с этой ситуацией, реализация может после определенного количества времени показать на это пользователю службы (время вышло, time-out). Таймаут является не подтверждением этой службы. Таймаут показывает, что служба еще не завершена. Приложение должно обработать эту ситуацию. Значения таймаута считаются специфичными для реализации, и не попадают в обсуждение этой спецификации. Однако рекомендуется, чтобы реализация позволяла подстраивать эти значения таймаута, чтобы удовлетворить требованиям приложения.

[11. Приложение A (норматив)]

Здесь описана дополнительная функциональность подчиненных устройств NMT CANopen (версия 2.0.1, 13 февраля 2002). В этом нормативном приложении описана функциональность для ведомых устройств NMT CANopen, которая была первоначально определена в платформе CiA DSP-302 для программируемых устройств CANopen.

11.1. Дополнительные элементы OD. Дополнительные записи:

Индекс Объект Имя
0024h DEFSTRUCT Debugger Par
0025h DEFSTRUCT Command Par

Дополнительные объекты коммуникации:

Индекс Объект Имя Тип Acc.(3) M/O
Конфигурация устройства
1020h ARRAY Проверка конфигурации UNSIGNED32 rw O
Хранилище EDS
1021h VAR Store EDS DOMAIN rw O
1022h VAR Формат хранилища UNSIGNED8 rw O
Команда и приглашение OS
1023h RECORD OS Command Command Par rw O
1024h VAR OS Command Mode UNSIGNED8 wo O
1025h RECORD OS Debugger Interface Debugger Par rw O
1026h ARRAY OS Prompt UNSIGNED8 rw O
Модульные устройства
1027h ARRAY Список модулей UNSIGNED16 ro M/O*
Дополнительные объекты
1028h ARRAY Emergency Consumer UNSIGNED32 rw O
1029h ARRAY Поведение при ошибке UNSIGNED8 rw O
Мультиплексированный PDO
1FA0h - 1FCFh RECORD Object Scanner List UNSIGNED32 rw O
1FD0h - 1FFFh RECORD Object Dispatching List UNSIGNED64 rw O

Примечания:

M/O означает Mandatory/Optional (обязательно/не обязательно).
* Mandatory (обязательно) для модульных устройств; иначе не обязательно.

3 Тип доступа, перечисленный здесь, может меняться для определенных sub-индексов. См. подробную спецификацию объекта.

11.2. Конфигурация устройства

11.2.1. Boot-up configuration process. Параметр в объекте 1010h для сохранения конфигурации slave-устройства недостаточна для того, чтобы CANopen Manager определил, что slave-устройство восстановилось в своей последней конфигурации после сброса, и смог немедленно ввести его в состояние Operational. Чтобы CANopen Manager мог определить, нужно ли переконфигурировать slave-устройство, должны использоваться следующие опциональные объекты:

Если устройство поддерживает сохранение параметров в энергонезависимой памяти, инструментарий конфигурирования сети или CANopen manager могут проверить (verify) конфигурацию после сброса устройств и определить, требуется ли повторное конфигурирование. Утилита конфигурации должна сохранить дату и время в этом объекте, и должна сохранить те же значения в DCF. Теперь утилита конфигурации позволит устройству сохранить свою конфигурацию путем записи по индексу 1010h и sub-индексу 1h сигнатуры "save". После сброса устройство должно восстановить последнюю конфигурацию и сигнатуру - автоматически или по запросу. Если любая другая команда изменит значения конфигурации загрузки (boot-up configuration values), устройство должно сбросить объект Verify Configuration в 0.

Configuration Manager сравнивает сигнатуру и конфигурацию со значением из DCF, и принимает решение - нужно или нет повторно конфигурировать устройство.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1020h
Name Verify configuration (проверка конфигурации)
Object Code ARRAY
Data Type UNSIGNED32
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) количество поддерживаемых элементов   
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 2
Default Value 2
Sub-индекс 1h
Description (описание) Configuration date (дата конфигурации)   
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32
Default Value No
Sub-индекс 2h
Description (описание) Configuration time (время конфигурации) 
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32
Default Value No

Значение Configuration date должно содержать количество дней от 1 января 1984 года. Configuration time должно содержать количество миллисекунд после полуночи.

Совет по применению: использование этого объекта позволяет значительно ускорить boot-up process. Если он используется, системный интегратор должен полагать, что пользователь мог поменять значение конфигурации и впоследствии активировать конфигурацию команды сохранения 1010h без изменения значения 1020h. Таким образом, системный интегратор должен гарантировать 100%-е последовательное использование этой функции.

11.2.2. Хранилище EDS. Для некоторых устройств можно хранить внутри себя EDS. Это дает некие преимущества:

• У производителя нет проблем с распространением EDS на дисках.
• Обслуживание разных версий EDS для разных версий ПО меньше подвержено ошибкам, если они сохранены вместе.
• Полные настройки сети могут быть сохранены в сетевом окружении. Это делает задачу анализа или переконфигурирования сети проще для инструментария и более прозрачной для пользователей.

EDS может быть сохранен в следующем объекте:

ОПИСАНИЕ ОБЪЕКТА

INDEX 1021h
Name Store EDS (хранилище EDS)
Object Code VAR
Data Type DOMAIN
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) rw
PDO Mapping No
Value Range No
Default Value No

Имя файла сохранять не нужно, поскольку каждый EDS содержит свое собственное имя файла.

Объект 1022h описывает формат хранилища. Это позволяет использовать сжатые форматы.

Value Format
0 ASCII, без сжатия
1-255 Зарезервировано

Устройство всегда может сохранять файл сжатым внутри себя. Этот объект описывает внешнее поведение.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1022h
Name Storage format (формат хранения)
Object Code VAR
Data Type UNSIGNED16
Category Conditional (наличие зависит от условия): Mandatory (обязательно), если поддерживается Store EDS.

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED8
Default Value No

11.3. Команда и приглашение OS. Многие операционные системы (OS) программируемых устройств поддерживают приглашение ввода команды в консоли (console prompt). Команды могут быть введены пользователем с клавиатуры или через любое другое пользовательское устройство ввода (например, с помощью программного обеспечения PC с командами, подаваемыми мышью в графическом интерфейсе). Чтобы позволить выполнять конфигурирование через сеть и отладку через сеть для такого узла, определены и введены в OD объекты "OS Command/Debugger Interface" (интерфейс команды и отладки операционной системы). Обрабатываемые устройством команды зависят от от производителя. Наиболее распространено использование 2 типов команд. Для многих PLC (программируемый логический контроллер) интерпретатор команд ожидает на входе двоичный поток данных, где закодирована команда и дополнительные бинарные данные наподобие CRC и т. п. Другая концепция - символьный ввод (один символ команды или текстовая строка команды).

См. также описание загрузки программы в CiA DSP-302.

11.3.1. OS command. Объект команды OS может использоваться как интерфейс команд для программируемых устройств. Содержимое команды может быть ASCII или двоичными данными, и это полностью зависит от производителя. Система хоста помещает команду в объект OS command, который должен иметь тип Command Par:

Индекс sub-индекс Поле в OS Command Тип данных
0023h 0h Количество поддерживаемых элементов UNSIGNED8
  1h Команда OCTET_STRING
  2h Статус:
0: последняя команда выполнена, нет ошибок, нет подтверждения.
1: последняя команда выполнена, нет ошибок, есть подтверждение.
2: последняя команда выполнена, ошибка, нет подтверждения.
3: последняя команда выполнена, ошибка, есть подтверждение.
4..254: не определено, зарезервировано.
255: в настоящий момент выполняется команда.
UNSIGNED8
  03h Подтверждение OCTET_STRING

ОПИСАНИЕ ОБЪЕКТА

INDEX 1023h
Name OS command (команда операционной системы)
Object Code RECORD
Data Type Command Par
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) количество поддерживаемых элементов   
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 3
Default Value 3
Sub-индекс 1h
Description (описание) Command (команда)                                
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range No
Default Value No
Sub-индекс 2h
Description (описание) Status (статус, состояние команды)          
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range UNSIGNED8
Default Value No
Sub-индекс 3h
Description (описание) Reply (подтверждение, ответ на команду) 
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range No
Default Value No

Если устройство реализовало эту функцию, то эти элементы являются обязательными, дополнительные элементы зависят от производителя. Может быть введена новая команда, если Status в диапазоне 0..3: команда и все параметры должны быть переданы в одном блоке по sub-индексу 1h. Выполнение команды должно начаться немедленно после завершения передачи. Хост опрашивает sub-индекс 2h, пока он не получит значение 0 .. 3. Может быть подтверждение на передачу, если Status 1 или 3. Устройство должно вернуть тот же самый ответ, если Reply запрошен больше одного раза, или может поменять Status с 1 на 0 или с 3 на 2, если оно не сохраняет в буфере подтверждение.

Следующий элемент OD управляет рабочим режимом OS command:

ОПИСАНИЕ ОБЪЕКТА

INDEX 1024h
Name OS command mode (режим команды операционной системы)
Object Code VAR
Data Type UNSIGNED8
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Access (тип доступа) wo
PDO Mapping No
Value Range UNSIGNED8
0: выполнить следующую команду немедленно.
1: сохранить следующую команду в буфере.
2: выполнить команду из буфера.
3: оборвать текущую команду и все команды в буфере.
4 .. 255: специфично для производителя.
Default Value No

Установлено, что объект OD OS command представляет наиболее свежую информацию в очереди, и этот объект управляет выполнением команд из этой очереди.

11.3.2. OS debugger interface. Объект интерфейса отладчика это двоичный интерфейс команд для агентов отладки программируемых устройств. Содержимое команд зависит от производителя. Этот объект позволяет пользователю подключиться удаленным отладчиком. Тип данных этого объекта Debugger Par:

Индекс sub-индекс Поле в OS Debugger Interface Тип данных
0025h 0h Количество поддерживаемых элементов UNSIGNED8
  1h Команда OCTET_STRING
  2h Статус:
0: последняя команда выполнена, нет ошибок.
1: последняя команда выполнена, ошибка.
255: в настоящий момент выполняется команда.
UNSIGNED8
  03h Подтверждение OCTET_STRING

ОПИСАНИЕ ОБЪЕКТА

INDEX 1025h
Name OS debugger interface (режим отладчика операционной системы)
Object Code RECORD
Data Type Debugger Par
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) количество поддерживаемых элементов   
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 3
Default Value 3
Sub-индекс 1h
Description (описание) Command (команда)
Entry Category Mandatory (наличие обязательно)            
Access (тип доступа) rw
PDO Mapping No
Value Range No
Default Value No
Sub-индекс 2h
Description (описание) Status (состояние)
Entry Category Mandatory (наличие обязательно)            
Access (тип доступа) ro
PDO Mapping No
Value Range UNSIGNED8
Default Value No
Sub-индекс 3h
Description (описание) Reply (подтверждение, ответ)
Entry Category Mandatory (наличие обязательно)            
Access (тип доступа) ro
PDO Mapping No
Value Range No
Default Value No

Если в устройстве реализована эта функция, то элементы 00h-03h являются обязательными, наличие дополнительных элементов зависит от производителя. Для последовательности команд см. секцию OS Command.

11.3.3 OS prompt. Объект приглашения операционной системы это управляемый командами интерфейс программируемых устройств. Содержимое команд зависит от производителя. Этот объект позволяет пользователю осуществить удаленное управление с клавиатуры.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1026h
Name OS prompt (приглашение командной строки операционной системы)
Object Code ARRAY
Data Type UNSIGNED8
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) количество поддерживаемых элементов   
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 2 - 3
Default Value No
Sub-индекс 1h
Description (описание) StdIn (стандартный ввод)
Entry Category Mandatory (наличие обязательно)            
Access (тип доступа) wo
PDO Mapping Возможно
Value Range UNSIGNED8
Default Value No
Sub-индекс 1h
Description (описание) StdIn (стандартный ввод)
Entry Category Mandatory (наличие обязательно)            
Access (тип доступа) wo
PDO Mapping Возможно
Value Range UNSIGNED8
Default Value No

Sub-индекс 1h StdIn можно использовать для передачи одного символа в устройство через SDO или PDO. Каждый новый символ добавляется к внутренней очереди ввода. Ответы от устройства выводятся через sub-индекс 2h StdOut. Этот объект может быть отображен на управляемый событиями (event-driven) PDO или опрашиваться через SDO. Sub-индекс 3h StdErr может использоваться для вывода ошибок. Этот объект также может быть отображен на event-driven PDO или опрашиваться через SDO.

Приложение отвечает за обработку очистки очередей (чтобы не было переполнений).

[11.4. Мультиплексированные объекты PDO]

11.4.1. Протокол MPDO. Этот протокол используется для реализации служб MPDO (Multiplexed PDO). Продюсер MPDO посылает данные, и мультиплексор показывает адрес источника или адрес назначения.

CiA301 Multiplexed PDO protocol

d должно содержать передаваемые данные. Это значение всегда должно быть заполнено до 32 бит*.
m должно содержать мультиплексор (индекс и sub-индекс) переменной в OD.

Примечание *: ограничение, связанное с только 32-битных передач не будет на практике создавать проблем, поскольку все участвующие устройства знают типы данных (и их размеры) связанных с ними объектов.

MSB f первого байта должно содержать флаг формата, и addr должно содержать поле адреса, которое может использоваться в следующих комбинациях:

f addr Использование
0 0 Зарезервировано
0 1-127 Адресация источника. Поде addr это Node ID одиночного продюсера. Мультиплексором является индекс и sub-индекс OD продюсера.
1 0 Адресация места назначения. Потребитель (consumer) это группа.
1 1-127 Адресация места назначения. Поле addr это Node ID одиночного потребителя. Мультиплексором является index и sub-индекс OD потребителя.

11.4.1.1. Destination Address Mode (DAM). Поле addr и поле m MPDO относится к потребителю (consumer). Это позволяет получить доступ к OD потребителя через SDO. С addr = 0, это позволяет делать множественную адресацию (multicasting) и широковещание (broadcasting), чтобы записывать в OD больше чем одного узла одновременно, без того, чтобы на каждом одиночном объекте имелся PDO.

Инициация DAM-MPDO зависит от приложения, примерно так же, как это происходит для объектов SDO.

11.4.1.2. Source Address Mode (SAM). Поле addr и поле m MPDO относится к продюсеру. Для каждого узла разрешен только один продюсер MPDO такого типа.

Тип передачи должен быть 254 или 255.

Продюсер использует Object Scanner List чтобы знать, какие объекты отправлять.

Потребитель использует Object Dispatcher List в качестве справочника (cross reference).

11.4.2. Элементы OD

11.4.2.1. PDO Mapping Record. Sub-индекс 0 показывает количество отображенных расширенных объектов. Допустимый диапазон для не мультиплексированных PDO составляет от 0 до 64. Значение 255 показывает DAM-MPDO, значение 254 показывает SAM-MPDO.

Для SAM следующие элементы в MR не имеют значения.

Для DAM первый объект описывает локальный объект (здесь может быть отображен только один объект в MPDO).

Здесь разрешены дополнительные значения для объектов 1600h – 17FFh и 1A00h – 1BFFh sub-индекс 0h:

0 .. 64: допустимый диапазон для количества отображенных объектов.
254: форматировано как SAM-MPDO.
255: форматировано как DAM-MPDO.

11.4.2.2. Object Dispatching List. Потребитель SAM-MPDO использует Object Dispatching List как справочник/набор ссылок (cross reference) между сетевым объектом (remote object) продюсера и локальным OD.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1FD0h – 1FFFh
Name Object dispatching list (список диспетчеризации объектов)
Object Code ARRAY
Data Type UNSIGNED64
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) количество элементов   
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 1 – FEh
Default Value No
Sub-индекс 1h
Description (описание) Dispatch_1
Entry Category Mandatory (наличие обязательно) 
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED64
Default Value No
Sub-индекс 2h – FEh
Description (описание) Dispatch_2 – Dispatch_254
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED64
Default Value No

Поля должны иметь следующую структуру:

          MSB                                                                                                                       LSB

Биты 63-56 55-40 39-32 31-16 15-8 7-0
поле Размер блока Локальный индекс Локальный sub-индекс Индекс отправителя Sub-индекс отправителя Node-ID отправителя

Каждый элемент в таблице описывает, как данные, принятые MPDO, переносятся в локальный OD. Если поле флага 0 и Node ID продюсера, индекс продюсера и sub-индекс продюсера соответствуют элементу, то данные должны быть записаны в локальный объект, адресованный по локальному индексу и локальному sub-индексу этого элемента.

Параметр размера блока позволяет использовать идущие друг за другом sub-индексы. Пример: если sub-индекс 1-9 отправителя должен быть отображен на sub-индекс 11-19 получателя, то этот диапазон определяется так:

sub-индекс отправителя = 1
локальный sub-индекс = 11
размер блока = 9

Элементы таблицы, которые не сконфигурированы, должны содержать значение 0.

11.4.2.3. Object Scanner List. Продюсер SAM-MPDO использует Object Scanner List для конфигурирования, какие объекты должны передаваться. Тип передачи дается соответствующим полем используемого PDO.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1FA0h – 1FCFh
Name Object scanner list
Object Code ARRAY
Data Type UNSIGNED32
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) количество элементов   
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 1 – FEh
Default Value No
Sub-индекс 1h
Description (описание) Scan_1
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32
Default Value No
Sub-индекс 2h – FEh
Description (описание) Scan_2 – Scan_254
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32
Default Value No

Поля должны иметь следующую структуру:

          MSB                                           LSB

Биты 31-24 23-8 7-0
поле Размер блока Индекс Sub-индекс

Каждый элемент в таблице описывает объект, который может быть отправлен через MPDO. Можно описать идущие друг за другом sub-индексы установкой параметра размер блока в количество sub-индексов.

Элементы таблицы, которые не сконфигурированы, должны содержать значение 0.

11.4.3. Реализация объектов MPDO

Продюсер MPDO. Если на узле указано для передачи один или большее количество MPDO, то должны применяться следующие правила реализации:

• Если это SAM-MPDO, то используется Object Scanner List вместе с типом передачи, чтобы определить, какой объект отправлять (для передачи должен быть только один SAM-MPDO).
• Если это DAM-MPDO, то обычно локальный объект может быть указан в объекте Mapping Parameter Set. Объект назначения (Destination Object) и Node ID могут быть заданы в зависимости от приложения.

MPDO Consumer. Если узел принимает MPDO (которые известны через объект Mapping Parameter Set), то должны применяться следующие правила реализации:

• Если это DAM-MPDO, то он записывает принятые данные в указанный элемент OD.
• Если это SAM-MPDO, то он использует Object Dispatching List в качестве навигационного справочника (cross reference).

11.4.4. Группы, безопасность и инструментарий конфигурирования сети. Описанная схема группового обмена сообщениями очень эффективна, когда используется только один DAM-MPDO на группу. Узел, который является потребителем группы, должен только получить MPDO для той группы. Нет ограничений на количество групп, кроме ограничения, которое накладывается количеством свободных COB-ID для объектов PDO.

На уровне CANopen нет никакой попытки принять меры против неправильного употребления объекта PDO, используемого в целях рассылки групповых сообщений.

11.4.5. Как показываются в EDS возможности MPDO. Для прозрачного использования инструментария инструментария конфигурирования нужно знать, поддерживает ли устройство механизм группы. Это должно быть помечено в EDS внутри секции DeviceInfo, в boolean-элементе GroupMessaging.

11.5.1. Предпосылки. Актуальная спецификация EDS позволяет описать модульные устройства. С этой функцией можно выполнить тест совместимости (Conformance Test) для таких устройств, без необходимости писать псевдо-EDS для конкретно подключенных модулей. Кроме того, можно описать эти устройства для планирования или конфигурации в независимых от производителя утилитах конфигурирования.

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

Предположим устройство расширителя шины (bus coupler device) и 3 имеющиеся в наличии типа модулей: Module Type A с 8 цифровыми выходами, Module Type B с цифровыми входами и Module Type C с комбинацией 8 входов и 8 выходов. Предположим, что ПО конфигурирования сканирует такое устройство, и определяет, что оно состоит из 8 цифровых входов и 8 цифровых выходов. Тогда нет возможности определить, каким образом был получен этот функционал - либо подключен только Module Type C, либо подключено 2 модуля, один Module Type A и еще один Module Type B.

Эта неоднозначность может создавать проблемы для пользователей. Такие случаи требуют дополнительных усилий по внедрению со стороны производителей устройств и поставщиков инструментария. Пользователи будут чувствовать, что CANopen слишком сложен для применения. Небольшое дополнение OD для устройств расширителя шины решит эту проблему.

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

11.5.2. Modular Devices (модульные устройства). Общий метод предоставить модульные устройства - использование устройства расширителя шины, которое позволяет подключать к себе несколько комбинаций модулей. Объект 1027h Module List описывает, какие конкретно модули подключены, и их количество.

ОПИСАНИЕ ОБЪЕКТА

INDEX 027h
Name Module list (список модулей)
Object Code ARRAY
Data Type UNSIGNED16
Category Conditional (зависит от условия): обязательно, если поддерживаются модульные устройства.

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) количество подключенных модулей
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 1 – FEh
Default Value No
Sub-индекс 1h – FEh
Description (описание) Module_2 – Module_254
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED16
Default Value No

Идущие подряд друг за другом sub-индексы (1 ≤ N ≤ 254) описывают соответствующие модули в том порядке, в котором они были подключены к устройству. Каждый элемент OD содержит число, которое идентифицирует модуль. Для этого число должно быть уникальным в пределах всех типов модулей, которые могут быть подключены к устройству типа расширителя шины.

В EDS (см. стандарт DSP-306) объект 1027h появляется в списке SubExtension каждого модуля. Элемент DefaultValue должен содержать идентификационный номер.

11.6.1. Объект Emergency Consumer. Эти объекты определяют идентификаторы Emergency COB-ID, которые потребляет подчиненное устройство NMT. Структура этого объекта следующая:

                              MSB                                                                                  LSB

Биты 31 30 29 28-11 10-0
11-битный CAN-ID 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-битный ID
29-битный CAN-ID 0/1 0 1 29-битный ID

Бит Значение Что означает
31 (MSB) 0 EMCY существует / допустим
1 EMCY не существует / недопустим
30 0 Зарезервировано (здесь всегда 0)
29 0 11-битный ID (CAN 2.0A)
1 29-битный ID (CAN 2.0B)
28 - 11 0 Тут все нули, если бит 29 == 0
X Если бит 29 == 1, то здесь находятся биты 28..11 для 29-битного EMCY COB-ID
10 - 0 (LSB) X Биты 10..0 EMCY COB-ID

Устройства, поддерживающие только стандартный тип фрейма, при попытке установить бит 29 ответят сообщением abort message (abort code: 0609 0030h). Не разрешено менять биты 0-29, когда объект существует (бит 31=0).

Sub-индекс относятся к соответствующему Node-ID.

ОПИСАНИЕ ОБЪЕКТА

INDEX 1028h
Name Emergency Consumer (потребитель сообщений аварии)
Object Code ARRAY
Data Type UNSIGNED32
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) количество Emergency Consumer
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) ro
PDO Mapping No
Value Range 1 – 127
Default Value No
Sub-индекс 1h
Description (описание) Emergency Consumer 1
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32
Default Value No
Sub-индекс 2h – 7Fh
Description (описание) Emergency Consumer от 2 до 127
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED32
Default Value No

11.6.2. Объект Error Behaviour. Если в состоянии Operational была определена серьезная ошибка, то модуль должен автономно войти в состояние предварительной готовности (Pre-Operational). Если реализован объект 1029h (Error Behaviour) то устройство может быть сконфигурировано для альтернативного входа в состояние Stopped, или оставаться в текущем состоянии, когда произошел отказ в устройстве. Отказы (ошибки) устройства должны включать следующие ошибки коммуникации:

• Условия отключения шины (Bus-off conditions) интерфейса CAN
• Событие Life guarding с состоянием 'occurred' (событие произошло)
• Событие Heartbeat с состоянием 'occurred' (событие произошло)

Некоторые ошибки устройства могут быть вызваны его внутренними проблемами.

Значение поля Error Classes может быть следующим:

0 pre-operational (только если текущее состояние operational)
1 состояние не поменяется
2 stopped
3 .. 127 зарезервировано

ОПИСАНИЕ ОБЪЕКТА

INDEX 1029h
Name Error Behaviour (поведение при ошибке)
Object Code ARRAY
Data Type UNSIGNED8
Category Optional (наличие не обязательно)

ОПИСАНИЕ ЭЛЕМЕНТА (записи OD)

Sub-индекс 0h
Description (описание) количество классов ошибок (Error Classes)                       
Entry Category Mandatory (наличие обязательно) 
Access (тип доступа) ro
PDO Mapping No
Value Range 1h - FEh
Default Value No
Sub-индекс 1h
Description (описание) Communication Error (ошибка коммуникации)                   
Entry Category Mandatory (наличие обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED8
Default Value 0
Sub-индекс 2h - FEh
Description (описание) Ошибка профиля устройства или ошибка, специфическая
для производителя.
Entry Category Optional (наличие не обязательно)
Access (тип доступа) rw
PDO Mapping No
Value Range UNSIGNED8
Default Value No

[Словарик]

Приведена расшифровка некоторых аббревиатур и терминов, появляющихся в статье. Другие аббревиатуры и термины см. разделе "Словарик" статьи [2].

ARQ Automatic Repeat Request, автоматический повтор запроса.

CAN Controller Area Network, внутренний стандарт на специальную шину передачи данных.

COB Communication Object, объект коммуникации. Информационная единица переноса данных в сети CAN. Данные должны передаваться по сети CAN внутри COB. Имеется 2048 разных COB в сети CAN. COB может содержать может содержать самое большее 8 байтов данных.

COB-ID каждый COB уникально идентифицируется в сети числом, который называется идентификатором COB (COB-ID). Его значение определяет приоритет COB на sub-слое MAC.

Remote COB объект COB, передача которого запрошена другим устройством (узлом сети) с помощью запроса RTR.

CRC Cyclic Redundancy Check, контрольная сумма.

CSDO Client SDO, клиентский объект SDO.

LLC Logical Link Control, управление логическим соединением. Один из sub-слоев Data Link Layer (слоя переноса данных) в эталонной модели CAN Reference Model, который дает пользователю интерфейс, который не зависит от ниже лежащего слоя MAC.

MAC Medium Access Control, управление доступом к носителю данных. Один из sub-слоев Data Link Layer (слоя переноса данных) в эталонной модели CAN, который управляет доступом к среде для передачи сообщения.

MDI Medium Dependent Interface. Один из sub-слоев физического уровня передачи данных в эталонной модели CAN, который описывает механический и электрический интерфейс между носителем данных и модулем.

NMT Network Management, управление сетью. Один из сервисных элементов слоя приложения в эталонной модели CANopen. NMT обслуживает конфигурирование, инициализацию и обработку ошибок в сети CANopen.

Node-ID идентификатор узла, который для подчиненного узла (NMT Slave) должен назначаться уникально, либо Node-ID должен быть равен 0. Если Node-ID равен 0, то протокол адресует все подчиненные устройства NMT.

OSI Open Systems Interconnection, специальное название системы слоев сетей.

PDO Process Data Object, объект обрабатываемых данных, т. е. тех прикладных данных, для передачи которых служит сеть CANopen.

PLS Physical Layer Signalling, сигнализация физического слоя. Один из sub-слоев физического слоя эталонной модели CAN, который описывает представление бит, их интервалы времени и синхронизацию.

PMA Physical Medium Attachment. Один из sub-слоев физического слоя эталонной модели CAN, который описывает функциональные схемы для передачи/приема сигналов по линии связи шины, и может предоставить способ детектирования отказов (ошибок).

RPDO Receive PDO, объект PDO приема.

RTR Remote Transmit Request, специальный запрос узлу от другого узла сети CAN на передачу данных. Узел, который получил запрос RTR, должен в ответ автоматически передать свои данные.

SDO Service Data Object, объект сервисных данных.

SSDO Server SDO.

SYNC Synchronisation Object, объект синхронизации.

TPDO Transmit PDO, объект PDO передачи.

октет набор из 8 бит (байт).

[Ссылки]

1. CiA 301 CANopen Application Layer and Communication Profile site:can-cia.org.
2. Обзор протокола CANopen.
3. CiA306: стандарт файлов EDS для CANopen.
4. 170715CANopen-docs.zip.

 

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


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

Top of Page