Cia 402 управление приводами drives and motion control

CiA ® 402 series: CANopen device profile for drives and motion control

This set of profile specifications standardizes the functional behavior of controllers for servo drives, frequency inverters, and stepper motors. It also introduces several operation modes and corresponding configuration parameters. The profile description includes a finite state automaton (FSA) that defines internal and external device behavior for each state. The state of the drive determines which commands are accepted and whether high power is applied. States are changed when a control-word from the host-controller is received. They can also be changed due to internal events. The current state is indicated by the status-word. The control-word and different command values (e.g. velocity) are mapped into default RPDOs (receive process data objects). The status-word and different actual values (e.g. position) are mapped into TPDOs (transmit process data objects).

This profile has been partly internationally standardized in the IEC 61800-7 series. The original CiA 402 part 2 is now IEC 61800-7-201. It describes all functional behavior including the FSA and all process data and configuration parameters. CiA 402 part 3 contains mainly the PDO definitions, nowadays published in IEC 61800-7-301. The IEC standards are under systematic review and update. This second edition is already available as Draft International Standard.

Читайте также:  Полный привод митсубиси аутлендер 2007

The IEC standard of CiA 402 specifies a set of generic default PDOs available to all drives as well as a set of specific default PDOs applicable only to a specific class of drives such as servo drives, frequency inverters or stepper motors. CiA has developed a third set of standardized PDOs optimized for easy system integration (CiA 402 part 5). CiA 402 part 4 specifies the safety parameters and dedicated SRDO (safety-related data objects) parameters as defined in EN 50325-5 (CANopen Safety). This approach is based on the Generic Safety Drive Profile from Ethercat Technology Group (ETG). The CiA 319 framework provides guidelines to simplify the implementation and configuration of devices using CANopen Safety communication services.

In October 2016, CiA has released the CiA 402-6 specifying the default 64-byte PDO usage for CANopen FD networks. The PDO sets are defined for servo drives and stepper motors (use the same set), for frequency converters as well as for multiple-axes systems.

On the one hand, CiA 402 is one of the best-specified motion control profiles. On the other hand, the multitude of optional functions and parameters limits the exchangeability of devices compliant to CiA 402. Some vendors implement only a subset of the mandatory functions and parameters, but still claim CiA 402 conformity.


Русские Блоги

Код управления двигателем CiA402

CiA402 — это интерфейс между кодом привода управления двигателем на основе CANOPEN и уровнем связи:

  1. Переход конечного автомата
  2. CiA402 objects
  3. Поддержка режимов работы csp, csv, csp (циклическое синхронное положение), csv (циклическая синхронная скорость).
    CiA402 specific files:
    cia402appl.c: CiA402 driver implemention
    cia402appl.h: Driver profile specific objects, definitions and axes structres
Читайте также:  Уголки зеркал 2110 с тросовым приводом

All motion controller related values are encapsulated in structure TCiA402Axis(file cia402appl.h).
The configuration parameters and error codes are directly mapping functions(file: ecatappl.c).
Currently the sample support maximum of two axes. The axes are initialized in the EtherCAT state change from PREOP to SAFEOP.
objects: refer EL9300 and ETG.6010
State machine:

Operation modes:
csv: режим скорости периодической синхронизации.

csv: Принципиальная схема работы:

Интеллектуальная рекомендация

Рисуем девушку, которая будет сопровождать вас | Специальное предложение ко Дню святого Валентина

Счастливого дня Святого Валентина! Это ежегодный День святого Валентина. Это новый объект в этом году? Нарисуем один с кодом. Просто говори и делай это, поехали

План реализации На платформе Android .

Построение архитектуры проекта Vue2 (6) — интерфейс вызова axios, междоменная конфигурация прокси webpack

Поскольку Vue был обновлен до версии 2.0, официальный представитель больше не обновлял текущие основные проекты Vue-ресурса, и все они выбрали axios для выполнения запросов ajax. Использование аксиомо.

Проект Spark Treaming Real Time Flow 7 — Spark Treaking Battle 2

Проект Spark Treaking Real Time Please 1 — Распределенный журнал Collection Framework The Dume Orusure Spark Treaking Real Time Flow Project 2 — Распределенное сообщение Queu Kafka Обучение Spark Trea.

Настройка времени обдумывания навыков LoadRunner

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

Rabbitmq-C Исходный код Предварительное решение (1)

Благодаря потребностям проекта клиент RabbitMQ должен быть реализован на плате STM32 для подключения облачного сервера. Просмотр онлайн-информации, свеже портированного AMQP в STM32, клиент Rabbitmq -.


