Pdo canopen что значит

Введение в CANopen

CANopen — это открытая промышленная сеть созданная на основе Controller Area Network (CAN). Стандарт CAN (ISO 11898) описывает два нижних уровня эталонной модели ISO/OSI, CANopen описывает остальные пять. Документ The CANopen Application Layer and Communication Profile (CiA DS 301) определяет каким образом устройства обмениваются данными и описывает интерфейс к нижележащим уровням сети.

Основная область применения СANopen — встроенные роспределенные системы управления реального времени (embedded networks). СANopen фактически является стандартом и наиболее широко применяемым протоколом при создании современных систем управления в машиностроении (обрабатывающие станки различного назначения, термпопласт-автоматы, полиграфическое оборудование), железнодорожном транспорте (DIN 25002-2), специальном транспорте, сложном медицинском оборудовании, лифтах. CANopen не применяется в АСУТП.

Общая схема связи устройств в CANopen

Протокол CANopen определяет несколько методов передачи сообщений по сети CAN. Эти сообщения называются объектами связи (communication objects). CANopen поддерживает синхронизованную передачу сообщений, которая обеспечивается объектами Sync и Time Stamp. Асинхронные сообщения (или события) могут пересылаться в любой момент времени. В целом CANopen определяет четыре типа сообщений (communication objects):

• сообщения управления сетью, например Layer Management (LMT) и Network Management (NMT) сообщения
• так называемые Service Data Objects (SDO)
• так называемые Process Data Objects (PDO)
• Предопределенные сообщения (Sync Object, Time Stamp Object, Emergency Object)

Инициализация и управление сетью

Сервис управления сетью используется для контроля состояния устройств в сети CANopen. В рамках сервиса управления сетью доступны следущие функции:

• динамическое или статическое распределние идентификаторов CAN для SDO/PDO соединений и сервиса обработки ошибок,
• управление состоянием работы устройств и котроль режимов соединений в устройствах
• периодический опрос устройств для определения сбоев в устройствах
• вместо опроса каждое устройство может периодически посылать сообщение о том, что оно функционирует нормально

Механизм передачи данных

CANopen определяет два совершенно разных механизма передачи данных.

Service Data Object (SDO) механизм обычно используется для конфигурирования устройств низкой приоритетности. Отдельные параметры устройства адресуются при помощи 16 битного адреса и 8 битного подадреса. С помощью SDO можно передавать данные длиной больше восьми байт используя механизм фрагментации. Функциональность SDO:

• передача данных любого размера,
• чтение и запись любых данных с подтверждением,
• быстрая передача данных длиной до 4 байт,
• обрыв соединения с любого конца с передачей ошибки через сеть.

Все параметры устройства объеденены в object dictionary (словрь объектов), и все объекты в object dictionary могут быть прочитаны или изменены удаленно при помощи SDO.

Process Data Object (PDO) механизм используется для предачи с высокой скоростью высокоприоритетных данных, так как PDO сообщения не содержат никаких дополнительных протокольных данных. При помощи PDO можно передавать только данные длина которых меньше 8 байт. Формат данных PDO может быть фиксированным или может быть сконфигурирован при помощи SDO. PDO сообщения могут быть переданы одним узлом сразу нескольким другим узлам одновременно.

События

CANopen поддерживает несколько способов передачи данных реального времени.

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

Возможен синхронный режим передачи данных. В этом режиме устройства синхронизируют передачу данных в сеть с часами Master устройства. Этот режим особенно полезен когда контуры управления замыкаются через сеть (так называемые сетевые системы управления).

Кроме перечисленных выше способов передачи данных, можно использовать передачу по запросу (polling). В любой момент можно использовать PDO сообщение для инициации передачи данных устройством. Эта схема использует RTR бит CAN кадра.

Источник

Разработка роботов

Протокол CanOpen

Недавно перед нами встала необходимость объединить несколько устройств в CAN сеть. Одно из устройств было реализовано на базе чипа от Beck и программировалось из CodeSys, другое на базе ARM контроллера, а главным устройством в сети должен был быть персональный компьютер с UNIX подобной ОС на борту. После изучения существующих промышленных протоколов я остановился на CanOpen. Этот протокол оказался очень гибким, он позволяет настроить различные режимы работы сети. Но главное CanOpen поддерживается в CodeSys и существует реализация на C под персональные компьютеры и контроллеры. В этой статье я расскажу, что такое CanOpen и как его запустить на персональном компьютере, используя библиотеку от http://www.canfestival.org.

