Программирование ARM Обзор протокола CANopen Tue, October 08 2024  

Поделиться

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

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

Обзор протокола CANopen Печать
Добавил(а) microsin   

Самое общее представление о стандарте CANopen можно получить из русской Википедии, однако это не дает полной картины для понимания протокола, а просто объясняет общие термины. CANopen разработан как высокоуровневый сетевой протокол, работающий поверх физического протокола CAN (Controller Area Network), что позволяет осуществлять обмен данными между устройствами от разных производителей, и гарантирует взаимозаменяемость устройств. Здесь приведено общее описание стандарта, собранное из разных источников (см. "Ссылки"). Все непонятные термины и сокращения приведены в конце статьи (см. раздел "Словарик"). Здесь приведен перевод документации с сайта canopensolutions.com [2].

Профильное семейство CANopen определяет стандартизованные приложения для распространяемых систем, основанных на CAN. CANopen был разработан международной группой пользователей и производителей CAN-in-Automation (CiA), и был стандартизован как CENELEC EN 50325-4 в декабре 2002 года. Вскоре после своего первого запуска в 1996 году CANopen встретил широкое признание (особенно в Европе), где можно считать CANopen лидирующим стандартом для системных решений, основанных на CAN.

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

Сейчас CANopen используется для реализации различных задач:

• Управление машинами.
• Заводская, лабораторная автоматизация.
• Транспорт и трафик.
• Автомобильные приложения.
• Автоматизация построек.
• Медицинские системы.

Основные функциональные возможности CANopen. Стандартизованные приложения для распространяемых систем автоматизации на базе (Controller Area Network) предоставляют следующие функции:

• Передача критичных к времени доставки данных в соответствии принципом потребителя.
• Стандартизованное описание устройства (data, parameters, functions, programs) в так называемой форме "словаря объектов" ("object dictionary"). Доступ ко всем "объектам" устройства по стандартизованному протоколу передачи осуществляется по принципу клиент-сервер.
• Стандартизованные службы для мониторинга устройства (node guarding / heartbeat), сигнализация об ошибках (emergency messages) и координация работы сети ("network management").
• Стандартизованные системные службы для синхронных операций (synchronization message), центральное сообщение меток времени (central time stamp message).
• Стандартизованные вспомогательные функции для конфигурирования через шину скорости (baud rate) и идентификационного номера устройства.
• Стандартизованные шаблоны назначения для идентификаторов сообщений, чтобы упростить конфигурации системы в так называемой форме "заранее определенные наборы соединения" ("predefined connection set").

Application (приложение)
Профиль устройства для обычных модулей ввода/вывода (Device profile for generic I /O modules, CiA 401 V3.0)   Профиль устройства управления перемещением (Device profile drives and motion control, CiA 402 V2.0) ... Интерфейс и профиль для ПЛК (Interface and device profile for IEC 61131-3 programmable devices, CiA 405 V2.0) ...
Слой приложения CANopen и профиль обмена данными (application layer and communication profile, CiA 301, V4.1, также EN 50325-4) и рабочая среда для менеджеров и программируемых устройств CANopen (framework for CANopen managers and programmable CANopen devices, CiA 302, V3.4)
Слой соединения для обмена данными по шине CAN (CAN data link layer, ISO 11898:2003)
Физический слой CAN (ISO 11898:2003)
Шина CANopen

Рис. 1. Иерархическая структура стека протоколов CANopen.

Основные документы стандарта CANopen. Документ CiA 301 "CANopen Application Layer and Communication Profile" [15] является базовым стандартом, доступным через организацию пользователей стандарта "CAN-in-Automation e.V." (CiA), находящейся в Германии (город Эрларген). Расширенные механизмы обмена описаны в CiA 302: "Framework for Programmable Devices", в специальных инструментах PLC, HMI или CANopen. Предложения по спецификации CiA 303, CiA 305 и CiA 306 определяют стандарты и рекомендации для кабелей, цоколевке выводов, SI units, службам установки слоев (layer setting services, LSS) и спецификацию по радиоэлектронным документам (electronic data sheet, EDS). Все стандарты CANopen были разработаны компаниями-участниками CiA, и они свободно доступны без узуфрукта. Обзор устройства CANopen device и профилей приложения дан в разделе "Стандартные профили устройства и приложения".

[Базовые понятия CANopen]

Физическая структура сети CANopen. Архитектура нижнего уровня CAN определяет физическую структуру сети CANopen. По сути она самая обычная, ничем не отличающаяся от других сетей CAN - используется линейная (шинная) топология, где все устройства параллельно подключены к одной двухпроводной линии связи. Чтобы избежать паразитных отражений сигнала, оба конца сети должны быть нагружены на терминирующую нагрузку (2 резистора по 120 ом). Дополнительно должны быть учтены максимально допустимые длины сегментов сети между отдельными сетевыми узлами - в зависимости от скорости передачи и параметров линии.

line topology

Рис. 2. Физическая организация сети CAN при использовании CANopen.

Рекомендуемые допустимые скорости (bit rate) для сети CANopen даны в CiA 301: 10 kbps, 20 kbps, 50 kbps, 125 kbps, 250 kbps, 500 kbps, 800 kbps and 1000 kbps. В CiA 301 также дается рекомендация для конфигурации длительности (тайминга) бит.

Дополнительно для CANopen должны быть соблюдены 2 дополнительных условия. В принципе, это самые обычные требования к сети CAN:

• Все узлы сети должны быть сконфигурированы на одинаковую скорость.
• В сети не должно быть узлов с совпадающими идентификаторами.

К сожалению, нет механизмов для автоматического соблюдения этих условий. Системный интегратор должен проверить и при необходимости привести в соответствие bit rate и node-ID каждого отдельного узла сети при соединении их в общую сеть. Обычно node-ID конфигурируется непосредственно на устройстве через DIP-перемычки или шестнадцатеричные роторные переключатели. Также конфигурирование может быть осуществлено через дополнительный внешний интерфейс (UART, USB, JTAG). Альтернативные решения требуют предварительную установку этих параметров через 2 зарезервированных идентификатора CAN с помощью программного обеспечения, при участии так называемой службы настройки слоя "LSS-service" (layer setting service), как это описано в CiA 305.

Логическая структура CANopen. Все стандартное 11-битное адресное пространство низкоуровневого протокола CAN поделено между службами CANopen (см. далее Диаграмму 1): NMT, Sync, TimeStamp, PDO, SDO, Guarding, LSS. Это обеспечивает доступ ко всем объектам протокола CANopen через плоскую адресацию, упрощающую взаимодействие по сети.

Обмен данными, OD и EDS. Одним из самых важных свойств CANopen является стандартизованное описание устройства (описание его функций), которое называется словарем объектов (object dictionary, OD). Это таблица, имеющая одинаковую структуру для всех типов устройств. Таким образом, это дает возможность получить доступ снаружи (т. е. через шину CAN) ко всем важным данным, параметрам и функциям устройства с использованием логической системы адресации (index, subindex).

Шина CANopen arrows left right Communication
Interface (интерфейс обмена)


Сервер для SDO
Клиент для PDO
Receive-PDO
Transmit-PDO
NMT, SYNC, Emergency, Time Stamp, Heartbeat
arrows left right Словарь объекта
(OD)


Схема логической адресации для доступа к параметрам приложения и обмена данными, а также к данным и функциям
arrows left right Процесс приложения (Application
Process)


Функциональность устройства

- Функции
- Данные
- Параметры
arrows left right



arrows left right



Сигналы I/O

и

Данные процесса (Process Data)

Рис. 3. Информационная схема CANopen.

Каждый элемент словаря (объект) адресуется через 16-битный индекс и 8-битный sub-индекс. В объектах записана информация об узле сети CANopen: какие данные узел принимает или передает, каким способом, текущее состояние узла.

В дополнение к стандартизованному описанию коммуникационных свойств устройств в соответствии с CiA 301 [15], CANopen определяет так называемые профили устройств ("device profiles") для типичных устройств для различных областей применения. Они указывают наиболее важные параметры, данные и функции на каждый тип устройства (например модули ввода/вывода, приводы, энкодеры, и т. д.).

Описание электронного оборудования (electronical data sheet, EDS) содержит тип данных и функции по каждой записи директории OD. Обычно EDS представляет собой файл ASCII, в котором содержаться все данные. Чтобы сделать эти данные более гибкими и расширяемыми в контексте обработки, их формат был изменен на XML.

Передача данных через SDO и PDO. Есть 2 базовых, отличающихся друг от друга способа передачи данных по протоколу CANopen. Способ service data objects (SDO) основан на обмене по принципу client-сервер, и позволяет использовать прямую адресацию объекта по индексу и sub-индексу (index и subindex). Он используется для конфигурации устройства, передачи больших блоков данных в обоих направлениях (upload, download), но требует дополнительной нагрузки на протокол. Поэтому SDO медленный (по сравнению с PDO) способ передачи данных. Соединение по принципу SDO осуществляется как точка-точка, с задействованием элементов словаря, и подразумевает парный обмен пакетами с наличием подтверждения получения информации. Некоторую аналогию SDO можно провести с протоколом TCP, общий принцип тот же. С помощью SDO можно передавать произвольный объем данных.

data transfer

Рис. 4. Обмен SDO.

Способ process data objects (PDO) предоставляет эффективную передачу данных по принципу генератор-потребитель (producer-consumer). Длина пакета данных ограничена 8 байтами, однако это не накладывает излишней нагрузки на протокол, как при обмене по принципу SDO. Один PDO может содержать значения более чем одной записи из словаря объектов (OD), но содержимое PDO должно быть определено на этапе инициализации. Каждое устройство может указать до 512 объектов PDO для приема и передачи с учетом ограничений системы (по памяти, вычислительной мощности) или сети (количество доступных идентификаторов CAN).

  Байт 0 Байт 7
CAN-ID PDO1 Data

  Байт
0
  Байт
3
  Байт
6
Байт
7
CAN-ID PDO2 Data 1
скорость
Data 2
позиция
Data 3
Target ?

  Байт
0
  Байт
2
  Байт
4
  Байт
6
Байт
7
CAN-ID PDO3 Data 1
температура
Data 2
напряжение
Data 2
ток
Data 3
Target ?
Рис. 5. Обмен PDO.

PDO запускаются либо по запросам remote, либо по внутренним событиям, таким как переполнение таймера, или когда (циклически) приходит синхронное сообщение передачи (synchronous transmission message, SYNC). Все узлы сети могут принять сообщение (потребители сообщений, PDO-Consumer, см. рисунок ниже). Этим PDO похож на сетевой протокол UDP. Для последующей обработки может быть применена фильтрация по CAN-ID только интересующих объектов.

PDO transfer

Рис. 6. Широковещание PDO.

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

Специальные объекты коммуникации, так называемые "service data objects" (SDO) используются для прямого доступа к устройствам CANopen. С этими SDO записи словаря объектов OD могут быть считаны и записаны, где обмен всегда осуществляется по принципу логического соединения 1:1 (peer-to-peer) между двумя узлами сети (например, между конфигурирущим узлом и узлом, который получает конфигурацию). Поскольку перемещение данных через такое соединение осуществляется как служба подтверждения, то это означает, что узлу требуется 2 сообщения CAN на соединение: одно сообщение для запроса по сети(SDO request, или "Client SDO"), и второе сообщение для ответа на запрос (SDO response, "Server SDO"). ИМХО, такая терминология вносит некоторую путаницу в терминологию. Эти 2 сетевых узла используются и называются соответственно как SDO client и/или SDO server; здесь сервер идентифицируется как узел, который предоставляет или принимает данные с помощью его словаря OD. Клиентом соответственно считается тот узел, кто запрашивает (читает) или передает (записывает). Здесь имеет место логическое соединение между двумя партнерами, который также называют каналом SDO ("SDO channel"). Инициатива для передачи SDO всегда исходит от клиента. Поскольку передача SDO подтверждается, то на каждый запрос должен поступить ответ, даже если устройство не может предоставить какие-либо значимые данные, или даже если запрос сам по себе был ошибочным. Такой отрицательный ответ называется "abort". В таком ответе в дополнение к 4-байтному коду ошибки (abort code), который указывает причину abort, также передается адрес записи OD, на котором произошла сбойная передача SDO. Как уже упоминалось, передача SDO всегда запускается как последовательность запрос-ответ (request-response) в соответствии с отдельным протоколом, который указан в первом байте данных SDO. Таким образом, идентификатор сообщения указывает сам SDO и первый байт данных SDO задает определенный протокол. По этой причине первый байт данных также называют байтом протокола или байтом команды. Сообщение SDO всегда длиной 8 байт, где биты поля данных, которые не используются, должны быть установлены в 0.