Using the CiA 402 Drive Profile for Motion Control Applications

The CAN in Automation (CiA) group has created unique device specifications for certain applications. One example we’ve highlighted before is CiA 417 which defines the CANopen Lift Application. Another is CiA 402 which defines the specification for devices that operate motors. This can include VFDs, Servo Drives, stepper drives, etc.

This post gives an overview of some of the main features of CiA 402, why a person would want to use it, and some considerations.

CiA402 – A Profile for Drives and Motion Control

The CAN bus protocol has had a lot of success since its initial creation for automotive applications. Over time the number of different vendors offering CAN products has increased along with the many different applications that use the protocol.

This has given rise to the need to create specifications for certain applications. Specifications help with interoperability and allow products to be more easily swapped out. They also help reduce development times by creating a common template.

The CiA 402 (also referred to as DS402) profile was created for motion controllers, VFDs, and servo drives that are operating motors. Here are a few important features of the DS402 profile.

Basic Definitions

CiA 402 defines some basic parameters. This includes identification parameters such as Vendor IDs, Product Codes, Serial Numbers, Fault codes, etc.

Other parameters are related to the motor type (stepper, AC servo) and nameplate information such as Motor rated current and Motor rated speed.

KEB’s Stepper module uses the CiA402 device profile

Other parameters exist that are operating mode-specific (more info on modes further on). Example mode-parameters include Target Torque, Max Torque, Max motor speed, etc.

These basic defined parameters function very similarly to EtherNet/IP’s AC Drive Profile. The idea is that the commonly used and required data is defined upfront. Also, the hex addresses for those parameters are defined and are fixed as well. So this basic information from Vendor A and Vendor B will be presented similarly.

Control & Status Words

The CiA 402 profile also defines the structure of the control and status words. The control word contains essential information such as: Enable voltage, Quick stop, Enable Operation, and Fault Reset.

The status word provides information that is sent from the drive device back to the controller. The status word contains information like Fault, Voltage Enabled, Warning, etc.

Both the control and status words leave bits open so they can be defined by the manufacturer. This gives the device manufacturer some flexibility to implement custom functions.

State Machine

The DS402 profile includes a state machine. The state machine covers the various states a drive can be in. These states include SWITCHED ON, FAULT, OPERATION ENABLE, etc…

The CiA 402 State Machine. As seen from Combivis

The drive’s state can be changed by the master controller over the control word. Or, the state can also be changed in reaction to an event (e.g. fault).

In turn, the current state of the drive is returned to the controller via the statusword. In this way, it is possible for the master control to monitor all drive axes in the case of multi-axis motion applications.

It is important to note that a drive must proceed through the state diagram logically. Therefore, if a person wants to start-up a drive and spin a motor then the drive must logically progress through a series of states until they reach the OPERATION ENABLE state.

Similarly, if the drive enters a fault state, it cannot be immediately run again. Rather, the fault must be cleared by first going into a FAULT RESET state – this can be done over the controlword.

Operating Modes

CiA 402 outlines basic operating Modes used in motion control applications. These Modes include Profile Positioning Mode, Velocity Mode, Torque Mode, Homing Mode, etc.

One important thing to note is that a vendor that says they comply with the CiA402 profile might meet parts of the standard, but not the entire specification. You should always verify with the device vendor if their product meets the specific functionality you are looking to implement.

Sample list of CiA 402 Operating Modes

For example, KEB drives like the S6 support the following modes: Profile Position, Velocity, Homing, Cyclic Sync Position, Cyclic Sync Velocity and Homing modes. However, not all of the 30+ homing routines outlined in the 402 specification are currently supported. The most common ones are, but the special-case ones are not.

CANopen over EtherCAT (CoE)

Where does the CiA402 profile fit in with EtherCAT? EtherCAT supports the CiA402 device profile through CANopen over EtherCAT (CoE). In fact, EtherCAT also supports other CANopen device profiles like CiA 406 (encoder profile) and CiA 408 (hydraulic device profile).

The CoE functionality is defined by the EtherCAT Technology Group (ETG.6010) and allows the DS 402 profiles to be mapped to EtherCAT. The EtherCAT state machine and the CAN state machine are similar enough with a few small exceptions.

6 Gen drives include CAN and EtherCAT

As standard, KEB 6 th generation drives like the S6 EtherCAT servo drive include hardware to support both CAN and EtherCAT – customers have the flexibility to choose what they want to use.

KEB Software Tools

KEB has a lot of nice tools on the controller and drive-side that will help a user set-up the CiA402 profile and CoE.