CanOpen

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

CANopen имеет два базовых механизма передачи данных:

• Высокоскоростной обмен небольшими объемами данных процесса через так называемые Process Data Objects — PDO
• Доступ к точкам входа в словаре объектов через Service Data Objects – SDO

Различают следующие PDO:

• Инициализируемые событием
• Циклические
• Запрашиваемые как широковещательные без дополнительной служебной информации протокола

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

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

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

Функциональность управления, например, контроль и мониторинг статуса связи узлов, выполняется с помощью протокола управления сетью (NMT), который основан на логическом взаимодействии master-slave. Для реализации функций мониторинга предназначено два механизма: Node-Guarding (защита узла) и Heartbeat (сердцебиение).

CanOpen PDO

Используются для обмена данными между узлами в реальном времени. Могут содержать не более 8 байт данных. У каждого PDO сообщения есть свой уникальный идентификатор COB-ID длинной в 11 бит, по нему определяется, какие именно данные находятся в пришедшем PDO сообщении. Этот идентификатор как имя структуры в языке C.

PDO могут передаваться несколькими способами:

1. По запросу на передачу от удалённого узла. Удалённый компьютер шлёт пустое PDO с требуемым COB-ID и выставленным битом RTR (Remote Transmition Request). Узел, получив такое сообщение, высылает требуемое PDO.
2. После получения SYNC сообщения. Главный узел в сети периодически шлёт всем остальным узлам SYNC сообщения, таким образом отсчитывая такты времени. Удалённые узлы знают какие PDO и на каких тактах они должны послать.
3. Асинхронная передача. Удалённый узел сам решает, когда он должен послать PDO.

В canfestival пользователь не должен слать и получать PDO сообщения напрямую. Необходимо в словаре объектов определить переменные, которые находятся в передаваемых и принимаемых PDO, а также указать способ передачи PDO. В пользовательском приложение нужно просто читать и писать значения этих переменных. Все операции с сетью будут делаться автоматически.

CanOpen SYNC протокол

Предназначен для синхронизации всех удалённых узлов в сети. Главный узел в сети с постоянным периодом шлёт SYNC сообщения. Удалённые узлы, получив такое сообщение, фиксируют информацию, которую нужно передать и при первой же возможности передают.

По умолчанию COB-ID SYNC сообщения 0x80 и оно не содержит данных. Параметры SYNC протокола находятся в объектах 0x1005 – COB-ID SYNC сообщения, 0x1006 – период цикла в микросекундах, 0x1007 – длина синхронного окна в микросекундах. Длина синхронного окна – время, за которое должны передаться все PDO. В CanFestival в объекте 0x1005 необходимо указывать 0x80000000 + (желаемое COB_ID).

CanOpen Heartbeat протокол

Предназначен для мониторинга состояния узлов. Удалённый узел с постоянным периодом шлёт определённые сообщения в сеть. По этим сообщениям главный компьютер понимает, что удалённый узел работает корректно (нет разрыва сети, удалённый узел не завис). Настраивается протокол при помощи объектов 0x1016 и 0x1017. Объект 0x1016 должен быть создан на главном компьютере, в нём указан период, с которым необходимо ожидать прихода сердцебиения, в миллисекундах. Объект 0x1017 должен быть создан на удалённом узле, в нём указан период в миллисекундах, с которым необходимо генерировать сердцебиение. Данный протокол имеет смысл использовать только, если PDO передаются в синхронном режиме, иначе он будет просто загружать сеть, а контроль удалённых узлов будет вестись по ответам на запросы RTR.

CanOpen NMT протокол

Позволяет управлять удалёнными узлами: запускать, останавливать, перезагружать, изменять состояние удалённого узла.

CanOpen узел может находиться в четырёх состояниях. Ниже приведена диаграмма состояний, стрелочками обозначены возможные переходы между состояниями. Полностью функционирует узел в Operational состоянии. В Pre-Operational состоянии узел может конфигурироваться при помощи SDO сообщений, PDO не работают.

CanOpen SDO протокол

Позволяет передавать данные произвольной длины. Сообщение делится на телеграммы по семь байт и последовательно передаётся через CAN. SDO сообщения имеют самый низкий приоритет, поэтому передаются довольно медленно.