Поля данных любой длины или последовательность байт может быть передана через доступ к объекту словаря. По этой причине длина информации, которая может быть передана через протокол SDO, теоретически не ограничена. Протокол SDO работает в 2 фазы: в фазе инициализации адресуется запись словаря объектов где показана длина передаваемых данных. Вторая фаза предназначена для данных, которые передаются в сегментах (по 8 байт на сегмент).

Соответственно DS-301 [15] разделяет 4 разных службы SDO: Initiate SDO Upload (инициация выгрузки SDO), Upload SDO Segment (выгрузка сегмента SDO), Initiate SDO Download (инициация загрузки SDO) и Download SDO Segment (загрузка сегмента SDO).

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

Сообщение для службы Initiate SDO Download, в котором доступ на запись в элемент словаря объектов узла происходит одновременно, структурируется следующим образом:

Байт команды OD main-index OD sub-index Данные (max. 4 байта)

Рис. 8. Initiate SDO Download.

Здесь OD main-index и OD sub-index это соответственно главный индекс и sub-индекс элемента в словаре объекта (OD).

Сервер SDO отвечает байтом протокола 0x60:

Байт команды 0x60 OD main-index OD sub-index Пустота (4 байта)

Рис. 9. Ответ на Initiate SDO Download.

В байте команд, где его отдельные биты назначены для разных целей, служба кодируется тремя битами (спецификатор команды). Еще один бит задает, какая осуществляется передача - expedited или обычная, non-expedited. Другой бит показывает, задан ли размер передаваемых данных в последних 4 байтах объекта коммуникации; однако этот бит используется только для non-expedited передач.

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

Обычно такое выравнивание упоминается так, что данные CANopen передаются по правилу "Little Endian" [11], что соответствует порядку следования байт в памяти процессоров INTEL. Это означает, что младший байт передается первым. Это несколько усложняет анализ данных протокола SDO человеком, хотя это в конце концов вопрос привыкания. При подсчете уже описанных бит протокола их получается 7. Восьмой бит зарезервирован.

Таким образом, SDO download в запись OD [1017], где heartbeat interval для heartbeat producer устанавливается в 4 секунды (в ms, как значение UNSIGNED16, например 0x0F A0), появляется в следующем виде:

2B 17  10 00 A0  0F  00  00

Рис. 10. Пример записи в объект [1017].

Узел (SDO server), когда отвечает сообщением успешного завершения:

60 17  10 00 00  00  00  00

Рис. 11. Ответ на запись в объект [1017].

Со службой Initiate SDO Upload, с которой считывается элемент словаря объекта узла CANopen, допустимой является то же самое деление поля данных, только здесь до некоторой степени инвертируются телеграммы запроса и ответа. Вот байт команды запроса клиента 0x40:

Байт команды (0x40) OD Main Index OD Sub Index Пустота (4 байта)

Рис. 12. Пример запроса чтения обекта словаря.

Сервер SDO отвечает:

Байт команды OD Main Index OD Sub Index Данные (4 байта)

Рис. 13. Ответ на запрос чтения объета словаря.

SDO сервер должен всегда отвечать на типичный запрос чтения производителя устройства (vendor ID; он находится в sub-индексе 1 объекта идентификации, identity object [1018]), поскольку этот OD-элемент является обязательным. В качестве примера рассмотрим устройство от IXXAT (номер вендора 00 00 00 04). Таким образом, сообщение ответа SDO будет следующим:

43 18  10 01 04  00  00  00

Рис. 14. Пример ответа на запрос чтения.

Если используется не "expedited transfer", то 4 байта данных Initiate SDO services можно использовать для указания длины (в байтах) передаваемых данных. Тогда действительная передача может произойти со службой Download SDO Segment или Upload SDO Segment. Может быть передано 7 байт данных пользователя на сегмент. Байт команды этих служб содержат 3 бита идентификатора службы (service-ID, спецификатор команды), один toggle-бит и 4 не используемых бита, за исключением последнего сегмента. Чтобы также безопасно передать данные пользователя, размер которых не делится нацело на размер сегмента 7, количество не используемых байт (значение между 6 и 0) кодируется 3 битами в последнем сегменте SDO. И наконец, LSB биты байта команд помечают конец передачи. Порядок следования сегментов мониторится по toggle-биту, где переключаются сообщения и SDO request, и SDO response. Закомментироанная последовательность сегментированной non-expedited выгрузки иллюстрируется следующим образом:

   40 08 10 00 00 00 00 00  // Инициация запроса: Read Device Name [1008]
   41 08 10 00 1A 00 00 00  // Инициация ответа: все в порядке, это будет 26 байт.
   60 00 00 00 00 00 00 00  // Запрос Upload segment, Toggle = 0
   00 54 69 6E 79 20 4E 6F  // Ответ Upload segment, Toggle = 0
   70 00 00 00 00 00 00 00  // Запрос Upload segment, Toggle = 1
   10 64 65 20 2D 20 4D 65  // Ответ Upload segment, Toggle = 1
   60 00 00 00 00 00 00 00  // Запрос Upload segment, Toggle = 0
   00 67 61 20 44 6F 6D 61  // Ответ Upload segment, Toggle = 0
   70 00 00 00 00 00 00 00  // Запрос Upload segment, Toggle = 1
   15 69 6E 73 20 21 00 00  // Последний сегмент, 2 байта свободно, Toggle = 1

В версии 4 CANopen спецификации DS-301 [15], представлен новый, значительно более эффективный, однако более сложный режим SDO, так называемый режим блочной передачи SDO (SDO block transfer). В отличие от передачи сегмента, описанного выше, здесь сегменты больше не запрашиваются индивидуально, вместо этого комбинируются друг с другом в блоки, где все сегменты передаются за 1 раз. Тогда партнер подтверждает только блок. Для пользовательских данных размером от 29 байт блочная передача лучше с точки зрения побочных затрат на протокол. С блочной передачей байт протокола нумерует отдельные сегменты каждого блока так что можно передать в блоке максимум 127 сегментов. Передача окружена фазой инициализации, в которой размеры блока и размеры служебных данных обоих партнеров делаются соответствующими друг другу, и фазой завершения, в которой фиксируется проверка контрольной суммы CRC по всей передаче, при условии, что партнеры обмена подтвердили передачу на этапе инициализации. Однако передача блока SDO в настоящий момент поддерживается только несколькими устройствами.

Доступ на чтение (SDO read access) к элементу словаря объекта [1008], имя устройства, блочная передач выглядит примерно так:

   A4 08 10 00 21 00 00 00  // Инициация запроса: Read [1008], размер блока 33, CRC поддерживается
   C2 08 10 00 1A 00 00 00  // Инициация ответа: длина данных 26 байт, нет CRC
   A3 00 00 00 00 00 00 00  // Инициация запроса блока: начинаем передачу
   01 54 69 6E 79 20 4E 6F  // Ответ Upload block, сегмент 1
   02 64 65 20 2D 20 4D 65  // Ответ Upload block, сегмент 2
   03 67 61 20 44 6F 6D 61  // Ответ Upload block, сегмент 3
   84 69 6E 73 20 21 00 00  // Последний сегмент 4
   A2 04 21 00 00 00 00 00  // Запрос Upload block: принято 4 сегмента, размер блока 33
   C9 00 00 00 00 00 00 00  // Ответ завершения: 2 байта свободно
   A1 00 00 00 00 00 00 00  // Конец запроса: благодарю

Важным сервисом SDO является "Abort SDO Transfer" (байт команды: 0x80). Он состоит полностью из одного сообщения CAN, который может быть передан в любое время любым из двух партнеров вместо обычного сообщения протокола SDO, и приводит к непосредственному завершению передачи SDO. Наиболее общие ситуации для SDO-Abort в качестве ответа на Initiate SDO request, это ситуация, когда в словаре объекта адресуемый объект отсутствует. Структура сообщения Abort SDO:

0x80 OD main-index OD sub-index Abort code

Рис. 15. Сообщение Abort SDO.

Поле данных этой службы SDO содержит информацию от ошибке (cause of the error, abort code) как двойное слово, dword. Спецификация CANopen перечисляет все определенные коды abort, их всего примерно 30. Использование собственных кодов abort или не определенных кодов не допускается. Наиболее важные коды abort:

   0x05030000  бит Toggle не изменился
   0x05040001  недопустимый идентификатор команды (Invalid SDO Command specifier)
   0x0601000x  не поддерживаемый доступ к объекту
   0x06010002  попытка записи в объект, предназначенный только для чтения
   0x06020000  объект не существует в словаре объекта
   0x0607001x  не соответствует тип данных
   0x06090011  sub-индекс не существует
   0x08000000  общая ошибка

Каждое устройство должно поддерживать как минимум 1 канал SDO. Остальные каналы SDO могут быть настроены через элементы словаря объекта. Записи OD от [1201] до [127F] с предопределены для записи параметра SDO, зарезервированы для определения каналов сервера SDO.

Основная задача системы CANopen конечно же состоит в управлении процессом передачи данными. Для этой цели предоставлено не только большинство идентификатором CAN, но также и большинство записей в словаре объекта. Для обработки передачи данных это происходит без дополнительной нагрузки на протокол, и передача происходит в соответствии с так называемым принципом "генератор-потребитель" ("producer-consumer principle"). Это означает, что сообщение, передаваемое узлом (это генератор) может быть принято всеми другими узлами (потребителями). Этот принцип также называют широковещанием ("broadcasting") и он представляет очень эффективный принцип передачи данных, особенно если сообщение (например сообщение синхронизации) должно быть передано одновременно для всех участников процесса.

Сообщение CAN, которое содержит данные процесса, называется PDO ("Process Data Object"). Как уже было описано, передача сообщений PDO возможно только в состоянии "Operational". Все PDO имеют не фиксированный формат. Поле данных PDO может быть длиной от 1 до 8 байт. Содержимое PDO также не может быть быстро интерпретировано. Основная идея здесь состоит в том, что и передатчик, и приемник знают, как интерпретировать содержимое PDO. По этой причине достаточно в PDO идентифицировать только его COB-ID. Так называемое отображение PDO ("PDO mapping") описывает, какие отдельные переменные процесса в поле данных PDO переданы, как они расположены, и какой тип данных и длину они имеют. Таком образом, содержимое и смысл поля данных каждого определенного PDO описано в форме записи PDO-mapping внутри словаря объекта на обоих сторонах обмена - передатчика и приемника.

PDO producer (передатчик, генератор PDO) составляет поле данных PDO в соответствии со своим отображением TxPDO mapping. Для этого он берет текущие данные передаваемых переменных из своего словаря объекта, и копирует их в поле данных PDO перед отправкой сообщения CAN (PDO). То же самое происходит на стороне потребителя данных (consumer): на базе записи RxPDO mapping, байты данных принятых PDO копируются в записи локального словаря объекта, так что срабатывают зависящие от устройства действия (например, установка цифровых выходов).

