Михаил Русских
На реальном примере рассматривается организация связи двух устройств с помощью протокола 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_2 = 0x0FE, 0x1800_5 = 0, 0x2800 = 0. То есть, при настройке по умолчанию PDO передаваться не будут.
Как отмечалось в первой части статьи, содержимое объектного словаря узла до перехода этого узла в рабочее состояние можно изменить с помощью SDO-сообщений. С этой целью и был присвоен Master-узлу статус SDO-клиента. Для изменения содержимого в 0x1800_5 на нужное значение, например, 50 (для отправки PDO каждые 50 мс), необходимо отправить SDO-сообщение, структура которого приведена в Таблице 4.
| Таблица 4. | Формат SDO-сообщения для передачи данных. | ||||||||||||||||||||
|
|||||||||||||||||||||
Команда 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 – указатель на объект стека;
command – NMT-команда;
nodeID – ID Slave-узла.
В данном случае для запуска в работу узла с ID=5 эта функция примет вид
CO_sendNMTcommand(CO,1,5).
Для остановки всех узлов в сети функция запишется следующим образом:
CO_sendNMTcommand(CO,2,0),
а для перевода узла с ID=5 в состояние 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-сообщения для запроса на прием данных. | ||||||||||||||||||||
|
|||||||||||||||||||||
| Таблица 6. | Формат ответного SDO-сообщения. | |||||||||||||||||||||
|
||||||||||||||||||||||
Команда 0x40 означает запрос на получение данных от сервера, а 0x43 – ответ сервера на передачу сообщения с длиной данных 4 байта. Получение информации об ускорении выполняется аналогично, и отличается только индексом объекта.
Приведенный в данной статье пример работы простой сети CANopen демонстрирует гибкость и надежность протокола. При детальном рассмотрении сам протокол не кажется таким уж сложным, кроме того, сегодня существует немалое количество программного обеспечения, облегчающего труд при формировании объектного словаря и организации работы сети, а растущее число устройств, поддерживающих протокол CANopen, способствуют его популяризации.
Список источников