CanOpen EDS файлы

Словарь объектов CanOpen узла может сохраняться в стандартизованном EDS файле. С такими EDS файлами умеют работать многие программы, их понимает CodeSys, утилита objdictedit из библиотеки CanFestival по этим файлам генерирует код на C.

Библиотека CanFestival под UNIX подобной ОС
В библиотеке реализована поддержка достаточно большого количества CAN плат, вам нужно лишь правильно собрать библиотеку, но, если вашей платы там нет, вам необходимо самому реализовать функции:

Как это сделать можете посмотреть в файле unix.c в папке drivers/unix.

После того как библиотека собрана и установлена запускаем утилиту objdictedit из папки objdictgen. В ней создаём новый файл, выбираем, что мы будем создавать: master или slave, указываем будем ли использовать SYNC и Heartbeat протоколы. После всего этого перед нами появляется словарь объектов.

В Communication Parameters можно настроить SYNC и Heartbeat протоколы. В Receive PDO Parameters и Transmit PDO Parameters можно создать и настроить отправляемые и получаемые PDO. В Manufacturer Specific можно создать переменные, которые будут спроецированы на PDO сообщения. В Receive PDO Mapping и Transmit PDO Mapping эти переменные можно спроецировать на PDO.

После того как словарь объектов создан жмём Build Dictionary – будут сгенерированы заголовочный файл и файл реализации на C.

В сгенерированном файле будут глобальные переменные на подобии моих:

CO_Data – это структура, описывающая CanOpen узел. UNS8 – переменные, спроецированные на PDO.

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

Источник

Протокол высокого уровня CANopen. Часть 2

На реальном примере рассматривается организация связи двух устройств с помощью протокола CANopen, поясняется работа с CANopen-стеком, приводится пример формирования словаря объектов

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

В роли устройства, поддерживающего CANopen, в данном случае, выступает изображенный на Рисунке 8 абсолютный энкодер CVM58 компании Pepperl+Fuchs [1]. Этот датчик может предоставлять информацию о положении вала, скорости его вращения и ускорении. CVM58 работает в промышленном диапазон температур при напряжении питания от 10 до 30 В.

Рисунок 8.	Абсолютный энкодер CVM58.

В качестве управляющего устройства, выдающего команды датчику угла поворота и принимающего от него данные, будет использоваться микроконтроллер dsPIC30F6014A [2], имеющий два модуля интерфейса CAN. В соответствии с напряжениями питания системы управления (3.3 В) и энкодера (12 В), в качестве приемопередатчика сети CAN была выбрана микросхема MAX3051 [3]. Схема соединения этих устройств показана на Рисунке 9.

Рисунок 9.	Схема организации CAN-сети, состоящей из двух узлов.

Написание полного стека CANopen с нуля может вызвать определенные затруднения и потребовать неприемлемых в некоторых случаях затрат времени, поэтому сегодня уже существует немалое количество библиотек для различных платформ, позволяющих адаптировать конкретное устройство для работы в сети CANopen. Например, в [4] представлен фреймворк CANopen с открытым исходным кодом CANFestival, в [5] – отечественная библиотека компании Марафон. В данном случае будем использовать стек CANopenNode [6], являющийся open-source проектом, активно совершенствуемым и сопровождаемым своим автором Янезом Патерностером (Janez Paternoster). Библиотека поддерживает контроллеры dsPIC30F, PIC24H, dsPIC33F, PIC32, Beck SC2x3, а также STM32F103 (официально пока не поддерживается). При желании этот стек можно адаптировать под любое ядро. Библиотека CANopenNode была написана на языке ANSI C с помощью методов объектно-ориентированного программирования.

За инициализацию и обработку данных каждого типа объектов протокола CANopen отвечают по два файла: файл с исходным кодом (расширение *.c) и заголовочный файл (расширение *.h). В итоге библиотека содержит следующие пары файлов для описания объектов:

• CO_SDO – описывает SDO-сервер;
• CO_SDOmaster – описывает SDO-клиент;
• CO_Emergency – описывает объект срочных сообщений и отвечает за обработку ошибок;
• CO_SYNC – описывает объект синхронизации;
• CO_PDO – описывает PDO-объекты;
• CO_HBconsumer – описывает потребителя Heartbeat-сообщений;
• CO_NMT_Heartbeat – описывает производителя NMT- и Heartbeat-сообщений.