Узел сети, которые хотят принять определенные PDO, должны активироваться только соответствующим сообщением CAN. Это осуществляется проверкой "set valid" соответствующей записи COB-ID в OD.

Однако вернемся сейчас к PDO mapping. Принцип расположения (mapping) переменных процесса показан в следующем (переменные доступны в форме записей словаря объекта в профиле приложения). Расположение отдельных переменных процесса в поле данных PDO описано в форме таблицы. Это также предоставлено как запись словаря объекта, а именно для каждого transmit-PDO и receive-PDO в [16xx] или [1Axx]. Эти таблицы, и таким образом расположение переменных процесса в поле данных PDO, могут конфигурироваться с помощью SDO доступа на запись.

mapping table2

Рис. 16. Пример взаимосвязи объектов.

В этом примере имеется точно 2 связи объектов: от объекта (переменная процесса) [2345sub67] продюсера PDO к объекту [5432sub10] потребителя PDO, и от объекта [6000sub01] продюсера до объекта [6200sub02] потребителя. Третий объект передачи [2001sub00] не обрабатывается на стороне приемника, и поэтому считается так называемым пустым, фиктивным объектом (dummy object).

Таблицы отображения имеют тип данных "PDO mapping", которые содержат в sub-индексе 0 (subindex 0) количество отображенных объектов, и в sub-индексах от 1 до 8 сами отображаемые записи словаря объекта в формате DWORD. Здесь содержится 24-битный адрес OD (index, subindex) и закодированная 8 битами длина записи OD. Устройство, которое поддерживает 8 отображенных записей имеет гранулярность 8, и может таким образом выполнить только побайтное отображение (byte-wise mapping). Устройства с гранулярностью 1, с другой стороны, поддерживают отображение каждого отдельного бита PDO ("bit-mapping"). Соответственно здесь должно быть тогда 64 элементов в таблице отображения (mapping table).

Однако PDO описан не только отображением (mapping), но также и его коммуникационными параметрами. Это COB-ID, т. е. идентификатор сообщения CAN, тип передачи ("transmission type"), время запрета ("inhibit time"), и это все может конфигурироваться через соответствующий элемент словаря объекта. Позиция этого дополнительного элемента словаря имеет смещение 0x200 перед соответствующим элементом отображения, например для transmit PDO [18xx] и receive PDOs [14xx]. Таким образом, каждый PDO описан двумя отдельными элементами OD, которые жестко принадлежать друг другу и должны конфигурироваться системным интегратором. Следующая таблица показывает запись "PDO parameter":

Таблица 1. Запись параметра PDO.

Sub-Index Содержимое Тип данных
0 Самый большой поддерживаемый sub-index BYTE
1 COB-ID DWORD
2 Тип BYTE
3 Inhibit time в миллисекундах WORD
5 Event timer (таймер события) WORD

Subindex 1 содержит идентификатор CAN PDO выровненный вправо в двойном слове. Самый старший бит значения показывает, активен ли PDO (valid) или не активен (invalid). Набор старших бит показывает недопустимость, например значение 0x80000199, описывает первый TxPDO узла с номером 25.

Тип передачи PDO может быть установлен вторым sub-индексом. Для начала следует отличать друг от друга синхронные и асинхронные PDO:

Таблица 2. Типы PDO.

Value (dec) Тип
0 синхронный, не цикличный
1...240 цикличный синхронный
241...251 зарезервировано
252 только синхронный RTR
253 только асинхронный RTR
254...255 асинхронный

Асинхронные PDO управляются по событиям (event-controlled), и представляют нормальный тип передачи PDO. Это означает, что когда изменилась как минимум одна из переменных процесса, отображенная на PDO, например изменилось входное значение, то PDO передается немедленно. Для этого значения 255 или 254 вводятся как тип PDO.

Синхронные PDO передаются после предварительного приема сообщения синхронизации (Sync Object). Таким образом, передача PDO осуществляется синхронно во всей сети, более или менее одновременно. Но то, что намного более важно - все входы устройства должны быть опрошены при поступлении sync object, чтобы был сформирован законченный универсальный снимок результатов. Со следующим сообщением sync, записанные данные отправляются в синхронных PDO. Таким образом присутствует задержка, на время цикла синхронизирующего сообщения, поскольку получатели обработали переменные процесса в момент предыдущего синхронизационного сообщения. В направлении вывода синхронные PDO, принятые узлом, становятся действительными только на следующем синхронизационном сообщении.

Чтобы шина CAN не забивалась большим количеством синхронных PDO, которые все посылаются с каждым сообщением SYNC, используются значения 1..240 циклического синхронного типа PDO в качестве делителей интервала передачи. Соответственно [18xxsub02] = 4 означает, что синхронный PDO отправляется только с четвертым сообщением Sync. Независимо от этого устройство конечно должно записать свои входы с каждым сообщением Sync, поскольку может произойти, что синхронно записанные переменные процесса в PDO будут запрошены RTR. В этом случае устройство CANopen должно немедленно передать соответствующий PDO с записанными значениями. В [1006] параметре "Communication Cycle Period" узлы могут быть оповещены интервалом Sync в микросекундах.

И наконец, в sub-индексе 3 для асинхронных PDO можно установить "inhibit time" (время запрета). Это значение дается в единицах 100 микросекунд. Inhibit time полезно, когда происходят частые неконтролируемые изменения входных значений; например, если аналоговый вход никуда не подключен и болтается в воздухе. Если inhibit time сконфигурировано, то узел не может передавать снова соответствующий PDO до истечения времени запрета; это гарантирует, что шина не будет чрезмерно загружена бесполезными сообщениями. Конечно же, время запрета используется только для TxPDO. Оно не имеет смысла для RxPDO.

Асинхронные TxPDO могут быть переданы циклически по таймеру события (event timer), sub-индекс 5. Если значение больше 0, то это становится миллисекундным таймером. Когда этот таймер истек, передается PDO. Таким образом, передача осуществляется, когда изменяется вход внешнего устройства, или когда истек event timer. Этот sub-индекс также имеет значение только для объектов transmit-PDO.

Узел CANopen обычно имеет 4 transmit-PDO и 4 receive-PDO, где один COB-ID зарезервирован для каждого из этих PDO. Так что это займет всего 127*4*2 = 938 идентификаторов COB-ID, что обычно составляет половину всего пространства идентификаторов. Однако из-за так называемой взаимосвязи объектов ("object linking"), например при установлении коммуникационных взаимоотношений между transmit- и receive-PDO, идентификаторы CAN снова освобождаются, поскольку при связи либо продюсера, либо потребителя должны быть адаптированы их COB-ID к партнеру обмена, так что свои собственные зарезервированные COB-ID становятся свободными. Таким образом, на практике для сети с 127 узлами в среднем доступно 8 идентификаторов COB-ID на устройство для TxPDO. Конечно, для сетей с меньшим количеством узлов неиспользуемые COB-ID могут также использоваться. Интегратор системы должен всегда иметь обзор пространства назначения идентификаторов, и иметь представление о реально используемых COB-ID; для более сложных систем для этого рекомендуется использовать программный инструмент, например IXXAT CANopen ConfigStudio. Этот инструментарий, например, автоматически обрабатывает PDO-mapping и PDO-linking.

Это необязательная опция, которая может использоваться в сети. Обычно пакеты SYNC генерирует мастер сети CANopen (генератор пакетов SYNC называют SYNC-producer) с регулярными интервалами, что позволяет синхронизировать обмен данными. В частности, получение пакета SYNC узлом может инициировать ответную передачу сообщения PDO (получателя пакета SYNC называют SYNC-consumer). Таким образом, с помощью пакетов SYNC можно реализовать получение информации от датчиков в регулярные моменты времени.

Поскольку CANopen не является иерархической системой master-slave, и контролируемый узел передает только коммуникационное состояние, а не реальное состояние состояние узла, то каждый узел нуждается в высокоприоритетном идентификаторе CAN, чтобы показывать ситуации ошибки. Этот механизм называется "Emergency Messaging", и он связан с объектом обмена "Emergency Message". Такое аварийное сообщение состоит из 8 байт данных в следующей форме:

Код ошибки (Error code) Регистр ошибки (Error register) Поле ошибки, специфичное для вендора

Рис. 17. Аварийное сообщение.

Коды ошибок указаны в DS-301 [15]. Старший байт разделяет категории ошибки:

Таблица 3. Коды ошибок аварийного сообщения.

Error code (hex) Описание ошибки
00xx Сброс ошибки / отсутствие ошибки (Error Reset / No Error)
10xx Обычная ошибка (Generic Error)
2xxx Ток (Current)
3xxx Напряжение (Voltage)
4xxx Температура (Temperature)
50xx Аппаратура устройства (Device Hardware)
6xxx Программа устройства (Device Software)
70xx Дополнительные модули
8xxx Мониторинг
90xx Внешняя ошибка (External Error)
F0xx Дополнительные функции
FFxx Ошибка, специфичная для устройства

Одновременно с передачей emergency message устройство записывает код ошибки в [1003], где сохраняется история ошибок. Регистр ошибки это содержимое элемента OD [1001] с побитным кодированием случая ошибки:

Таблица 4. Кодирование событий ошибки.

Бит Случай ошибки (Error cause)
0 Обычная ошибка (Generic Error)
1 Ток (Current)
2 Напряжение (Voltage)
3 Температура
4 Обмен данными (Communication Error)
5 Ошибка, специфичная для профиля устройства (Device Profile Specific)
6 Зарезервировано (всегда 0)
7 Ошибка, специфичная для производителя (Manufacturer Specific)

Идентификатор CAN для emergency message сохраняется в OD устройства под ячейкой [1014], но этот элемент OD является опциональным (необязательным), как и само событие аварии (emergency event).

В дополнение к предоставлению служб и протоколов для передачи данных процесса и конфигурации устройств, работа системы, распространяемая по сети, требует функций для командного управления коммуникационным состоянием отдельных узлов сети. Поскольку передача данных устройств CANopen во многих случаях управляется событиями (event-controlled), также требуется отслеживания возможности обмена между узлами сети. CANopen предоставляет так называемые службы управления сетью ("network management", сокращенно NMT) и протоколы для этих задач, а именно управление коммуникационным состоянием узлов сети и мониторинг узла.

[Статус узла сети CANopen и состояние управления через сообщения NMT]

CANopen описывает коммуникационное состояние сетевого узла в диаграмме состояния (state diagram). Путем отправки специальных сообщений CAN (NMT messages), мастер управления сети (network management master) может управлять коммуникационным состоянием других узлов (подчиненные узлы в управлении сетью, network management slaves) сети CANopen. Например мастер может одной командой поменять состояние всех узлов или отдельного конкретного узла.

Сообщения NMT передаются через самый высокоприоритетный идентификатор сообщения (CAN-ID 0). Поле данных этого сообщения состоит только из 2 байт: требуемое целевое состояние закодировано в первом байте данных, второй байт задает номер узла, у которого должно быть изменено коммуникационное состояние. Все узлы сети совместно адресуются через виртуальный идентификатор узла node-ID 0; таким способом одной командой все узлы сети могут быть переведены в рабочее состояние ("Operational"), чтобы работа узлов началась одновременно.

[Какие бывают состояния. Смена состояния]

Ниже на диаграмме показаны возможные состояния устройства и переходы между ними.

state of node

Рис. 18. Диаграмма смены состояний узла.

Сброс, включение питания. Чтобы можно было даже частично сбросить определенный узел, это состояние имеет деление на 3 подсостояния: "Reset-Application" (сброс приложения), "Reset-Communication" (сброс обмена) и "Initializing" (инициализация).