An engineer could use the many PLCopen function blocks and create their own function block for CiA402 control. However, this has already been done for you by KEB engineers.

For our controls products, a function block called KEB_CIA402_DriveControl is included in Combivis Studio 6. The function block includes all the necessary inputs to spin the motor and control through the various supported operating modes.

Combivis Studio includes a pre-engineered CiA402 Function Block in its library

On the drive side, Combivis includes a nice wizard with a graphical interface. The graphical interface allows a user to see the current machine state the drive is in. The user can also give inputs through the software to progress the drive through the states. This is great for troubleshooting and basic start-ups.

KEB’s Combivis software includes CiA402 commissioning tools


CiA 402 gives a machine builder flexibility. KEB offers a lot of compatible drive solutions for stepper, AC servos, and multi-axis applications. We also offer a lot of nice software tools to help with development and optimizing your machine.

Are you interested in CiA402 or CoE drives? If so, contact a KEB engineer today to discuss our many CiA402 drive options.


Cia 402 управление приводами drives and motion control

Самое общее представление о стандарте CANopen можно получить из русской Википедии, однако это не дает полной картины для понимания протокола, а просто объясняет общие термины. CANopen разработан как высокоуровневый сетевой протокол, работающий поверх физического протокола CAN (Controller Area Network), что позволяет осуществлять обмен данными между устройствами от разных производителей, и гарантирует взаимозаменяемость устройств. Здесь приведено общее описание стандарта, собранное из разных источников (см. «Ссылки»). Все непонятные термины и сокращения приведены в конце статьи (см. раздел «Словарик»). Здесь приведен перевод документации с сайта [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 ом). Дополнительно должны быть учтены максимально допустимые длины сегментов сети между отдельными сетевыми узлами — в зависимости от скорости передачи и параметров линии.

Рис. 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 Communication
Interface (интерфейс обмена)
Сервер для SDO
Клиент для PDO
NMT, SYNC, Emergency, Time Stamp, Heartbeat
Словарь объекта
Схема логической адресации для доступа к параметрам приложения и обмена данными, а также к данным и функциям
Процесс приложения (Application
Функциональность устройства

— Функции
— Данные
— Параметры

Данные процесса (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 можно передавать произвольный объем данных.

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

Байт 0 Байт 7

CAN-ID PDO2 Data 1
Data 2
Data 3
Target ?

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 осуществляется посылками, которые содержат не более 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), появляется в следующем виде:

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

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

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

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

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

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

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

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

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

Рис. 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 выгрузки иллюстрируется следующим образом:

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

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

Важным сервисом 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:

Каждое устройство должно поддерживать как минимум 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 доступа на запись.

Рис. 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
2 Тип BYTE
3 Inhibit time в миллисекундах WORD
5 Event timer (таймер события) WORD

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

Тип передачи PDO может быть установлен вторым sub-индексом. Для начала следует отличать друг от друга синхронные и асинхронные 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»), чтобы работа узлов началась одновременно.

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

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

Рис. 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.

NMT 000h
Sync 080h
TimeStamp 100h
Защита (Guarding)

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

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

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

Объект обмена (Communication
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
Мониторинг узла (NMT node monitoring) по принципу node guarding или heartbeat 700 + NodeID Transmit

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»:

Рис. 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»:

Рис. 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)

Более подробное описание содержимого этих профилей можно найти на сайте [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 Контроллер CAN Слой данных
Интерфейс обмена (Communication
Словарь объектов (Object
(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 ).

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

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

[Пакеты для 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 ).

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

[Инструменты для обслуживания и диагностики 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 ).

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

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

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

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

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

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

Этот продукт доступен в нескольких основных версиях: 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

[Свободный инструментарий для 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 .

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

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

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

Вы можете по адресу послать запрос на получение лицензии, в ответ Вам пришлют 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
2. CANopen Basics
3. CANopen – The standardized embedded network
4. Free software CANopen framework
5. CANopen Bootloader Protocol Stack
6. CANopenNode: CANopen based stack for communication in embeded control systems
7. Arduino Generic CAN Open Node
8. CANFestivino: Arduino Library Version of CANFestival CANopen Stack
9. CANopen MCP2515.
10. Протокол CanOpen
11. Порядок следования байт (endianness).
12. MCP2515: контроллер шины CAN с интерфейсом SPI.
13. CANopen high-level protocol for CAN-bus
14. AN945: стек CANopen для PIC18 ECAN.
15. CiA301: слой приложения и профиль коммуникации CANopen.


Есть объект 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 не получится.


Оцените статью
Авто Сервис