Также в состав библиотеки входят следующие обязательные файлы:

• CANopen – является основным файлом CANopen-стека, представляет собой некое промежуточное звено между приложением и библиотекой;
• CO_OD – представляет собой объектный словарь, методика его создания и изменения приводится ниже;
• CO_driver – драйвер работы с модулем CAN, зависит от типа микроконтроллера (для определенного семейства микроконтроллеров предоставляются конкретные файлы CO_driver.c и CO_driver.h)
• eeprom – позволяет сохранять во внутренней памяти EEPROM данные из ОЗУ, так же зависит от семейства микроконтроллеров.

Как уже отмечалось в первой части статьи, очень важным элементом, определяющим работу сети, является объектный словарь. Для датчика CVM58N производитель предоставляет файл 1830845D.eds, сформированный в соответствии с профилем для энкодеров DS406 [7]. В eds-файле описываются объекты, поддерживаемые данным датчиком, значения объектов, выставленные по умолчанию, и приводится другая полезная информация.

Если о конфигурации энкодера позаботился производитель, то о настройке Master-узла сети (в данном случае микроконтроллера dsPIC30F6014A) должен позаботиться сам разработчик. Но благодаря предоставляемому вместе с библиотекой редактору словаря объектов (Object Dictionary Editor) осуществить это не представляет особого труда. Поскольку значение данного редактора очень велико, стоит описать его подробнее.

Сам редактор представляет собой web-приложение. Для редактирования словаря проекта должны иметься файлы _project.html и _project.xml. Можно не создавать их самому, а редактировать уже готовые файлы в составе примера, находящегося в папке CANopen310Example_IO скачанного архива библиотеки. Для входа в редактор необходимо открыть _project.html. Следует заметить, что файл корректно открывается только с помощью браузера Mozilla Firefox, причем для поддержки версии Firefox 4 и выше необходимо установить утилиту Remote XUL Manager [8]. На Рисунке 10 показано окно проекта с уже сгенерированными файлами объектного словаря.

Рисунок 10.	Окно конфигурации проекта.

Программа может даже создавать eds-файлы в соответствии со стандартами CiA. Однако нас здесь интересуют, в первую очередь, два файла – CO_OD.c и CO_OD.h, которые после их создания должны быть размещены в папке проекта наряду со всеми вышеперечисленными файлами. Но для начала нужно правильно сконфигурировать словарь Master-узла, для чего следует нажать кнопку Open Editor, после чего появится интерфейс самого редактора (Рисунок 11).

Рисунок 11.	Окно редактора словаря объектов.

В левом окне перечислены все доступные объекты, некоторые из них деактивированы для экономии памяти устройства. Для организации связи с датчиком необходимо произвести следующие изменения. Во-первых, в разделе Features необходимо присвоить записи NMT master значение 1 и обязательно нажать Update feature. Это позволит конфигурируемому узлу иметь статус NMT-Master и передавать NMT-сообщения для того, чтобы вводить в работу или останавливать другие узлы сети. Также обязательным, как будет доказано в дальнейшем, является присвоение узлу статуса SDO-клиента (значение SDO client установить в 1). В разделе Objects->Manuf можно изменить ID узла в сети (CAN node ID, индекс 0x2101), скорость передачи данных (CAN bit rate, индекс 0x2102) и некоторые другие менее значимые параметры. Следует помнить, что скорость передачи данных всех узлов сети должна быть одинаковой, а наличие в одной сети двух узлов с одинаковыми ID не допускается.