После аппаратного сброса (HW-Reset) или включения питания (Power-On) узел попадает в состояние "Initializing". После завершения базовой инициализации узла (например контроллера хоста, контроллера CAN, программы приложения и т. д.) узел передает так называемое сообщение загрузки ("boot-up message") и самостоятельно переходит в состояние в "Pre-operational" (предварительная готовность к работе).

В подсостоянии "Reset-Application" сбрасываются специфические параметры производителя и стандартный профиль устройства к состоянию на момент включения питания (Power-On values, что соответствует последним сохраненным значениям параметров). После этого узел перемещается в подсостояние "Reset-Communication". В этом подсостоянии сбрасываются параметры профиля коммуникации к своим значениям при включении питания (Power-On values). Затем состояние узла меняется на "Initializing".

Pre-Operational. Это состояние главным образом используется для конфигурирования устройств CANopen. Таким образом, процесс обмена данными (через объекты PDO) в этом состоянии невозможен. Элементы словарей объекта устройства могут быть доступны через сервисные объекты данных ("service data objects", SDO). Путем передачи сообщения SDO можно модифицировать словарь объекта определенного устройства, например с помощью инструментария конфигурирования.

В состоянии Pre-operational в дополнение к обмену через сообщения SDO также могут передаваться или приниматься сообщения аварии (emergency), синхронизации (synchronization), метки времени (time stamp) и конечно управляющие сообщения NMT. Путем передачи "Start-Remote-Node" узел переключается в состояние "Operational".

Operational. В этом состоянии возможна передача данных процесса через так называемые объекты обработки данных ("process data objects", PDOs).

Stopped. За исключением сообщений node guarding или heartbeat, в этом состоянии узел не может передавать или принимать какие-либо сообщения.

[Мониторинг устройств CANopen с использованием механизмов node guarding и heartbeat]

Для гарантирования работоспособности узлов сети CANopen предоставляет 2 альтернативные возможности: циклический опрос node guarding и автоматическую передачу сообщений heartbeat, подробнее см. раздел "Мониторинг сети: Guarding и Heartbeat".

Для мониторинга коммуникационного состояния устройства требуется один CAN-ID на узел сети. Для этого зарезервированы низкоприоритетные идентификаторы сообщений со значением 1792 + node-ID.

В настоящее время принцип node guarding больше не используется. Это могло быть данью главным образом более высокой загрузки шины (из-за 2 сообщений CAN на интервал мониторинга), но также и нежелательной централизацией зависимости целостности сети от работоспособности одного узла NMT-master.

Для обеспечения работоспособности узлов сети протокол CANopen предоставляет 2 взаимоисключающие альтернативы:

1. Циклический опрос состояния узла со стороны узла с повышенным приоритетом, так называемого "NMT-Master". Этот принцип называется "node guarding" (буквально переводится "защита узла").
2. Автоматическая передача специального контрольного сообщения узлами сети. Этот принцип называется "heartbeat" (переводится как "сердцебиение").

Node guarding. При работе по принципу node guarding определенный узел сети (это главный узел сети, так называемый NMT-master) опрашивает остальные узлы сети (подчиненные узлы, соответственно называемые NMT-slave) фреймом CAN remote (что такое remote frame, см. [12]). Опрос узлов идет последовательно, друг за другом, с заранее определенным интервалом времени ("guard time", защитный интервал времени). В ответ подчиненные узлы должны передать телеграмму данных, описывающую их текущее коммуникационное состояние (stopped, operational, pre-operational) вместе с так называемым битом toggle. Если узел по какой-то причине не ответил на запрос NMT-master в течение заданного времени ("node life time", время жизни узла), то это регистрируется как ошибка соответствующего узла, и показывается контроллеру хоста NMT-master как "node-guarding event" (событие защиты узла). Другими словами, подчиненные устройства NMT-slave также мониторят сеть на предмет обнаружения запроса от NMT-master в течение своего "времени жизни". Если такой запрос отсутствовал дольше, чем так называемый интервал "времени жизни" узла, то узел NMT-slave также предполагает, что мастер сети NMT-master поломался, и показывает это своему хост-контроллеру через "Life guarding event" (событие защиты жизни сети).

В режиме node guarding, требуется по одному идентификатору CAN на узел сети, чтобы осуществлять опросы коммуникационного состояния. Для этой цели зарезервированы сообщения с идентификаторами низкого приоритета значениями 1792 + node-ID.

Heartbeat. При мониторинге сети по принципу heartbeat узел автоматически передает свое коммуникационное состояние с регулярными интервалами как доказательство своей коммуникационной работоспособности. Интервал между такими ближайшими друг к другу сообщениями (heartbeat messages) конфигурируется через специальную запись директории объектов [1017]. Значение 0 запрещает механизм heartbeat. Так называемое "heartbeat consumer time" (потребительское время сердцебиения) до 127 сетевых узлов дано в записи OD [1016]. Этот интервал времени описывает максимальное время, в течение которого прибытие сообщения подтверждения работоспособности (heartbeat message) ожидается определенным узлом.

В обоих принципах защиты сети сообщения с коммуникационным статусом передается в форме однобайтного значения:

t/r Состояние узла (Node State)
t ..... Toggle-bit с контролем node guarding
r ..... зарезервировано (= 0) с контролем heartbeat

Рис. 19. Кодирование состояния узла.

Определены следующие значения для состояния узла:

0x00 - Bootup
0x04 - Stopped
0x05 - Operational
0x7F - Pre-Operational.

Самый старший бит значения назначен для специальной роли - по принципу защиты node guarding этот бит должен переключаться (toggle), по принципу heartbeat он должен быть всегда в состоянии 0.

Сообщение состояния узла (node status message) имеет специальное приложение, так называемое событие загрузки "bootup event". Это сообщение ("bootup message") автоматически отправляется узлом сети, как только он перейдет из состояния инициализации ("Initialization") в состояние перед началом нормального функционирования ("Pre-Operational"); это оповещает все узлы, уже присутствующие в сети CANopen, о появлении нового узла. Дополнительно конфигурирующий узел (NMT-master) информируется, когда он может начать конфигурировать узел. Байт данных для bootup имеет значение 0x00.

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

Функциональные данные - те данные, которые описывают целевое функционирование системы (температура, величины управляющих воздействий исполнительных механизмов), те данные, которые передавались бы между блоками, даже если бы в качестве связующего звена использовалась линия связи отличная от CAN, например, LIN или USB, или Ethernet, или I2C.

Технологические данные - те, которые обеспечивают функционирование сети в целом, контроль корректной работы всех узлов, конфигурирование частей системы — те данные, появление которых связано с использованием сети CANopen и не зависит непосредственно от задач, решаемых системой.

Документ CiA DS-201 выделяет 4 основных группы подсистем (Fig.3 CiA DS-201):

CMS: передача сообщений. Сюда относятся: обмен функциональными данными, обмен срочными сообщениями, обмен данными по запросу, управление объектным словарём.
NMT: управление сетью, контроль работы устройств сети.
DBT: динамическое распределение идентификаторов.
LMT: управление конфигурированием устройства.

[Использование заранее определенных идентификаторов сообщений для простых систем]

Чтобы уменьшить объем конфигурирования, требуемый для простых структур сети (1: n коммуникационных взаимосвязей между управляющим устройством и несколькими устройствами более низкого уровня), CANopen поддерживает предопределенное назначение идентификаторов сообщений (Predefined Connection Set). Этот набор заранее определенных идентификаторов поддерживает одно emergency message на узел, сообщения синхронизации и меток времени, одно SDO-соединение на устройство, NMT-сообщения для управления узлами и их мониторинга, и до 4 transmit-PDO и 4 receive-PDO на устройство.

Сеть CANopen может дифференцировать между собой максимум до 127 узлов. Эти узлы совместно используют 11-битное пространство идентификаторов.

Сначала делается дифференцирование между сетевыми функциями и функциями, связанным с устройством. Один идентификатор CAN резервируется на каждую связанную с сетью функцию (например управление узлом через NMT), один идентификатор на устройство требуется для функциональности, связанной с устройством (например, аварийные сообщения, сообщения PDO), поскольку должна быть возможность дифференцировать одинаковые функции на разных устройствах. Более важные функции назначаются на более приоритетные идентификаторы COB-ID. Для будущих расширений и по историческим причинам некоторые идентификаторы сообщений не назначены. Таким образом, есть возможность работать системам наличием одного управляющего главного узла и до 127 подчиненных узлов, без необходимости переконфигурирования узлов сети.

Следующая диаграмма показывает результирующее разделение пространства идентификаторов CAN.

Диаграмма 1. Распределение адресного пространства стандартных идентификаторов CAN для элементов протокола CANopen.

NMTarrow right    000h
 
Syncarrow right    080h
Emergency
TimeStamparrow right    100h
 
     180h
PDO
     200h
 
     280h
 
     300h
 
     380h
 
     400h
 
     480h
 
     500h
 
     580h
SDO
     600h
 
     680h
 
     700h
Защита (Guarding)
     780h
LSSarrow right  
   7FFh
 

Обратите внимание, что идентификаторы распределены между службами таким образом, чтобы выделить им нужный приоритет в соответствии с низкоуровневой работой протокола CAN (чем меньше значение идентификатора, тем приоритет прохождения пакета выше). Таким образом, пакеты NMT будут распространяться с самым высоким приоритетом, а LSS с самым низким.

Следующая таблица показывает выделение идентификаторов Predefined Connection Set:

Таблица 5. Принцип выделения предопределенных идентификаторов CAN.

Объект обмена (Communication
object)
COB-ID, hex Подчиненные узлы (Slave nodes)
Управление узлом NMT (NMT node control) 000 Только прием (receive)
Синхронизация (Sync) 080 Только прием (transmit)
Emergency 080 + NodeID Передача
TimeStamp 100 Только прием
PDO 180 + NodeID
200 + NodeID
280 + NodeID
300 + NodeID
380 + NodeID
400 + NodeID
480 + NodeID
500 + NodeID
1. Transmit PDO
1. Receive PDO
2. Transmit PDO
2. Receive PDO
3. Transmit PDO
3. Receive PDO
4. Transmit PDO
4. Receive PDO
SDO 580 + NodeID
600 + NodeID
Transmit
Receive
Мониторинг узла (NMT node monitoring) по принципу node guarding или heartbeat 700 + NodeID Transmit
LSS 7E4
7E5
Transmit
Receive

SDO и PDO всегда используются парно (например для передачи и для приема), где правило состоит в том, что узел с более низким идентификатором COB-ID (и соответственно с более высоким приоритетом) передает, и с более высоким идентификатором COB-ID (т. е. с более низким приоритетом) принимает.

Как уже упоминалось, Predefined Connection Set дает возможность работать системам с одним главным узлом и до 127 подчиненных узлов, и при этом не требуется переконфигурировать что-либо. Здесь имеется старший управляющий узел, например для передачи данных процесса на узел с node-ID 5 можно использовать сообщения PDO с идентификаторами COB-ID 0x205, 0x305, 0x405 и 0x505; данные процесс от этого узла принимаются через сообщения PDO с идентификаторами COB-ID 0x185, 0x285, 0x385 и 0x485. Таким образом, по умолчанию управляющий узел может обмениваться с подчиненным узлом до 32 байтами процесса входа и 32 байтами процесса выхода. В нашем примере управляющий узел может получить доступ к словарю объекта узла номер 5 запросом SDO с идентификатором COB-ID 0x605, и принять соответствующий SDO-ответ с COB-ID 0x585.

Для более сложных сетевых структур, например с взаимосвязями n: m, или если недостаточно использовать предопределенное количество PDO на устройство, предварительное назначение идентификаторов должно быть изменено путем реконфигурирования выделения идентификаторов (параметр PDO). Для этой цели рекомендуется использовать инструментарий конфигурирования.