Теперь необходимо согласовать типы передаваемых данных. Передача будет осуществляться широковещательно с помощью PDO. Открыв eds-файл энкодера, с учетом комментариев и информации из [7], можно определить, что объект с индексом 0x6004 отвечает за передачу значений текущего положения вала датчика. Из его описания видно, что тип передаваемого параметра равен 7, то есть UNSIGNED32 (беззнаковое целочисленное значение длиной 32 бита). В соответствии с этим нужно указать для Master-узла в объекте отображения RPDO (индекс 0x1600) количество отображаемых объектов (подиндекс 0) и индекс объекта, куда будут записываться принимаемые значения (подиндексы 1-8). Рассмотрим данный подход на конкретном примере словаря из папки CANopen310Example_IO, который необходимо немного изменить для адаптации его к текущему проекту. Запись по подиндексу 0 имеет значение 2. Значит, здесь активированы mapped object 1 и mapped object 2 (подиндексы 1 и 2, соответственно). Впрочем, для текущей задачи хватит одного mapped object 1, поэтому при желании можно удалить mapped object 2, и далее будем рассматривать только mapped object 1. Значение по умолчанию в mapped object 1 указано 0x62000108. Это значит, что принимаемые PDO будут помещаться в поле с индексом 0x6200 и подиндексом 1. Последняя цифра 8 означает, что будут приниматься 8-разрядные данные. В данном случае это неприемлемо, поэтому для приема данных длиной 32 бита нужно изменить значение на 0x62000120. Соответственно, в описании объекта, куда будут записываться PDO, в поле Data type нужно установить 07 – UNSIGNED32. На этом основные изменения объектного словаря для данного проекта завершены. По желанию можно настроить еще множество объектов, например, изменить количество RPDO или TPDO, поменять время выдачи Heartbeat-сообщений и т.п.

Для экономии времени каркас программы желательно взять из примера CANopen310Example_IO, поскольку эта программа уже написана в соответствии с блок схемой, показанной на Рисунке 12.

Рисунок 12.	Общий принцип работы программы.

Здесь также используется таймер, по прерыванию от которого раз в миллисекунду выполняется обработка RPDO и TPDO с помощью функций CO_process_RPDO() и CO_process_TPDO(), соответственно. А по прерыванию от самого модуля CAN функцией CO_CANinterrupt() непосредственно обеспечивается прием и отправка сообщений. Стоит отметить, что в соответствии с методикой приема RPDO-сообщений, этот прием осуществляется по конкретной маске, которая позволяет принимать сообщения с определенными идентификаторами. В функции конфигурации RPDO CO_RPDOconfigCom() (файл CO_PDO.c) при инициализации буфера для приема (функция CO_CANrxBufferInit()) указана маска 0x7FF. Это позволяет принимать сообщения с любыми идентификаторами. Если необходимо принимать лишь определенные сообщения, то это число нужно изменить вручную.

Для возможности получения от датчика данных о положении его вала требуется решить одну проблему. Дело в том, что после перевода датчика в рабочий режим от него не последует какой-либо полезной информации, кроме Heartbeat-сообщений. Здесь следует учитывать, что за характер передачи PDO отвечают несколько объектов, для наглядности перечисленные в Таблице 3.

Таблица 3.	Режимы передачи PDO
Индекс 0x1800 Индекс 0x2800 Описание Подиндекс 2 Подиндекс 5 0x0FE 0 Цикличная передача каждые 10 мс 0x0FE 15 2 Цикличная передача каждые 15 мс, PDO отправляется дважды, если данные поменялись 0x0FE 0 0 Передача PDO отключена 0x0FE 0 xxx Передача PDO отключена 3 xxx 0 Передача после каждого третьего SYNC-сообщения 3 xxx 0x2D Передача после каждого третьего SYNC-сообщения, но только 45 (0x2D) раз

В объектном словаре этого энкодера приводятся следующие значения: 0x1800_2 = 0x0FE, 0x1800_5 = 0, 0x2800 = 0. То есть, при настройке по умолчанию PDO передаваться не будут.

Как отмечалось в первой части статьи, содержимое объектного словаря узла до перехода этого узла в рабочее состояние можно изменить с помощью SDO-сообщений. С этой целью и был присвоен Master-узлу статус SDO-клиента. Для изменения содержимого в 0x1800_5 на нужное значение, например, 50 (для отправки PDO каждые 50 мс), необходимо отправить SDO-сообщение, структура которого приведена в Таблице 4.

Таблица 4.	Формат SDO-сообщения для передачи данных.
COB ID DLC Команда Мл. байт индекса Ст. байт индекса Подинд. Байт 0 Байт 1 Байт 2 Байт 3 0x600 + ID узла 8 0x2F 0x2F 0x18 5 0x32 x x x

Команда 0x2F означает запрос на передачу данных длиной 1 байт. Чтобы осуществить такую операцию, на стадии инициализации следует вызвать две функции с определенными параметрами.

Первая:
CO_SDOclient_setup(*SDO_C, COB_IDClientToServer, COB_IDServerToClient, nodeIDOfTheSDOServer),

*SDO_C – указатель на объект SDO-клиента,