[Layer Setting Services (LSS)]

Стандартом четко определено, что должно обязательно быть выполнено 2 условия для взаимодействия устройств CANopen по сети: все устройства должны использовать одинаковую скорость обмена (baudrate), и идентификаторы узлов CANopen (node-ID) должны быть уникальными в пределах сети. Но что делать, если устройства не переключаются в состояние с этими свойствами?

Спецификация CANopen DS-305: Layer Setting Services (LSS) описывает, как можно настроить устройства CANopen с помощью простого протокола.

Условием для использования LSS, в дополнение к условию поддержки LSS самим устройством, является установление проводного соединения 1:1 с конфигурируемым узлом. Тогда скорость передачи бит (baudrate) и node-ID устанавливаются в режиме диалога. COB-ID 0x7E5 используется для сообщений CAN в устройство, устройство отвечает на COB-ID 0x7E4. Сообщения LSS всегда имеют полную длину 8 байт. Не используемые байты должны всегда быть инициализированы значением 0.

Чтобы наладить контакт с конфигурируемым устройством, передается команда "Switch Mode Global":

0x04 0x01 зарезервировано

Рис. 20. Начальная фаза установки взаимоствязи с устройством.

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

Затем запрашивается node-ID через службу "Inquire Node-ID":

0x5E зарезервировано

Рис. 21. Запрос идентификатора устройства.

Если все хорошо, то устройство ответит так:

0x5E Node ID зарезервировано

Рис. 22. Ответ устройства со своим идентификатором.

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

Служба "Configure Node-ID" используется для конфигурирования нового node-ID:

0x11 Node ID зарезервировано

Рис. 23. Запрос на конфигурирование идентификатора узла.

В ответ устройства включен код ошибки:

0x11 Error code Error extension зарезервировано

Рис. 24. Ответ на запрос смены идентификатора.

Об успешной операции сигнализирует только код ошибки 0; код ошибки 1 означает недопустимый node-ID; другие коды ошибки зарезервированы. Расширение кодов ошибки содержит информацию, специфическую для вендора, но это допустимо только для кода ошибки 0xFF.

Скорость по шине (baudrate) конфигурируется службой "Configure Bit Timing Parameters":

0x13 Bit timing table Элемент таблицы скоростей зарезервировано

Рис. 25. Запрос на изменение скорости.

Стандартные скорости CANopen перечислены в следующей таблице:

Таблица 6. Кодирование скоростей CANopen.

Таблица скоростей (Baudrate table 0x00)
Индекс в таблице Baudrate
0 1000 kBit/s
1 800 kBit/s
2 500 kBit/s
3 250 kBit/s
4 125 kBit/s
5 reserved
6 50 kBit/s
7 20 kBit/s
8 10 kBit/s

На команду установки скорости устройство ответит:

0x13 Error code Error extension зарезервировано

Рис. 26. Ответ на команду изменения скорости.

И снова код ошибки 0 означает успех операции; код ошибки 1 означает недопустимую скорость; все другие коды ошибки зарезервированы. Расширение кодов ошибки содержит информацию, специфическую для вендора, но это допустимо только для кода ошибки 0xFF.

Теперь сконфигурированы node-ID и baudrate, эти установки должны быть сохранены службой "Store Configuration":

0x17 зарезервировано

Рис. 27. Команда сохранения конфигурации.

На это устройство выдаст подтверждение:

0x17 Error code Error extension зарезервировано

Рис. 28. Подтверждение сохранения конфигурации.

Код ошибки 0 означает успех; код ошибки 1 означает, что устройство не поддерживает сохранение; код ошибки 2 означает, что есть проблема с доступом с носителю данных, куда сохраняются настройки (storage medium); другие коды ошибок зарезервированы. Расширение кодов ошибки содержит информацию, специфическую для вендора, но это допустимо только для кода ошибки 0xFF.

И наконец, устройство переключается обратно в из режима конфигурации командой "Switch Mode Global":

0x04 0x00 зарезервировано

Рис. 29. Команда выхода из режима конфигурирования.

После физического выключения и повторного включения устройство теперь будет работать с новыми настройками.

[Стандартные профили устройства и приложения]

На основе CiA 301 [15] как фундаментального стандарта CANopen появилось впоследствии большое количество документов, описывающих стандартные устройства или стандартные приложения. В этих дополнительных стандартах (так называемые профили устройства и приложения, device and application profiles) с помощью элементов словаря объекта (OD) определены поведение и параметры стандартизованных устройств или приложений. Цель стандартизации на основе профилей устройства состоит в том, чтобы устройствами одного класса можно было бы обмениваться, что позволяет получить независимость от конкретного производителя устройств (устройства от разных производителей становятся взаимозаменяемыми). Профили приложения должны упростить интеграцию систем, построенных на устройствах от разных вендоров. Профили обычного устройства (Generic device profile) описывают интерфейс одного устройства, в то время как профили приложения описывают все интерфейсы устройств, которые являются частью приложения. Профили устройства также могут содержать дополнительные коды ошибок, скомпилированные типы данных, светодиоды устройства (LED) и многие другие вещи. Профиль устройства обычно определяет отображение по умолчанию для первых 4 receive-PDO и transmit-PDO, представляющих наиболее общие элементы OD, специфические для профиля. Таким образом, устройство со стандартным профилем может непосредственно, прямо "из коробки" использоваться без необходимости настройки его элементов словаря, относящихся к параметрам и обмену данными.

Нельзя полностью описать устройство во всех возможных вариантах. Таким образом, все профили позволяют определять специфичные для вендора свойства внутри так называемого диапазона профиля производителя ("vendor-specific profile range"). Таким способом можно описать функции, атрибуты и параметры, которые не содержатся в стандартном профиле.

Стандарт CiA 401 ("Device Profile for I/O Modules") известен как описание наиболее важного профиля устройства. Этот профиль описывает аналоговые и цифровые интерфейсы ввода и вывода, и их возможности по назначению параметров. CiA 401 задает элементы OD для максимум 2040 цифровых входов/выходов и до 255 аналоговых входов/выходов. Помимо стандартизованных элементов словаря для текущих значений есть ряд продолжающихся элементов OD для управления параметрами поведения этих входов и выходов.

Другим очень важным профилем устройства является CiA 402, это профиль устройства для драйверов с интерфейсом CANopen ("Drives and Motion Control"). Этот профиль покрывает сервоконтроллеры, шаговые двигатели и частотные преобразователи. Наподобие CiA 401, этот стандарт также основан на модели для описания поведения привода. Модель привода описывает машину состояний и поддерживает среди разных других параметров работу режима позиционирования, режима ускорения и режима крутящего момента. Здесь два из таких наиболее важных и поэтому обязательных элемента OD: управляющее слово ("control word") и слово состояния ("status word") для установки и получения обратно режима привода и его статуса. Они отображены первыми в каждом PDO по умолчанию.

В следующей таблице перечислены определенные в настоящий момент профили устройства и приложения CANopen:

Таблица 7. Профили устройства CANopen.

Номер профиля Класс устройства
CiA 401 Обычные модули ввода вывода (Generic I/O Modules)
CiA 402 Управление приводами (Drives and Motion Control)
CiA 404 Измерительные устройства и контроллеры управления с обратной связью (Measuring devices and Closed Loop Controllers)
CiA 405 Программируемые устройства, ПЛК (IEC 61131-3 Programmable Devices)
CiA 406 Круговые и линейные энкодеры (Rotating and Linear Encoders)
CiA 408 Гидравлические приводы и линейные вентили (Hydraulic Drives and Proportional Valves)
CiA 410 Измерители угла наклона (Inclinometers)
CiA 412 Медицинское оборудование (Medical Devices)
CiA 413 Грузовые шлюзы (Truck Gateways)
CiA 414 Текстильное и ткацкое оборудование (Yarn Feeding Units, Weaving Machines)
CiA 415 Машины для дорожного строительства (Road Construction Machinery)
CiA 416 Управления дверьми зданий (Building Door Control)
CiA 417 Управление лифтами (Lift Control Systems)
CiA 418 Батарейные модули (Battery Modules)
CiA 419 Зарядные устройства для батарей (Battery Chargers)
CiA 420 Оборудование штамповки, волочения, гибки, резки (Extruder Downstream Devices)
CiA 422 Городской транспорт (Municipal Vehicles – CleANopen)
CiA 423 Системы управления дизельными машинами ЖД (Railway Diesel Control Systems)
CiA 424 Управление дверями поездов ЖД (Rail Vehicle Door Control Systems)
CiA 425 Дополнительные модули медицинской диагностики (Medical Diagnostic Add-on Modules)
CiA 445 Устройства идентификации (RFID Devices)

Более подробное описание содержимого этих профилей можно найти на сайте can-cia.org [1].

[Реализация CANopen]

Для реализации CANopen во встраиваемых системах используются стеки протоколов, которые обычно предоставляются в форме лицензий компаний-разработчиков. Компания HMS предоставляет под брендом IXXAT всесторонне протестированный стек протоколов CANopen либо в обычном коде языка C, либо в виде готовой адаптации к большому количеству удобных стеков для различных микроконтроллеров. Стек CANopen доступен как "Slave" или "Master/Slave", обкатанный на множестве приложений. Термины "Slave" и "Master" относятся к различной функциональности устройства в контексте управления сетью, что реализовано протоколом CANopen в форме логической взаимосвязи главное/подчиненное устройство (Master/Slave).

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

Структура ПО протокола CANopen. Стек IXXAT CANopen от компании HMS разработан в масштабируемой, модульной форме, в соответствии с различными службами CANopen, такими как Network Management (NMT), Process Data Objects (PDO), Service Data Objects (SDO), Emergency (EMCY), Synchronization (SYNC), SDO-Manager (SDM/SDR), Layer Setting Services (LSS) и Object Dictionary (OBD). Все модули имеют доступ к словарю объектов, который представляет центральный экземпляр программного пакета как мост между коммуникационным интерфейсом и данными, параметрами и функциями приложения.

Доступ к контроллеру CAN (для передачи и приема сообщений) осуществляется через интерфейс "Data Link Layer", который интегрирован в отдельный модуль (DLL). Это позволяет быстро и просто адаптировать ПО протокола CANopen к разным реализациям контроллера CAN.

Шина CANopen arrows left right Контроллер CAN Слой данных
(Data
Link
Layer)
arrows left right Интерфейс обмена (Communication
Interface)
SDO
PDO
SYNC
MNS
NMM
ENCY
LED
FLY
SDM, SRD
LSS
arrows left right Словарь объектов (Object
Dictionary,
OBD)
arrows left right Приложение
(Application, USR)

Структура программного обеспечения IXXAT CANopen stack

Рис. 30. Принцип организации стека CANopen компании IXXAT.

Простое конфигурирование и оптимизированные требования к памяти. Функционал стека IXXAT CANopen может быть просто адаптирована под требования приложения. Для этого разработчик просто должен активировать или деактивировать функции/модули как определения ("define") в центральном конфигурационном файле.

Для реализации подчиненного устройства с довольно полезным функциональным набором на 16-разрядном микроконтроллере требуется примерно 13 килобайт ROM и 1 килобайт RAM. Если у разработчика имеется меньше доступных ресурсов, то эти значения могут бить дополнительно уменьшены с помощью специальных модификаций.

HMS предоставляет программное обеспечение протокола CANopen (IXXAT CANopen protocol software) как кросс-платформенный исходный код C, или код, специально адаптированный к применению к определенным моделям микроконтроллеров и контроллеров CAN. Таким образом, разработчик получает большую степень свободы к адаптации и управлению программного обеспечения, как если бы он разрабатывал его сам.

С начала работ по стандартизации CANopen компания HMS активно участвовала в организациях CANopen. Поэтому HMS определенно может реализовать самые последние стандарты на самом раннем этапе их появления. HMS инвестирует значительный объем работ в непрерывное продвижение и обслуживание своих стеков CANopen. Посредством соглашения о поддержке программного обеспечения клиенты HMS могут участвовать в этом непрерывном дальнейшем развитии и извлечь выгоду из поддержки квалифицированных специалистов CANopen. Чтобы предоставить пользователям высококачественные продукты, HMS всегда проверяет свой стек протоколов на совместимость тестовым ПО от CiA [1]. Фактически ПО IXXAT успешно используется во многих областях применения уже много лет, гарантируя пользователям беспроблемное, успешное внедрение CANopen в свои продукты.

Разрабатывать или купить? Снова и снова разработчики решают для себя вопрос - стоит или нет разрабатывать ПО протокола CANopen самостоятельно, потому есть несколько свободно доступных альтернатив без необходимости платить за лицензию, и даже есть несколько альтернатив с открытым исходным кодом. Конечно, это интересная проблема в плане разработки. Однако с точки зрения это стоит дешево, поскольку зрелое ПО протокола CANopen предлагается сейчас несколькими производителями по вполне привлекательным ценам.

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

Если мы предположим, что собственная разработка стека протокола CANopen может быть реализована за 4 человеко-месяца при почасовой оплате 60 евро, то стоимость такой разработки может быть больше чем 35000 евро. Однако это очень оптимистичная прикидка, и хорошо протестированное и надежное решение с предоставленным исходным кодом может быть получено за часть от этой цены. Таким образом, самостоятельная разработка стека протоколов становится полностью неинтересной с точки зрения экономии, включая время выхода конечного продукта на рынок.

Что в себя включает готовая реализация CANopen? HMS предоставляет свой IXXAT CANopen protocol stack с подробной документацией и примерами программ. Файлы проекта предоставлены вместе с примерами программ, которые позволяют осуществить прямую интеграцию в соответствующее рабочее окружение производителя компилятора. Все примеры программ могут быть непосредственно запущены на базовой платформе (оценочная плата разработчика или интерфейсная карта IXXAT).

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

• Адаптация аппаратуры к целевой платформе (таймер, система прерываний).
• Создание элементов словаря объектов.
• Адаптация конфигурационного файла.
• Компиляция и тестирование. Для тестирования приложение примера может быть перенесена на целевую платформу. Это можно взять также как базу для собственного приложения.

Ранние реализации CANopen на целевой системы можно было настроить за несколько дней.

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

Доступно программное обеспечение и инструментарий CANopen. Обзор доступных стеков протоколов IXXAT можно найти во врезке "Стеки протоколов для встраиваемых систем IXXAT", или на сайте IXXAT. Общее описание полезного инструментария для разработки и быстрого старта, как canAnalyser, CANopen Device Manager, CANopen ConfigurationStudio (базовая версия) можно найти во врезке "Инструментарий и интерфейсы IXAAT".

HMS предоставляет под брендом IXXAT различные стеки протоколов, которые позволяют получить функционал CANopen на определенных пользовательских микроконтроллерных платформах. ПО протокола распространяется как независимый от аппаратуры исходный код C, который всегда проверяется на последних тестах совместимости CANopen организации CiA [1]. Подробная документация и примеры программ позволяют быстро разработать нужное прикладное ПО.

HMS предоставляет следующие программные пакеты:

CANopen Protocol Software. Этот пакет включает в себя все необходимые функции для реализации подчиненных устройств (slave) или простых главных устройств (master) CANopen в соответствии со спецификацией CIA 301 (EN 50325-4) [15]. По умолчанию предоставляется поддержка служб LSS в соответствии с CIA 305. Доступны дополнительные модули для интеграции функционала flying master или SDO manager. Подробнее см. CANopen Protocol Software на сайте IXAAT (строка для поиска Software package for the development of CANopen slave or simple CANopen master devices site:ixxat.com).

CANopen Manager Software. Это очень мощный программный пакет для реализации блоков устройств CANopen, которые могут работать как slave, master или сложных устройств менеджеров (CANopen manager). Этот программный пакет базируется на спецификациях CIA 301 [15], CIA 302 и CIA 405. Подробнее см. CANopen Manager Software на сайте IXAAT (строка для поиска Software package for the development of CANopen master devices site:ixxat.com).

CANopenRT (Real-Time) Software. Это ПО является специфической версией протокола CANopen, реализующая расширенные интерфейсы, что позволяет достичь очень эффективной интеграции либо в операционные системы реального времени (RTOS), либо в другие широко распространенные операционные системы. Подробнее см. CANopen RealTime Software на сайте IXAAT (строка для поиска Real-time-capable software package for the development of CANopen slave or simple CANopen master devices site:ixxat.com).

[Пакеты для PC]

HMS также предлагает API для реализации устройств master и slave, обслуживания всех видов приложений и уровней сложности сети. Библиотека распространяется в виде Windows DLL, которая может быть просто интегрирована в ПО пользователя.

CANopen Master API. Это API является программным пакетом, позволяющим упростить разработку таких приложений CANopen slave и master, как сервисные и тестовые программы на платформе Windows. Подробнее см. CANopen Master API на сайте IXAAT (строка для поиска Software package for the development of CANopen service and test applications under Windows site:ixxat.com).

CANopen Manager API. Это API мощное и гибкое решение, которое (в комбинации с CAN-интерфейсом iPC-I XC161/PCI(e)) позволяет реализацию основных управляющих приложений CANopen. Это может быть также интегрировано с совместимым IEC 61131-3 run-time окружением платформ на основе Microsoft Windows. API базируется на CANopen Manager Software, и таким образом полностью поддерживает стандартизованную процедуру CANopen boot-up. CANopen Manager API совместимо со спецификациями CIA 301 [15], CIA 302, и CIA 405. Подробнее см. CANopen Manager API на сайте IXAAT (строка для поиска Software package for the implementation of complex PC-based CANopen control solutions site:ixxat.com).

[Инструменты для обслуживания и диагностики CANopen]

CANopen Device Manager. Это универсальный и обновляемый инструмент, нацеленный на тестирование устройства, диагностику и полевые испытания. Он построен на основе центрального компонента, который управляет сервисами CANopen и предоставляет главную точку входа для определения сети. CANopen Device Manager закрывает функционал наподобие узла NMT и управление ошибками, клиента SDO (включая блочную передачу с CRC), PDO producer и PDO consumer, SYNC producer и time stamp producer. Он также позволяет осуществлять загрузку DCF и загрузку firmware в соответствии со спецификацией CiA 302, LSS master по спецификации CiA 305. Как опциональный аддон предоставляется система скриптов Python, что позволяет реализовать мощные тестовые приложения.

Подробнее см. CANopen Device Manager на сайте IXAAT (строка для поиска Powerful CANopen service and diagnostics tool for service staff and developers site:ixxat.com).

[Онлайн-анализ, симуляция и интерпретация данных]

canAnalyser с модулем CANopen. Программа canAnalyser является мощным и разносторонним инструментом для разработки, тестирования и обслуживания сетей на основе CAN/CANopen.

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

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

Хост скриптов (Scripting Host) комбинирует графический интерфейс пользователя с гибкостью скриптов. С помощью использования Scripting Host canAnalyser можно быстро и просто адаптировать для специфических задач измерений и анализа. Это позволяет пользователю симулировать устройства и протоколы, или тестировать существующие устройства на моделируемых шинах, и помещать их в рабочее состояние. Специальное тестовое окружение может быть просто реализовано на любых интерфейсных компонентах Windows. Scripting Host поддерживает стандартные скриптовые языки C# и Visual Basic .NET. Объединение модулей DLL также позволяет интеграцию в другие модули.

Подробнее см. canAnalyser 3 Suite на сайте IXAAT (строка для поиска canAnalyser 3 Suite site:ixxat.com).

[Интерфейсы]

Платы и модули CAN. HMS предоставляет широкий диапазон плат CANopen, обслуживая широкий диапазон обычных интерфейсов PC для всех требований приложений:

• PCI, PCIe, PCIe Mini, PCIe 104
• PC/104, ISA
• Ethernet
• USB
• Bluetooth

Подробнее см. IXXAT CAN interfaces на сайте IXAAT (строка для поиска IXXAT CAN interfaces site:ixxat.com).

[Другие платные инструменты]

Этот продукт доступен в нескольких основных версиях: Evaluation, Ultimate и Pro Ultimate. Версия Ultimate имеет разные наборы опций отличающиеся друг от друга по стоимости (в комплекте идут разные аппаратные интерфейсы). Ниже приведен список возможностей CANopen Magic Ultimate. The list is not exhaustive by any means, but does give a good overview of the abilities of CANopen Magic Pro Ultimate.

• SDO Upload (чтение из узла сети).

- Отображение прочитанных данных в формате ASCII.
- Отображение прочитанных данных в как десятичных целых чисел со знаком, беззнаковых целых чисел и в формате real.
- Отображение прочитанных данных в шестнадцатеричном формате.
- Отображение прочитанных данных в форматах времени дня (TIME OF DAY) и разницы во времени (TIME DIFFERENCE).
- Сохранение прочитанных данных в файл.
- Автоматический выбор наиболее подходящего типа данных для элемента.
- Ручной выбор элемента.
- Выбор элемента из списка конфигурируемого OD.

• SDO Download (запись в узел сети).

- Ввод данных для записи в формате ASCII.
- Ввод данных для записи в формате десятичного целого со знаком, без знака и в формате real.
- Ввод данных для записи в шестнадцатеричном формате.
- Ввод данных для записи в форматах времени дня (TIME OF DAY) и разницы во времени (TIME DIFFERENCE).
- Данные для записи могут быть прочитаны из файла.
- Автоматический выбор наиболее подходящего типа данных для элемента.
- Ручной выбор элемента.
- Выбор элемента из списка конфигурируемого OD.

• Управление сетью (NMT) для всех узлов или для одного узла.

• Сканирование сети для получения информации о доступных узлах.

• Можно подключить одновременно к сети CAN другие средства разнаботки PEAK.

• Автоматическое запоминание позиций и настроек позиций окон, аппаратных и сетевых конфигураций.

• Передача конфигурируемых сообщений.

- Выбор набора идентификаторов (ID) по умолчанию для сетевого соединения.
- Ручной ввод ID.
- Выбор определяемых пользователем ID сообщений.
- Периодическая передача с настраиваемым периодом.
- Передача нажатий на кнопки.
- Передача при получении сообщения с определенным ID.
- Конфигурируемые содержимое и длина сообщения.
- Есть возможность передачи сообщений RTR (Remote Transmission Request).
- Обзорное отображение всех сконфигурированных сообщений.
- Можно давать сообщениям понятные описательные имена.

• Описание сети (Network Description) и её конфигурирование.

- Указание имен для узлов сети.
- Указание EDS для узлов сети.
- Указание имен для сообщений.

• Сохранение конфигураций узла в файлах описания устройства (Device Configuration Files, DCF).

• Восстановление конфигураций из файлов DCF.

• Сохранение всех конфигураций узлов в файл конфигурации сети (Network Configuration File, NCF).

• Восстановление всех конфигураций узлов из файла NCF.

• Обзорный вид на сеть (Network Overview Display).

- Автоматическое сканирование сети на наличие в ней узлов.
- Предоставляется быстрый обзор доступных узлов и базовой информации о них.
- Постоянно отображается текущее состояние узла и последняя ошибка.
- Установка всех heartbeat-ов для всех узлов за один раз.

• Быстрое конфигурирование PDO.