параметры COB_IDClientToServer и COB_IDServerToClient должны быть равны 0, если объект SDO-сервера имеет определенный по умолчанию COB ID,
nodeIDOfTheSDOServer – ID узла SDO-сервера.

Функция может быть записана так:
CO_SDOclient_setup(SDO_C, 0, 0, 5).

Вторая функция непосредственно предназначена для отправки SDO-сообщений, которые имеют длину данных не более 4 байт. Ее вид:

CO_SDOclientDownloadInitiate(*SDO_C, index, subIndex, *dataTx, dataSize),

*SDO_C – указатель на объект SDO-клиента,

index – индекс объекта в объектном словаре удаленного узла,

subIndex – его подиндекс,

*dataTx – указатель на массив данных,

dataSize – размер передаваемых данных в байтах.

В итоге, функцию можно записать так:
CO_SDOclientDownloadInitiate(SDO_C, 0x1800, 0x05, DataArray,1).

В данном случае DataArray содержит лишь один элемент со значением 50.

Теперь остается только включить датчик в работу, то есть перевести его в состояние Operational, и принимать от него данные. Поскольку dsPIC30F6014A в этой сети имеет статус NMT-Master, активировать энкодер можно с помощью следующей функции:

CO_sendNMTcommand(*CO, command, nodeID),

*CO – указатель на объект стека;

nodeID – ID Slave-узла.

В данном случае для запуска в работу узла с эта функция примет вид
CO_sendNMTcommand(CO,1,5).

Для остановки всех узлов в сети функция запишется следующим образом:
CO_sendNMTcommand(CO,2,0),

а для перевода узла с в состояние Pre-operational:
CO_sendNMTcommand(CO,0x80,5).

После запуска энкодера можно наблюдать отправку PDO-сообщений с периодичностью 50 мс (Рисунок 13).

Рисунок 13.	Цикличные PDO-сообщения в сети CAN, передающиеся с интервалом 50 мс: а) 25 мс/дел, 1 В/дел, б) 100 мкс/дел, 1 В/дел.

Сообщения автоматически принимаются модулем CAN Master-устройства и, в соответствии с установленной маской, записываются в объект, указанный при конфигурировании RPDO-отображения, то есть, в данном случае, в объект с индексом 0x6200.

Из детального рассмотрения принципов работы протокола CANopen видно, что задача организации отправки и приема сообщений не очень сложна. Был рассмотрен довольно простой пример настройки узлов сети CANopen и передачи информации о физической величине (положении вала) от датчика к управляющему устройству. Необходимо заметить, что возможности протокола, как и самого датчика, этим не ограничиваются. Для демонстрации преимущества статуса SDO-клиента кратко рассмотрим обмен дополнительными данными в процессе работы узлов сети CANopen. В рабочем режиме узлы также могут общаться между собой с помощью SDO-сообщений для обмена данными. Например, энкодер, помимо угла поворота вала, может сам измерять скорость вращения вала и ускорение. В соответствии с объектным словарем датчика, объекты, содержащие данные этих физических величин, имеют индексы 0x6030 и 0x6040 для скорости и ускорения, соответственно. SDO-клиент должен сделать запрос по соответствующему индексу объекта SDO-сервера, а SDO-сервер должен ответить сообщением, содержащим требуемые данные. Отправка запроса осуществляется с помощью все той же функции CO_SDOclientDownloadInitiate(), а прием ответного сообщения – с помощью функции CO_SDOclient_receive(). В Таблицах 5 и 6 показаны структуры кадра запроса на прием информации о скорости и ответного кадра, соответственно.

Таблица 5.	Формат SDO-сообщения для запроса на прием данных.
COB ID DLC Команда Мл. байт индекса Ст. байт индекса Подиндекс Байт 0 Байт 1 Байт 2 Байт 3 0x600 + ID узла 8 0x40 0 0 1 x x x x

Таблица 6.	Формат ответного SDO-сообщения.
COB ID DLC Команда Мл. байт индекса Ст. байт индекса Подиндекс Байт 0 Байт 1 Байт 2 Байт 3 0x600 + ID узла 8 0x43 0 0 1 a b c d

Команда 0x40 означает запрос на получение данных от сервера, а 0x43 – ответ сервера на передачу сообщения с длиной данных 4 байта. Получение информации об ускорении выполняется аналогично, и отличается только индексом объекта.

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

Источник