- Автоматическое сканирование на наличие PDO, определенных на узле.
- Быстрое и простое конфигурирование коммуникационных параметров PDO.
- Быстрое и простое конфигурирование параметров отображения на PDO (PDO mapping).
- Выбор для объектов PDO набора идентификаторов соединения (ID) по умолчанию.
- Ручной ввод идентификаторов ID для объектов PDO.
- Выбор определяемых пользователем идентификаторов для объектов PDO.
- Разрешение и запрет PDO одним кликом.
- Разрешение и запрет одним кликом всех PDO, определенных для узла.

• Конфигурирование отображения трассировки (Configurable Trace Display).

- Запуск и остановка для анализа трассировки.
- Сохраняется до 13000+ сообщений (0.5 секунд на скорости 1 мегабит при 100% загрузке шины).
- Интерпретация сообщений CANopen позволяет просто просматривать активность сети.
- Отображение имен, определенных пользователем.
- Фильтрация отображаемых сообщений.
- Можно открыть до 4 окон трассировки, с индивидуальными настройкой и фильтрацией.
- Непрерывный режим, показывающий каждое сообщение на шине.
- Статический режим, показывающий последнее сообщение для каждого ID на шине.
- Абсолютные метки времени (timestamps) с точностью 1 мкс.
- Относительные метки времени с точностью 1 мкс, показывающие время между следующими друг за другом сообщениями.
- Экспорт трассировки в формате CSV с нарастанием (ascending CSV) и убыванием (descending CSV) с целью последующего анализа в Excel.
- Отображение содержимого сообщения в шестнадцатеричном формате.
- Отображение содержимого сообщения в десятичном знаковом и беззнаковом формате.
- Отображение содержимого сообщения в формате ASCII.
- Отображение сырого содержимого сообщения.
- Опциональное отображение фреймов ошибки.

• Фильтрация отображения трассировки с помощью диапазонов ID или скриптовой системы.

• Конфигурируемое отображение данных процесса (Process Data).

- Может быть показано любого количество элементов данных процесса.
- Обновление при детектировании объектов PDOs в сети.
- Конфигурируемое графическое отображение данных в нескольких форматах.
- Добавление меток и графики для создания интерфейсов продукта.
- Отображение графиков аналоговых данных.

• Файлы проекта.

- Сохранение и загрузка настроек в файлах проекта.
- Запуск приложения с проектом через командную строку.

• Конфигурирование на узлах LSS.

- Автоматическое детектирование одиночных узлов.
- Конфигурирование идентификаторов ID узла.
- Конфигурирование битовых интервалов (bit timings, скорость по шине).

• Работа со всеми CAN-интерфейсами PEAK-System Technik.

• Мониторинг последней аварии (emergency), переданной текущим выбранным узлом.

• Интерфейс командной строки для программирования через BAT-файлы и тестирования линейки конечной продукции.

• Можно запустить одновременно, в той же самой сети, вместе с другими совместимыми инструментами, включая PCANExplorer и PCANView.

• Конфигурируемые таймауты SDO и LSS.

• Система симуляции узла (CANopen Node Simulation System).

- Можно симулировать за 1 раз до 127 узлов CANopen.
- Симулируемые узлы могут обмениваться друг с другом и реальными узлами.
- Реакция на NMT, объекты SDO, PDO, LSS и другие функции, поддерживаемые стеком - CANopen, используемая для постройки симулируемых узлов.
- Симулируемые узлы могут быть доступны из CANopen Magic Ultimate как если бы это были реальные узлы, с использованием всех функций CANopen Magic Ultimate.
- Можно использовать для разработки узлов перед тем, как станет доступной аппаратура.
- Просмотр содержимого образа процесса симулируемого узла.
- Просмотр OD симулируемого узла.
- Создание графического управления вводом и выводом, чтобы управлять и визуализировать I/O симулируемого узла.
- Сохранение всех настроек симуляции в проекте и файлах Sim IO, чтобы можно было обмениваться ими с другими инженерами.
- Моделирование коробочных коммерческих продуктов и тестирование их интеграции в свою пользовательскую сеть.
- После завершения симуляции узлов просто перепишите аппаратный драйвер для переназначения конфигурации узла на аппаратуру.
- Поддержка MicroLSS/LSS Fastscan.
- Поддержка добавляемого профиля устройства CiA 447 (CiA 447 Car Add-On Device Profile).
- Постоянная запись в лог и воспроизведение симуляции с опциями паузы и пошагового выполнения.

Страничка с общим описанием: CANopen Magic site:canopenstore.com.

[Свободный инструментарий для CANopen]

IXXAT Device Description Explorer for CANopen and POWERLINK. Это свободный от выплат инструмент от компании HMS позволяет пользователю инспектировать и конвертировать файлы описания устройства CANopen и POWERLINK в соответствии со стандартами CiA 306 и CiA 311, по спецификации EPSG DS 311 XML Device Description.

canAnalyser - Demo. Это мощный и разносторонний инструмент для разработки, тестирования и обслуживания сетей CAN и CANopen. Страница загрузки: Demos Software & Tools site:ixxat.com.

MicroCANopen. Существует в 3 версиях: MicroCANopen, MicroCANopen Classic и MicroCANopen Plus. Из них бесплатна только первая версия, с сильно урезанными возможностями. Частности, в примерах для ARM среды разработки IAR есть демонстрационные проекты CANopen на основе урезанной версии MicroCANopen (проект basic-microcanopen-project). Подробнее про MicroCANopen см. описание на сайте canopenstore.com, строка для поиска MicroCANopen site:canopenstore.com.

CanFestival. Возможно, это самая продвинутая библиотека из бесплатных, с исходным кодом. Портирована на многие популярные встраиваемые платформы. Хорошее описание протокола CANopen и работы с утилитами CanFestival можно найти по ссылке [10].

CANopen DeviceExplorer (Demo). Утилита для диагностики сети, урезанную версию можно скачать с сайта emtas.de (строка для поиска CANopen DeviceExplorer site:emtas.de), исполняемый файл инсталлятора будет называться наподобие setup-emtas-cde-2_6_2.exe. Достоинство утилиты в том, что она поддерживает множество заводских адаптеров, в том числе и USB-CAN адаптеры SYSTEC (тип адаптера выбирается на этапе инсталляции). Под Windows после установки запускайте программу под учетной записью администратора.

Вы можете по адресу service@emtas.de послать запрос на получение лицензии, в ответ Вам пришлют 30-дневную бесплатную лицензию (файл наподобие emtas_XXXXX_Demo_YYYYMMDD_cde_2-x-x.ldat). Полнофункциональная персональная лицензия стоит 780 евро, для её получения также требуется предоставить свое имя и адрес.

AN945, стек CANopen от Microchip [14]. Библиотека для микроконтроллеров PIC18 с низкими требованиями к FLASH и RAM. Исходный код присутствует, при желании можно портировать на другие платформы.

[Словарик]

Application object (прикладной объект). Функциональность устройства, которую оно предоставляет, описывается прикладными объектами. Прикладные объекты могут быть читаемыми или записываемыми параметрами устройства, данными или функциями. К прикладному объекту можно получить доступ через однозначный адрес в OD.

bps, kbps bit per second, kilobit per second. Единица измерения физической скорости следования бит.

CANopen object (объект CANopen) Функциональность CANopen-устройства, видимая через шину, описывается объектами CANopen. Объектами CANopen могут быть данные, параметры или функции устройства. Объект может быть идентифицирован в объектном словаре с помощью 16-битного индекса и 8-битного sub-индекса.

CiA аббревиатура от CAN in Automation, название организации, которая разработала спецификацию CANopen.

CiA-301 коммуникационный профиль CANopen [15]. Обязательная для всех устройств CANopen спецификация коммуникационной модели и структура OD. Начиная с версии 4.0 были включены CMS и NMT, DBT был удалён, и LMT перешел в LSS.

CiA-302 общая спецификация для программируемых CANopen устройств []. Среди прочего содержит предварительные определения для CiA-405.

CiA-401 CANopen-профиль устройства для стандартных модулей ввода/вывода.

CiA-402 CANopen-профиль устройства для приводов.

CiA-405 CANopen-профиль устройства для IEC-1131 программируемых устройств.

CiA-406 CANopen-профиль устройства для датчиков положения.

Client-SDO (клиент SDO). Клиент SDO обозначает инициатора передачи SDO. Оно имеет доступ к записи объектного словаря "сервера SDO". Обычно клиентом выступает мастер шины CANopen, а сервером подчиненное устройство CANopen. Мастер через объекты SDO получает параметры из словаря OD подчиненного устройства.

CMS CAN-based Message Specification, спецификация сообщений, основанная на протоколе CAN. Предоставляет объекты типов Variable, Event и Domain для разработки и указания, как функциональность устройства (узла сети CAN) может быть доступна через интерфейс CAN. Т. е. как выгружать или загружать набор данных ('domain'), длина которых превышает максимальный размер 8 байт элементарного сообщения CAN, включая функцию обрыва передачи ('abort transfer').

COB communication object, объект обмена данными. Это сообщение, которое передается по CANopen. Данные передаются посредством COB.

COB-ID / COBID (идентификатор коммуникационного объекта). COB-ID создает коммуникационное соединение между передаваемым и принимаемыми коммуникационными объектами, и одновременно определяет приоритет сообщения. Это стандартное свойство сети CAN - идентификатор с меньшим номером имеет приоритет выше. Идентификатор 0 с наивысшим приоритетом зарезервирован для сервисов управления сетью (NMT).

COS Change Of State, информация об изменении состояния. Когда объект PDO работает под управлением событий (Event Driven PDO), то он автоматически передает COS. Это обычно происходит, когда имеется новая информация (например, поменялось значение на входе). Чтобы избежать чрезмерного забития шины, может быть задано время запрета (inhibit time).

Communication cycle period (период коммуникационного цикла). Период коммуникационного цикла определяет интервал времени между последовательными объектами синхронизации.

Communication parameters (коммуникационные параметры). Атрибуты PDO описаны в его коммуникационных параметрах. Эти атрибуты включают в себя тип передачи, время подавления (время запрета, inhibit time) и идентификатор COB-ID.

DBT DistriBuTor, динамическое распределение идентификаторов.

DCF Device Configuration File, файл конфигурации устройства. DCF-файл описывает реальное, существующее, настроенное устройство в сети. Структура DCF файла соответствует структуре EDS файла, плюс имеется специфичная для проекта конфигурация этого устройства. Среди прочего конфигурация содержит скорость передачи данных, PDO отображение (PDO mapping), специфичное для проекта название устройства, устанавливает идентификатор узла и параметризацию прикладных объектов.

Device profiles (профили устройств). Функциональность устройства описывается с помощью стандартных функций в области стандартизированного профиля устройства, а для специфичных для производителя функций устройства – в области специфичного для производителя профиля устройства.

Dummy / Dummy entry (фиктивная, или пустая запись). Фиктивное отображение необходимо для заполнения пропусков в отображении принимаемого PDO. Например, если объект PDO имеет длину 8 байт, но в нем имеют отображение полезной нагрузкй только последние 2 байта, то тогда первые 6 байт должны быть отображены на фиктивные записи.

Если типы данных (с индексами 1..7) отображены, они обслуживаются как фиктивные. Соответствующие данные в PDO устройством не вычисляются. Эта опциональная функция полезна в тех случаях, когда передаются данные на несколько устройств через один и тот же PDO, но каждое из устройств использует определенную, свою отдельную часть этого PDO. Нельзя создавать фиктивное отображение для TPDO.

EDS electronic data sheet, описание электронного оборудования. EDS описывает функциональность устройства. Этот файл должен быть предоставлен разработчиком / произ- водителем устройства CANopen. EDS-файл содержит общие и специфичные данные устройства, некоторую статистическую информацию о самом файле и детальное, полное описание OD.

Emergency object / EMCY (объект аварии). Высокоприоритетным объектом аварии устройство сигнализирует о наступлении неустранимой внутренней ошибки устройства или о сбросе одной или всех внутренних ошибок устройства. Поддержка сообщения об ошибке устройства является необязательной. Аварийный код ошибки указывает тип ошибки в соответствии с CiA-301.

Granularity (Гранулярность). Максимально возможное количество объектов, которые могут быть введены в PDO, определяется гранулярностью (длине объекта в битах) прикладных объектов. Максимальный размер поля данных PDO – 8 байт данных. Таким образом при гранулярности 8 не более чем 8 байтовых прикладных объектов может быть отображено на PDO. При гранулярности 1 поддерживается ровно 64 булевых прикладных объекта.

Granularity задается в разделе [DeviceInfo] словаря OD. Если здесь задано 0, то это означает, что отображение модифицировать нельзя.

Guard time (время охраны). Относится к протоколу Guarding, предназначенному для отслеживания работоспособности узлов сети CANopen. NMT-мастер циклически передает запрос к подчинённому устройству, чтобы получить его текущее состояние узла. На данный запрос должен быть дан ответ в течении времени жизни узла (node life time). Время жизни узла является результатом умножения фактора времени жизни (life time factor) на время охраны узла. Подчинённый узел не проводит мониторинг NMT мастера, если время охраны = 0. Тем не менее он отвечает на протокол Guarding. Нарушения охраны узлов описаны в CANopen-спецификации CiA301 [15].

HMS аббревиатура обозначает название компании HMS Industrial Networks, которая предоставляет программно-аппаратные решения для CANopen.

Inhibit time (время подавления, или время запрета). Объект данных процесса (PDO) может быть повторно передан только после истечения этого времени.

IXAAT бренд компании HMS для дистрибуции решений CANopen.

LMT Line Management, управление конфигурированием устройства.

LSB Least Significant Bit, младший значащий бит.

LSS Layer Setting Services, службы CANopen, предназначенные для первоначальной настройки узлов сети.

NCF Network Configuration File, файл конфигурации сети.

NMT Network Management, система обслуживания сети. Сервисный элемент прикладного уровня, который состоит из конфигурации, инициализации и контроля ошибок сети, а также процесса синхронизации во всей сети CANopen. Управление сетью имеет структуру мастер/подчинённый.

Node guarding (охрана узла). Циклический мониторинг узла. Специальный протокол, предназначенный для отслеживания работоспособности узлов сети CANopen.

Node-ID (идентификатор узла) Отдельное устройство CANopen определяется в сети по его номеру узла (между 1 и 127). Этот номер конфигурируется при настройке сети (либо перемычками, либо специальным ПО, либо по протоколу LSS). Идентификатор узла 0 зарезервирован для служб NMT.

OD, OBD object dictionary, словарь объектов. Объектный словарь это структура данных, через которую можно обратиться ко всем объектам CANopen-устройства. OD разделен на область с общей информацией об устройстве, такой как название производителя и т. д., а также область, которая содержит параметры связи, и область, которая описывает специфичную для устройства функциональность. Через записи (объекты) OD прикладные объекты устройства, такие как входные и выходные сигналы, параметры устройства, сервисы устройства или сетевые переменные становятся доступными по сети в стандартизированной форме. OD образует интерфейс между сетью и прикладным ПО.

OD entry (запись объектного словаря). Информационная запись OD.

PDO process data object (объект данных процесса). Специальный объект CANopen, предназначенный для обмена полезными (прикладными) данными по сети CAN. PDO представляет фактические средства транспорта для передачи данных процесса. PDO передаётся "поставщиком" (producer, продюсер) и может быть получен одним или несколькими "потребителями" (consumer). Данные процесса, передаваемые поставщиком в PDO, могут состоять максимум из 8 байт. PDO передаётся без подтверждения, и требует идентификатора, однозначно назначенного для PDO. Значение передаваемых данных определяется идентификатором, который они используют, и отображением на PDO (PDO mapping), назначенной для PDO. Приоритет и режим работы PDO определяются параметрами, специфичными для соединения. Для управления PDO и поставщики PDO, и потребители PDO требуют соответствующих структур данных. Данные, необходимые поставщику PDO, ор- ганизованы в виде так называемых TxPDO / TPDO записей OD; данные, которые будут получены потребителем PDO, организованы в виде так называемых Rx-PDO / RPDO записей OD.

PDO linking (PDO связывание). PDO связывание представляет собой коммуникационное соединение между передаваемым PDO и соответствующими принимаемыми PDO. Коммуникационная связь образуется путем назначения одинакового PDO идентификатора для передачи и приема PDO.

PDO mapping (отображение объектов на PDO). Распределение поля данных PDO (макссимум 8 байт) между прикладными объектами определяется PDO отображением. Оно может быть статическим (то есть постоянным) или динамическим (то есть изменяемым).

Predefined connection set (заранее заданное распределение идентификаторов). Предопределенное распределение идентификаторов означает предопределенное назначение CAN, основанное на идентификаторе узла и коде функции. Для следующих коммуникационных объектов предопределенное распределение идентификаторов регулирует значение для COB-ID: охрана узла (Node guarding) /сердцебиение (heartbeat), аварийный объект (EMCY), посылка синхронизации (SYNC), временная метка (TIME), сервер SDO1, RPDO1 .. RPDO4 и TPDO1 .. TPDO4.

RPDO принимаемый объект данных процесса. См. также PDO.

Scan timeout (тайм-аут сканирования). Интервал времени, в течение которого устройство должно ответить, после того как было вызвано: для того, чтобы быть признанным присутствующим в сети CANopen.

SDO service data object - специальный объект CANopen, предназначенный для обслуживания узлов сети CAN. Это коммуникационный объект CANopen, используемый для конфигурирования и параметризации CANopen устройств. Он может использоваться для передачи больших объёмов данных (не ограниченных 8 байтами, как в PDO). Записи OD устройства могут быть доступны для чтения или записи через SDO. Необходимая запись объектного словаря адресуется через индекс и sub-индекс. SDO формирует прямой 1:1 канал связи между любыми двумя узлами в стиле клиент-сервер. Клиент запрашивает данные для чтения или записи, а сервер предоставляет данные. Обычно в качестве клиента выступает мастер сети, а сервером подчиненные узлв сети.

SDO timeout (тайм-аут SDO). На SDO-запрос должен быть дан ответ в течение времени тайм-аута. Время таймаута задается в миллисекундах.

Server SDO (сервер SDO). Каждое устройство должно поддерживать как минимум один сервер SDO, и таким образом предоставить доступ к записям в его OD. Спецификация объекта сервера SDO требует одного CAN идентификатора, определенного для каждого направления передачи, поскольку он является подтверждаемым сервисом. CAN идентификаторы первого сервера SDO (SDO1) зависят от идентификатора узла, и они строго регламентированы.

Примечание: некоторые простые устройства CANopen, которые не поддерживают конфигурирование, вообще не предоставляют поддержку протокола SDO. В таком случае для их подключения / опознания в сети требуется загрузка файла EDS.

SI unit International System of Units (SI-Units), интернациональная система единиц измерений. Представляет набор физических единиц системы измерения. Стандартизована серией международных спецификаций ISO/IEC 80000. Этот стандарт также определяет международную систему International System of Quantities (ISQ). Система SI-Units является почти глобально адаптированной: только Liberia, Myanmar и США не адаптировали SI-Units как свою официальную систему мер и весов.

Sync object / SYNC (объект синхронизации). Объект синхронизации используется для синхронизированного сбора данных, синхронизированного командного стробирования и циклической передачи данных процесса. Прием объекта синхронизации запускает обновление и передачу синхронных сообщений. Для этого одно устройство (поставщик синхронизации, SYNC producer) циклически передаёт высокоприоритетные объекты синхронизации. Для полного описания объект синхронизации требует задания параметра периода коммуникационного цикла и параметра длины синхронного окна. Если параметр инициализируется 0, он не имеет никакого эффекта.

Synchronous window length (длина окна синхронизации). Интервал времени после получения объекта синхронизации, когда должен быть отправлен PDO, имеющий тип синхронной передачи.

Timestamp message (сообщение метки времени). Используется для повторной синхронизации локальных таймеров, чтобы обеспечить более высокие требования базиса синхронизации для всех устройств системы.

Transmission type (тип передачи). Режим работы PDO указывается в коммуникационном профиле устройства через параметр "тип передачи". CANopen предоставляет следующие типы передачи для PDO: Synchronous (синхронная) - передача зависит от объекта синхронизации, либо Acyclic (ациклическая) - один раз или циклически, при каждом приёме или после некоторого количества объектов синхронизации, заданного через скорость передачи данных. Asynchronous (асинхронная) - передача инициируется специфичным для производителя событием или событием, определенным в профиле устройства. Remote (удалённая) - передача происходит только после RTR-запроса другим подписчиком (потребителем PDO).

Transmission rate (скорость передачи). В режиме циклического синхронного PDO это значение представляет число сообщений синхронизации, ко- торое должно быть получено до того, как будет разрешена повторная передача PDO.

TPDO (передаваемый объект данных процесса). Передаваемый PDO (см. PDO).

ПЛК программируемый логический контроллер.

узуфрукт из Википедии: (лат. usus — использование, лат. fructus — доход) — вещное право пользования чужим имуществом с правом присвоения доходов от него, но с условием сохранения его целостности, ценности и хозяйственного назначения. Предметом узуфрукта могут быть вещи, потребление которых возможно без их уничтожения, например, земельные участки, животные и, в классическом римском праве, рабы; 1) денежный капитал не может быть предметом узуфрукта. 2) Устанавливается пожизненно, на определённый срок, или с условием, наступление которого прекращает право узуфруктуария (пользователя имущества).

[Ссылки]

1. CANopen site:can-cia.org.
2. CANopen Basics site:canopensolutions.com.
3. CANopen – The standardized embedded network site:can-cia.org.
4. Free software CANopen framework site:canfestival.org.
5. CANopen Bootloader Protocol Stack site:microcontrol.net.
6. CANopenNode: CANopen based stack for communication in embeded control systems site:sourceforge.net.
7. Arduino Generic CAN Open Node site:github.com.
8. CANFestivino: Arduino Library Version of CANFestival CANopen Stack site:github.com.
9. CANopen MCP2515.
10. Протокол CanOpen site:robot-develop.org.
11. Порядок следования байт (endianness).
12. MCP2515: контроллер шины CAN с интерфейсом SPI.
13. CANopen high-level protocol for CAN-bus site:nikhef.nl.
14. AN945: стек CANopen для PIC18 ECAN.
15. CiA301: слой приложения и профиль коммуникации CANopen.

 

Комментарии  

 
+1 #1 Евгений 10.06.2019 09:03
Есть объект 1800h: Параметры TPDO 1
Индекс 1800h
Название TPDO 1 communication parameter
Тип данных PDO parameter record

Индекс 00h
Название highest sub-index supported
Стандартное значение 02h
Индекс 01h
Название COB-ID used by TPDO
Стандартное значение $NODEID+180h
Индекс 02h
Название transmission type
Стандартное значение FEh
Индекс 05h
Название event timer
Стандартное значение 01F4h

Объект 1A00h: Отображение TPDO 1
Название TPDO 1 mapping parameter
Тип данных PDO parameter record
Описание элемента
Индекс 00h
Название number of mapped objects
Стандартное значение 10h
Описание элемента
Индекс 01h
Название mapped object 1 – System state
Описание элемента
Индекс 02h
Название mapped object 2 – Active kit code

Как выдать через CAN данные по индексам 01h..10h?

microsin: судя по описанию, максимальный поддерживаемый индекс у этих объектов 02h, поэтому получить данные по индексам 03h..10h не получится.
Цитировать
 

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


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

Top of Page