Canopen протокол: Обзор протокола CANopen | arm

CAN + CANOpen + CANfestival + STM32. Часть первая / STM32 / Сообщество EasyElectronics.ru

Совсем без теории, к сожалению, не получится. Поэтому вкратце вот о чем:

1. Пару слов о самом CAN
2. О самом CANOpen
3. И немного о CANfestival

Коротко о CAN

А вот с протоколом CANOpen двумя словами не отделаться.

Объектный словарь (Object dictionary) и что с ним делать

• SDO (service data object) — чтение и запись данных в OD по запросу.
• PDO (process data object) — сообщения для отправки данных асинхронно (хотя не обязательно). Как правильно через эти сообщения передаются текущие измерения и управляющие сигналы

SDO

Читать и писать в объектный словарь может ведущий в сети CANOpen или, как его часто называют, «мастер» (master). Как правило, когда мастер настраивает какой-либо узел, он при помощи SDO записывает в OD интересующие его параметры. Формат сообщения с запросом на чтение или запиись зависит от типа SDO — короткое однофреймовое (expedited) или длинное многофреймовое (segmented). Expedited-формат предназначен для обмена небольшим объемом данных — до 4-ех байт, для всего что больше нужен формат segmented.

Однофреймовый expedited-запрос формируется следующим образом (см. картинку ниже):

• 11-битный идентификатор = 0x600 + Node Id
• Длинна = 8 байт
• 0-ой байт данных — спецификатор команды, подробнее о нем ниже
• 1-2 байты данных — соответственно младший и старший байты интересующего индекса OD
• 3 байт — субиндекс OD
• 4-7 байты — данные, если это запись

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

• 11-битный идентификатор = 0x580 + Node Id
• Длинна = 8 байт
• 0-ой байт данных — спецификатор команды
• 1-2 байты данных — соответственно младший и старший байты интересующего индекса OD
• 3 байт — субиндекс OD
• 4-7 байты — данные, если это ответ на читающий запрос

Если запрос успешно выполнен то css будет равен 4, в случае же ошибки — 8. Всё остальное имеет тот же смысл, что и в запросе.
Для ясности приведу пример. Предположим, что нужно записать 4-ёх байтное число 0x12345678 в объектный словарь некоторого узла с Node Id равным 1 по индексу 0x2000 субиндексу 2. Фрейм с запросом будет выглядеть следующим образом:

ID = 0x601, len = 8, data = 0x23 0x00 0x20 0x02 0x78 0x56 0x34 0x12

Ответ в случае успеха будет выглядеть так:

ID = 0x581, len = 8, data = 0x60 0x00 0x20 0x02 0x00 0x00 0x00 0x00

Обращаю внимание, что данные во фрейме располагаются в порядке от младшего байта к старшему. Поэтому поле данных индекс представлен как 0x00 0x20, а данные идут байт за байтом 0x78 0x56 0x34 0x12.

Еще пример — запись 2-ух байт в индекс 0x2002 субиндекс 0x03:

И еще пример — 1 байт в индекс 0x2003 субиндекс 0x04:
Запрос
ID = 0x601, len = 8, data = 0x2F 0x03 0x20 0x04 0x12 0x00 0x00 0x00
Ответ
ID = 0x581, len = 8, data = 0x60 0x03 0x20 0x04 0x00 0x00 0x00 0x00

Многофреймовый вариант, описывать не стану, во-первых лень, а во-вторых смысла особого нет, т.к. если использовать готовый стек (CANFestival), то он заботливо скроет от разработчика низкоуровневые подробности.

PDO

txPDO0: ID = 0x180 + Node ID, Len = 8, Data = [8 байт данных]
txPDO1: ID = 0x280 + Node ID, Len = 8, Data = [8 байт данных]
txPDO2: ID = 0x380 + Node ID, Len = 8, Data = [8 байт данных]
txPDO3: ID = 0x480 + Node ID, Len = 8, Data = [8 байт данных]

rxPDO0: ID = 0x200 + Node ID, Len = 8, Data = [8 байт данных]
rxPDO1: ID = 0x300 + Node ID, Len = 8, Data = [8 байт данных]
rxPDO2: ID = 0x400 + Node ID, Len = 8, Data = [8 байт данных]
rxPDO3: ID = 0x500 + Node ID, Len = 8, Data = [8 байт данных]

Network Management (NMT)

• Initialization — состояние сразу подачи питания;
• PreOperational — «предбоевое» состояние. В это режиме узел уже шлет Heartbeat’ы (о них ниже), но еще не шлет и не принимает PDO;
• Operational — «боевой» режим, в котором узел шлет и принимает PDO;
• Stopped — режим полной остановки, узел будет недоступен даже по SDO. Предполагается, что в этот режим будут загонять устройство перед выключением.

Управление этими режимами осуществляется с помощью специальных сообщений имя которым NMT. Их формат следующий:

ID = 0x00, Len = 2, data = [cmd (1 байт)] [nodeId (1 байт)]

Heartbeat’ы и Node Guarding

ID = 0x700 + Node, ID Len = 1, data = [Mode (1 байт)]

Механизм Node Guarding исповедует прямо противоположный подход. Мастер периодически опрашивает при помощи NMT ведомые устройства на предмет их текущего режима. Нет ответа — нет узла.

Emergency

ID = 0x80 + Node Id, Len = 4..8, data = [Error Code(2 байта)] [Error Register(2 байта)] [Manufacturer Specific Error Field(0..4 байт)]

CANFestival

Ну так вот, в официальном репозитарии CANFestival помимо портов под Linux можно найти порты и под микроконтроллеры AVR. Подробно о том что в этом репозитарии, как портировать и создавать объектные словари и обособленные проекты расскажу во второй части, ибо силы писать эту статью уже кончились.

Заключение

CANopen — Википедия с видео // WIKI 2

CANopen — открытый сетевой протокол верхнего уровня для подключения встраиваемых устройств в бортовых транспортных и промышленных сетях. В качестве сетевого и транспортного уровня использует протокол реального времени CAN. Используется для связи датчиков, исполнительных механизмов и программируемых логических контроллеров между собой. Открытый стандарт.

Энциклопедичный YouTube

• 1/3

  Просмотров:

  5 295

  911

  48 362

• ✪ Станок для гибки проволоки

• ✪ КПиЯП – Лабораторная работа 1 – Знакомство с классами

• ✪ PROXIMAMENTE EL VIDEO TUTORIAL DE COMO PLEGAR CHAPA

Содержание

Типичные области применения

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

Достоинства

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

Недостатки

Малая распространённость за пределами Европы.

Перспективы

Помимо протокола прикладного уровня, CANopen означает членство в клубе разработчиков аппаратуры “по интересам”. Подробнее можно узнать на сайте CiA(www.can-cia.org). Вступить в данную организацию могут все, кто посчитает это нужным. Организация объединяет в том числе и ведущих производителей автомобилей в Европе.

Структура стандартов

Структура организации перекликается со структурой стандартов регламентирующих работу CANopen сетей.

В основе протокола прикладного уровня лежит документ DS.301, который в свою очередь является практическим развитием идей декларированных в документах CiA DS-201-207. Он определяет протоколы конфигурирования и функционирования сети.

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

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

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

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

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

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

• 1. Обмен функциональными данными в реальном времени ключевое слово PDO, CMS (основная подсистема, в принципе необязательная, но если не будет ни одной из остальных подсистем то данное пустое множество может называться CANopen лишь потенциально).

 ПРИМЕР  Система поддержания температуры в помещении основной блок, измерители температуры, нагреватели/испарители 

• Словарь объектов — это не подсистема ключевое слово PDO, SDO, entry, Index. Словарь используется всеми подсистемами и описывает целевые данные которыми надлежит обмениваться, правила обмена. Можно провести параллель с реестром в Windows.

 ПРИМЕР  Температура в отдельных точках и параметр управления нагревателями/испарителями

• 2. Синхронизация обмена данными ключевое слово SYNC (необязательная, но такая же целесообразная подсистема, как и подсистема 1). При использовании данной подсистемы в сети существует генератор синхросообщений, периодически передающий высокоприоритетное сообщение SYNC. После появления в сети такого сообщения все синхронизируемые устройства производят обмен данными в течение заданного временного интервала(окно синхронного обмена данными). Коллизии(одновременная передача данных двумя и более устройствами) разрешаются на уровне физического уровня протокола CAN. Словарь объектов содержит перекрёстные ссылки откуда какие данные взять, и какие куда положить. Таким образом приложения не занимаются самостоятельно сбором данных, просто в определённых переменных (с точки зрения приложения) периодически оказываются свежие данные. Аналогично с управляющими воздействиями. При этом режиме обмен может происходить не только между датчиками и основным блоком, но и между датчиками минуя основной блок.
• Асинхронный обмен данными. Включает обмен сообщениями сетевого управления (управления узлами сети) Network Management, NMT Services, сообщениями подсистемы контроля работы сети (вариант Обнаружения ошибок работы сети) Error Control, срочными сообщениями — авральными объектами (обнаружение ошибок работы узлов) Emergency Object, EMCY. Сообщения данного класса могут появиться в любой момент времени, в том числе и внутри окна синхронного обмена данными. Данные сообщения имеют высокий приоритет (выше, чем сообщений, составляющих пакеты данных), а коллизии разрешаются на уровне физического уровня протокола CAN. Для реализации данных подсистем в сети назначается (на этапе проектирования сети) устройство ответственное за работу конкретной подсистемы. Помимо этого имеются механизмы динамического назначения подобных устройств. Теперь подробно.
  • 3. Управление узлами сети Network Management, NMT Services (необязательная подсистема). Сеть может быть спроектирована таким образом что после включения каждый прибор, завершив инициализацию, перейдёт в состояние готовности, но при этом не будет участвовать в обмене функциональными данными до тех пор, пока мастер управления работой сети (NMT master) не разрешит его работу. В состоянии готовности устройство не принимает участие в обмене функциональными данными но может обмениваться технологическими данными. В состоянии готовности устройство может быть сконфигурировано(см далее Подсистема управления словарём объектов). При помощи данной подсистемы мастер сети может выполнить сброс и перезапуск любого из узлов, для которого потребуется такая процедура. Мастер получает от прибора сообщения, в которых указано реальное состояние прибора, если реальное состояние не соответствует ожидаемому, то это расценивается как ошибка. Реакции на ошибки рассмотрены ниже по тексту.
  • 4. Контроль работы сети (обнаружение ошибок работы сети) NMT Error Control Protocols, Node Guarding, Heartbeat Protocol (необязательная подсистема). Некоторые системы (особенно связанные с безопасностью) должны контролировать наличие и исправность всех штатных датчиков.

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

Обнаружение ошибок работы сети (Node Monitoring) производится двумя сходными способами^[1]

• • • I. Перекличка узлов Node Guarding. Мастер периодически опрашивает узлы, которые отвечают. Как только узел перестаёт отвечать, отмечается ошибка для этого датчика, и мастер в соответствии с логикой работы может остановить потенциально опасные процессы. Узел, который не будет опрошен в течение определённого времени (оборвалась линия), также отмечает для себя ошибку. Недостатки этого способа – запросы от мастера отнимают часть пропускной способности сети и отказ единственного узла (мастера) приводит к отказу всей сети.
    • II. Контрольное тактирование. Heartbeat (букв. англ. “сердцебиение”). Все узлы сети самостоятельно, без запроса, регулярно передают сообщения о своём состоянии – “heartbeat message”. Если в течение контрольного интервала сообщения от какого-то узла отсутствуют, другие узлы, подписанные на его сообщения, отмечают для себя ошибку. Этот способ лишён недостатков предыдущего и рекомендован к применению в современных системах^[2].

Для каждой конкретной сети допускается использование только одного способа контроля или Node Guarding или Heartbeat Protocol.

• • 5. Изменение объектного словаря. ключевые слова PDO, SDO, PDO-mapping Объектный словарь содержит данные которыми производится обмен по принципу PDO, описывает состав и структуру этих данных. Используя обмен данными по запросу(SDO) можно изменить набор данных которыми будет производиться обмен по принципу PDO. Обмен SDO данными возможен как в состоянии готовности, так и в состоянии работы. Таким образом имеется возможность после включения питания, но до запуска функционирования сети, настроить все приборы сети на обмен нужными данными, а затем запустить сеть. Во время изменения структуры словаря во время работы следует учитывать следующие моменты:
  • SDO обмен имеет более низкий приоритет чем обмен PDO, поэтому может возникнуть момент времени, когда часть словаря уже будет изменена в соответствии с новыми требованиями, часть ещё не изменится и в этот момент произойдёт обмен PDO.
  • Поскольку устройства передающие и принимающие PDO должны понимать друг друга, то может возникнуть ситуация когда одно устройство будет работать с новой структурой, а другое со старой.

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

• • 6. Изменение данных по запросу. Помимо изменения словаря приложение одного устройства может загрузить данные в другое устройство. Отличие PDO и SDO обмена данными с точки зрения приложения. При обмене PDO всё происходит автоматически по определённым правилам и приложение не обращаясь к сетевым примитивам получает данные из переменных, как будто бы данные получаются внутри э того самого прибора. Для получения данных по принципу SDO приложение должно при помощи сетевых сервисов запросить данные у другого устройства, и только потом получив ответ использовать данные для работы. Поэтому основу-хребет обмена данными следует строить на PDO-обмене. К сожалению имеются ограничения на размер данных(8 байт для PDO, но можно использовать несколько таких штук). И только при особой необходимости использовать SDO. При SDO обмене данными, устройство к которому обратились с запросом на получение или запись(dowload/upload) данных называется SDO сервером, а устройство которое инициировало обмен называется клиентом. В зависимости от объема передаваемых данных, обмен производится по разным алгоритмам, и может быть не менее эффективен чем PDO обмен. SDO обмен допускает производить контроль безошибочности данных, что позволяет даже загрузку кусков исполняемого кода.

• • 7. Авральные объекты, срочные сообщения.Emergency Object, EMCY. В процессе работы прибор может обнаружить ошибки в работе своей программы, или в работе электроники. В таком случае чем скорей об этом будут оповещены все остальные части системы, тем будет лучше и работа такой системы будет безопасней. Для этой цели используются высокоприоритетные срочные сообщения. Такие сообщения посылаются в момент обнаружения неисправности, и в момент исчезновения этой неисправности. Стандарт описывает классы ошибок, такими параметрами могут быть Ток, напряжение, температура. Если в сети задействован механизм срочных сообщений, то устройства обязаны понимать по край мере два сообщения — Общая ошибка(без уточнения категорий), сброс ошибки. Каждый тип ошибки может быть уточнён ещё целым байтом, который может кодировать например номер контролируемой цепочки.

• • Обработка ошибок. Базовый стандарт описывает только способы оповещения об ошибках и задаёт категории ошибок. Дальнейшие уточнение, и реакция на ошибку определяется разработчиком системы.

Приведённые выше пункты описываются в документах CiA DS-201-207 и CiA DS-301 Разработчик системы «с нуля» может самостоятельно определить функциональные требования к сетке, контролируемые параметры и сценарии поведения при появлении неисправностей. Но поскольку CANopen сети использует большое количество производителей, которые уже разработали системы, охватывающие множество сфер промышленности, то появились рекомендации того, какими параметрами, как минимум, должна оперировать та или иная система, и какие типы реакций на те или иные конкретные ошибки, которые свойственны конкретному классу устройств. Данные рекомендации оформлены в виде стандартов серий CiA DS-4**. Это позволяет производить не системы в целом, а части систем, и эти новые приборы будут прекрасно интегрироваться с системами разработанными именитыми производителями. Часть этих стандартов уже открыты(устоявшиеся), часть остаются достоянием небольших групп производителей(новые, подверженные изменениям). Основная причина того что существует так много закрытых документов та, что это не просто рекомендации, но стандарты при несоблюдении которых нарушается работоспособность системы. При внесении изменений в документы, новые версии рассылаются всем участникам данной группы «по интересам». Группы по интересам не являются замкнутой кастой, все желающие могут вступить в ту или иную группу. Обязательным условием является денежный взнос. Взимаемые суммы зависят от размера фирмы, и являются демократичными по отношению к малому бизнесу.

РАЗМЕР ФИРМЫ                        ЧЛЕНСКИЙ ВЗНОС(ГОД)     С УЧЁТОМ ГЕРМАНСКИХ НАЛОГОВ   
более чем    100 000   сотрудников: 8 700,00 Euro           10 353,00 Euro                
от 10 000 до 99 999    сотрудников: 5 200,00 Euro           6 188,00  Euro                
от 1 000  до 9 999     сотрудников: 4 100,00 Euro           4 879,00  Euro                
от 100    до 999       сотрудников: 2 100,00 Euro           2 499,00  Euro                
от 50     до 99        сотрудников: 1 500,00 Euro           1 785,00  Euro                
от 10     до 49        сотрудников: 900,00   Euro           1 071,00  Euro                 
от 1      до 9         сотрудников: 650,00   Euro           773,50    Euro                
для школ и университетов          : 520,00 Euro             618,80    Euro                

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

Промышленные сети семейства CAN

См. также

CiA (англ.).

Примечания

Ссылки

Введение в CANopen | CAN – технологии

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 плат, вам нужно лишь правильно собрать библиотеку, но, если вашей платы там нет, вам необходимо самому реализовать функции:

UNS8 canReceive(CAN_HANDLE, Message *);
UNS8 canSend(CAN_HANDLE, Message const *);
CAN_HANDLE canOpen(s_BOARD *);
int canClose(CAN_HANDLE);
UNS8 canChangeBaudRate(CAN_HANDLE, char *);

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

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

/* Master node data struct */
extern CO_Data PC_Data;
extern UNS8 IN_1;              /* Mapped at index 0x2000, subindex 0x00*/
extern UNS8 OUT_1;             /* Mapped at index 0x2001, subindex 0x00*/

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

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

CO_Data *m_nodeData = & PC_Data;

Инициализация CanOpen:

// Open the Peak CANOpen device
if(! canOpen( & m_board, m_nodeData ) )
    return false;
// Defining the node Id
setNodeId( m_nodeData, ID );
// Start Timer thread
StartTimerLoop( & init );
// Put the master in operational mode
setState( m_nodeData, Initialisation );
setState( m_nodeData, Operational );

Остановка CanOpen стека:

// Stop timer thread
StopTimerLoop( & exit );
// Close CAN board
canClose( m_nodeData );
TimerCleanup( );

Запуск удалённого узла с ID равным nodeID.

masterSendNMTstateChange( m_nodeData, nodeID, NMT_Start_Node );

Останов удалённого узла с ID равным nodeID.

masterSendNMTstateChange( m_nodeData, nodeID, NMT_Stop_Node );

Перезагрузка удалённого узла с ID равным nodeID.

masterSendNMTstateChange( m_nodeData, nodeID, NMT_Reset_Node );

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

sendPDOrequest( m_nodeData, RPDOIndex );

Мы не впервые используем промышленные сети. Для сетей RS-485 мы используем протокол Modbus RTU.

Спецификации протокола CANopen | CAN – технологии

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

В настоящее время реализованы следующие прикладные профили CANopen:
    CiA 401: профиль устройства ввода/вывода общего применения
    CiA 402: профиль устройства-привода электродвигателя (сервоприводы, шаговые двигатели, частотные инверторы)
    CiA 404: профиль устройства-контроллера с обратной связью
    CiA 406: профиль устройства-кодела (линеного и вращающегося)
    CiA 408: профиль устройства- гидравлического клапана и гидротрансмиссии
    CiA 410: профиль для инклинометра
    CiA 412: семейство профилей для устройств медицинского назначения (коллиматоры, дозиметры и т.п.)
    CiA 413: семейство профилей для шлюзов в грузовых автомобилях
    CiA 414: семейство профилей для швейных машин
    CiA 415: прикладной прфиль для датчиков в дорожных машинах
    CiA 416: прикладной прфиль для систем управления дверями в зданиях
    CiA 417: прикладной прфиль для систем управления лифтами
    CiA 418: профиль устройства – аккумуляторный блок
    CiA 419: профиль устройства- зарядное устройств для аккумуляторов
    CiA 420: семейство профилей для термполаст-автоматов
    CiA 421: прикладной профиль для системы управления пассажирского поезда (платформа для интеграции подуровней системы управления)
    CiA 422: прикладной профиль для специального муниципального транспорта (мусоровозы и т.п.)
    CiA 423: прикладной профиль для двигательной установки пассажирского поезда
    CiA 424: прикладной профиль для управления дверями пассажирского поезда
    CiA 425: семейство профилей для медицинских вспомогательных устройств
    CiA 426: прикладной профиль для управления внешними осветительными приборами ж/д поезда (локомотива)
    CiA 430: прикладной профиль для вспомогательных систем пассажирского поезда
    CiA 433: прикладной профиль для управления вну тренними осветительными приборами ж/д поезда
    CiA 434: семейство профилей для автоматизации лабораторного оборудования – Часть 1: Общие определения.
    CiA 436: семейство профилей для строительных машин
    CiA 437: прикладной профиль для распределительных электросетей на основе солнечных батарей
    CiA 443: профили для SIIS-устройств (простые датчики и многфункциональные измерители, применяемые в подводных промышленных системах)
    CiA 444: семейство профилей для дополнительных устройств кранов (портовых и т.п.)
    CiA 445: профиль RFID-считывателя
    CiA 446: профиль шлюза CANopen – AS-Interface (Actuator Sensor Interface)
    CiA 447: прикладной прфиль для дополнительных (вспомогательных) устройств в легковых автомобилях (такси, полицейские машины)
    CiA 450: профиль устройства – насос
    CiA 452: профиль устройства  PLCopen контроллер движения
    CiA 453: профиль устройства – источник питания
    CiA 455: прикладной профиль для буровых машин

Спецификации протокола высокого уровня CANopen разрабатываются, поддерживаются и распространяется некоммерческой организацией CAN in Automation (CiA). Члены организации имеют доступ ко всем спецификациям как принятым, так и находящимся в стадии разработки свободно. Не члены организации могут получить спецификации по запросу на сайте CiA

CANopen — Википедия. Что такое CANopen

CANopen — открытый сетевой протокол верхнего уровня для подключения встраиваемых устройств в бортовых транспортных и промышленных сетях. В качестве сетевого и транспортного уровня использует протокол реального времени CAN. Используется для связи датчиков, исполнительных механизмов и программируемых логических контроллеров между собой. Открытый стандарт.

Типичные области применения

В основном в системах управления перемещением, в сборочных, сварочных и транспортировочных агрегатах. Используется для однокабельного соединения многовходовых блоков датчиков, интеллектуальных датчиков, пневматических вентилей, считывателей штрих-кодов, приводов и операторских пультов.

Достоинства

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

Недостатки

Малая распространённость за пределами Европы.

Перспективы

Помимо протокола прикладного уровня, CANopen означает членство в клубе разработчиков аппаратуры “по интересам”. Подробнее можно узнать на сайте CiA(www.can-cia.org). Вступить в данную организацию могут все, кто посчитает это нужным. Организация объединяет в том числе и ведущих производителей автомобилей в Европе.

Структура стандартов

Структура организации перекликается со структурой стандартов регламентирующих работу CANopen сетей.

В основе протокола прикладного уровня лежит документ DS.301, который в свою очередь является практическим развитием идей декларированных в документах CiA DS-201-207. Он определяет протоколы конфигурирования и функционирования сети.

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

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

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

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

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

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

• 1. Обмен функциональными данными в реальном времени ключевое слово PDO, CMS (основная подсистема, в принципе необязательная, но если не будет ни одной из остальных подсистем то данное пустое множество может называться CANopen лишь потенциально).

 ПРИМЕР  Система поддержания температуры в помещении основной блок, измерители температуры, нагреватели/испарители 

• Словарь объектов — это не подсистема ключевое слово PDO, SDO, entry, Index. Словарь используется всеми подсистемами и описывает целевые данные которыми надлежит обмениваться, правила обмена. Можно провести параллель с реестром в Windows.

 ПРИМЕР  Температура в отдельных точках и параметр управления нагревателями/испарителями

• 2. Синхронизация обмена данными ключевое слово SYNC (необязательная, но такая же целесообразная подсистема, как и подсистема 1). При использовании данной подсистемы в сети существует генератор синхросообщений, периодически передающий высокоприоритетное сообщение SYNC. После появления в сети такого сообщения все синхронизируемые устройства производят обмен данными в течение заданного временного интервала(окно синхронного обмена данными). Коллизии(одновременная передача данных двумя и более устройствами) разрешаются на уровне физического уровня протокола CAN. Словарь объектов содержит перекрёстные ссылки откуда какие данные взять, и какие куда положить. Таким образом приложения не занимаются самостоятельно сбором данных, просто в определённых переменных (с точки зрения приложения) периодически оказываются свежие данные. Аналогично с управляющими воздействиями. При этом режиме обмен может происходить не только между датчиками и основным блоком, но и между датчиками минуя основной блок.
• Асинхронный обмен данными. Включает обмен сообщениями сетевого управления (управления узлами сети) Network Management, NMT Services, сообщениями подсистемы контроля работы сети (вариант Обнаружения ошибок работы сети) Error Control, срочными сообщениями — авральными объектами (обнаружение ошибок работы узлов) Emergency Object, EMCY. Сообщения данного класса могут появиться в любой момент времени, в том числе и внутри окна синхронного обмена данными. Данные сообщения имеют высокий приоритет (выше, чем сообщений, составляющих пакеты данных), а коллизии разрешаются на уровне физического уровня протокола CAN. Для реализации данных подсистем в сети назначается (на этапе проектирования сети) устройство ответственное за работу конкретной подсистемы. Помимо этого имеются механизмы динамического назначения подобных устройств. Теперь подробно.
  • 3. Управление узлами сети Network Management, NMT Services (необязательная подсистема). Сеть может быть спроектирована таким образом что после включения каждый прибор, завершив инициализацию, перейдёт в состояние готовности, но при этом не будет участвовать в обмене функциональными данными до тех пор, пока мастер управления работой сети (NMT master) не разрешит его работу. В состоянии готовности устройство не принимает участие в обмене функциональными данными но может обмениваться технологическими данными. В состоянии готовности устройство может быть сконфигурировано(см далее Подсистема управления словарём объектов). При помощи данной подсистемы мастер сети может выполнить сброс и перезапуск любого из узлов, для которого потребуется такая процедура. Мастер получает от прибора сообщения, в которых указано реальное состояние прибора, если реальное состояние не соответствует ожидаемому, то это расценивается как ошибка. Реакции на ошибки рассмотрены ниже по тексту.
  • 4. Контроль работы сети (обнаружение ошибок работы сети) NMT Error Control Protocols, Node Guarding, Heartbeat Protocol (необязательная подсистема). Некоторые системы (особенно связанные с безопасностью) должны контролировать наличие и исправность всех штатных датчиков.

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

Обнаружение ошибок работы сети (Node Monitoring) производится двумя сходными способами^[1]

• • • I. Перекличка узлов Node Guarding. Мастер периодически опрашивает узлы, которые отвечают. Как только узел перестаёт отвечать, отмечается ошибка для этого датчика, и мастер в соответствии с логикой работы может остановить потенциально опасные процессы. Узел, который не будет опрошен в течение определённого времени (оборвалась линия), также отмечает для себя ошибку. Недостатки этого способа – запросы от мастера отнимают часть пропускной способности сети и отказ единственного узла (мастера) приводит к отказу всей сети.
    • II. Контрольное тактирование. Heartbeat (букв. англ. “сердцебиение”). Все узлы сети самостоятельно, без запроса, регулярно передают сообщения о своём состоянии – “heartbeat message”. Если в течение контрольного интервала сообщения от какого-то узла отсутствуют, другие узлы, подписанные на его сообщения, отмечают для себя ошибку. Этот способ лишён недостатков предыдущего и рекомендован к применению в современных системах^[2].

Для каждой конкретной сети допускается использование только одного способа контроля или Node Guarding или Heartbeat Protocol.

• • 5. Изменение объектного словаря. ключевые слова PDO, SDO, PDO-mapping Объектный словарь содержит данные которыми производится обмен по принципу PDO, описывает состав и структуру этих данных. Используя обмен данными по запросу(SDO) можно изменить набор данных которыми будет производиться обмен по принципу PDO. Обмен SDO данными возможен как в состоянии готовности, так и в состоянии работы. Таким образом имеется возможность после включения питания, но до запуска функционирования сети, настроить все приборы сети на обмен нужными данными, а затем запустить сеть. Во время изменения структуры словаря во время работы следует учитывать следующие моменты:
  • SDO обмен имеет более низкий приоритет чем обмен PDO, поэтому может возникнуть момент времени, когда часть словаря уже будет изменена в соответствии с новыми требованиями, часть ещё не изменится и в этот момент произойдёт обмен PDO.
  • Поскольку устройства передающие и принимающие PDO должны понимать друг друга, то может возникнуть ситуация когда одно устройство будет работать с новой структурой, а другое со старой.

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

• • 6. Изменение данных по запросу. Помимо изменения словаря приложение одного устройства может загрузить данные в другое устройство. Отличие PDO и SDO обмена данными с точки зрения приложения. При обмене PDO всё происходит автоматически по определённым правилам и приложение не обращаясь к сетевым примитивам получает данные из переменных, как будто бы данные получаются внутри э того самого прибора. Для получения данных по принципу SDO приложение должно при помощи сетевых сервисов запросить данные у другого устройства, и только потом получив ответ использовать данные для работы. Поэтому основу-хребет обмена данными следует строить на PDO-обмене. К сожалению имеются ограничения на размер данных(8 байт для PDO, но можно использовать несколько таких штук). И только при особой необходимости использовать SDO. При SDO обмене данными, устройство к которому обратились с запросом на получение или запись(dowload/upload) данных называется SDO сервером, а устройство которое инициировало обмен называется клиентом. В зависимости от объема передаваемых данных, обмен производится по разным алгоритмам, и может быть не менее эффективен чем PDO обмен. SDO обмен допускает производить контроль безошибочности данных, что позволяет даже загрузку кусков исполняемого кода.

• • 7. Авральные объекты, срочные сообщения.Emergency Object, EMCY. В процессе работы прибор может обнаружить ошибки в работе своей программы, или в работе электроники. В таком случае чем скорей об этом будут оповещены все остальные части системы, тем будет лучше и работа такой системы будет безопасней. Для этой цели используются высокоприоритетные срочные сообщения. Такие сообщения посылаются в момент обнаружения неисправности, и в момент исчезновения этой неисправности. Стандарт описывает классы ошибок, такими параметрами могут быть Ток, напряжение, температура. Если в сети задействован механизм срочных сообщений, то устройства обязаны понимать по край мере два сообщения — Общая ошибка(без уточнения категорий), сброс ошибки. Каждый тип ошибки может быть уточнён ещё целым байтом, который может кодировать например номер контролируемой цепочки.

• • Обработка ошибок. Базовый стандарт описывает только способы оповещения об ошибках и задаёт категории ошибок. Дальнейшие уточнение, и реакция на ошибку определяется разработчиком системы.

Приведённые выше пункты описываются в документах CiA DS-201-207 и CiA DS-301 Разработчик системы «с нуля» может самостоятельно определить функциональные требования к сетке, контролируемые параметры и сценарии поведения при появлении неисправностей. Но поскольку CANopen сети использует большое количество производителей, которые уже разработали системы, охватывающие множество сфер промышленности, то появились рекомендации того, какими параметрами, как минимум, должна оперировать та или иная система, и какие типы реакций на те или иные конкретные ошибки, которые свойственны конкретному классу устройств. Данные рекомендации оформлены в виде стандартов серий CiA DS-4**. Это позволяет производить не системы в целом, а части систем, и эти новые приборы будут прекрасно интегрироваться с системами разработанными именитыми производителями. Часть этих стандартов уже открыты(устоявшиеся), часть остаются достоянием небольших групп производителей(новые, подверженные изменениям). Основная причина того что существует так много закрытых документов та, что это не просто рекомендации, но стандарты при несоблюдении которых нарушается работоспособность системы. При внесении изменений в документы, новые версии рассылаются всем участникам данной группы «по интересам». Группы по интересам не являются замкнутой кастой, все желающие могут вступить в ту или иную группу. Обязательным условием является денежный взнос. Взимаемые суммы зависят от размера фирмы, и являются демократичными по отношению к малому бизнесу.

РАЗМЕР ФИРМЫ                        ЧЛЕНСКИЙ ВЗНОС(ГОД)     С УЧЁТОМ ГЕРМАНСКИХ НАЛОГОВ   
более чем    100 000   сотрудников: 8 700,00 Euro           10 353,00 Euro                
от 10 000 до 99 999    сотрудников: 5 200,00 Euro           6 188,00  Euro                
от 1 000  до 9 999     сотрудников: 4 100,00 Euro           4 879,00  Euro                
от 100    до 999       сотрудников: 2 100,00 Euro           2 499,00  Euro                
от 50     до 99        сотрудников: 1 500,00 Euro           1 785,00  Euro                
от 10     до 49        сотрудников: 900,00   Euro           1 071,00  Euro                 
от 1      до 9         сотрудников: 650,00   Euro           773,50    Euro                
для школ и университетов          : 520,00 Euro             618,80    Euro                

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

Промышленные сети семейства CAN

См. также

CiA (англ.).

Примечания

Ссылки

Решение для управления движением на базе шины CANopen

Компания ICP DAS производит множество устройств для автоматизации промышленных процессов, в том числе решений на базе шины CANopen. Чтобы упростить разработку CANopen систем ICP DAS создала библиотеку CANopen motion library, которая поможет быстрее создавать различные системы, ориентированные на управление движением.

CANopen motion library основанная на стандарте CiA 402, предоставляет различные функции, такие как управление положением, скоростью, моментом, синхронизацией действий, режим интерполяции и т.д. Что позволяет создавать системы с множеством осей вращения и устройствами CANopen Slave подключенными к одному контроллеру.

Основные особенности библиотеки:

• Совместима со стандартом CiA 402 v1.1
• Поддержка до 127 двигателей в одной сети
• Абсолютное и относительное управление положением
• Контроль скорости и крутящего момента
• Поддержка синхронизации действий для 127 двигателей
• Поддержка управления интерполяцией для 32 двигателей
• Поддержка различных методов управления
• Поддержка ограничения крутящего момента с помощью команд CANopen
• Поддержка node guarding и heartbeat протоколов
• Поддержка динамической конфигурации PDO
• Расстояние между узлами от 25 м до 5000 м
• Поддержка скорости до 1 Мбит/с

Поддерживаются двигатели:

Преимущества использования CANopen сети:

• Она подходит для распределенной системы управления движением с множеством осей вращения
• Высокая скорость передачи информации до 1 Мбит/с
• Снижает стоимость и затраты на прокладку проводов
• Пользователи имеют свободу выбора из нескольких вариантов двигателей, не ограничиваясь определенной маркой
• Шина CAN имеет аппаратные функции обнаружения и исправления ошибок, которые повышают безопасность всей системы
• CANopen модули ввода-вывода и двигатели от различных производителей могут работать в одной и той же сети CANopen

Ознакомиться с документацией CANopen Motor API вы можете по ссылке.

Аппаратные средства, которые поддерживаются API:

За более подробной информацией обращайтесь к специалистам IPC2U по телефону: +7 (495) 232 0207 или по e-mail: [email protected]

CAN в автоматизации (CiA): CANopen

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

Здесь вы можете найти историю CANopen.

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

«Подключи и работай» с CANopen

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

Коротко о CANopen

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

Нижние слои CANopen

CANopen основан на уровне канала передачи данных в соответствии с ISO 11898-1. Битовая синхронизация CANopen указана в CiA 301 и позволяет регулировать скорость передачи данных от 10 кбит / с до 1000 кбит / с. Хотя все указанные схемы адресации CAN-ID основаны на 11-битном CAN-ID, CANopen также поддерживает 29-битный CAN-ID.CANopen предполагает наличие физического уровня в соответствии с ISO 11898-2. Тем не менее, CANopen не исключает других возможностей физического уровня.

Более подробная информация о нижних уровнях CANopen доступна здесь.

Внутренняя архитектура устройства

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

Объектный словарь CANopen наиболее важен для настройки и диагностики устройства CANopen. В качестве внутренней ссылки устройства используется 16-разрядный индекс, который задается как 4-значное шестнадцатеричное значение. Диапазон индексов от 1000 _h до 1FFF _h предоставляет ссылки на все параметры, которые определяют поведение связи CANopen устройства CANopen.Диапазон индексов от 2000 _h до 9FFF _h предоставляет ссылки на все параметры, связанные с приложением. CANopen различает собственные параметры (диапазон индекса от 2000 _h до 5FFF _h ) и стандартизованные параметры (диапазон индекса от 6000 _h до 9FFF _h ).

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

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

Протоколы CANopen включают:

Объяснение CANopen – простое введение (2020)

Требуется простое и практичное введение в CANopen?

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

Примечание: CANopen может показаться сложным – так что это руководство представляет собой визуальное введение в терминах непрофессионала.

Прочтите ниже, чтобы полностью понять CANopen.

Вы также можете посмотреть наше вступительное видео о CANopen выше.

Что такое CANopen?

CANopen – это протокол связи на основе CAN.

Стандарт CANopen полезен, поскольку он обеспечивает готовую функциональную совместимость между устройствами (узлами), например, в промышленное оборудование. Кроме того, он предоставляет стандартные методы для настройка устройств – также после установки.

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

Сегодня CANopen широко используется в управлении двигателями (шаговые / серводвигатели), но также и в широком спектр других приложений:

Робототехника

Автоматизированная робототехника, конвейерные ленты и другое промышленное оборудование

Медицинский

Генераторы рентгеновского излучения, инжекторы, столы для пациентов и диализные устройства

Автомобильная промышленность

Сельское хозяйство, железная дорога, трейлеры, тяжелые, морские и др.

CANopen – протокол более высокого уровня

Важно понимать следующее:

CANopen – это «протокол более высокого уровня», основанный на шине CAN.

Это означает, что шина CAN (ISO 11898) служит «транспортным средством» (например, грузовиком) для сообщений CANopen (например, контейнеров).

CANopen можно просматривать из 7-уровневой модели OSI, см. Ниже.

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

представляет два нижних уровня (1: физический, 2: канал передачи данных). Это означает, что CAN просто разрешает передачу кадров с 11-битным CAN ID , удаленным бит передачи (RTR) и 64 бита данных (поля, относящиеся к протоколам более высокого уровня).

Другими словами, шина CAN играет в CANopen ту же роль, что и, например, в протокол J1939.

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

Стоит отметить, что CANopen также может быть адаптирован к другим протоколам канального уровня, отличным от CAN (например, EtherCAT, Modbus, Powerlink).

Шесть основных концепций CANopen

Даже если вы знакомы с CAN-шиной и, например, J1939, CANopen добавляет ряд важных новых концепций:

Коммуникационные модели

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

Протоколы связи

Протоколы используются для связи, например.грамм. настройка узлов (SDO) или передача данных в реальном времени (PDO)

Устройство
Состояния

Устройство поддерживает разные состояния. «Главный» узел может изменять состояние «подчиненного» узла – например, сбросить его

Словарь объектов

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

Электронный лист данных

EDS – это стандартный формат файла для записей OD, позволяющий e.грамм. сервисные инструменты для обновления устройств

Профили устройств

описывают, например, Модули ввода / вывода (CiA 401) и управление движением (CiA 402) для независимости от поставщика

На иллюстрации ниже показано, как концепции CANopen связаны друг с другом, и мы подробно рассмотрим каждую из них:

Основы связи CANopen

В сети CANopen несколько устройств должны обмениваться данными.

Например, в системе промышленной автоматизации у вас может быть рука робота с несколькими узлами серводвигателей и интерфейсом управления / узлом ПК.

Для облегчения связи существует три модели внутри CANopen, каждая из которых тесно связана с протоколами CANopen, которые мы вскоре рассмотрим. См. Ниже краткое введение:

Главный / Подчиненный

Один узел (например, интерфейс управления) действует как мастер приложения или хост-контроллер. Он отправляет / запрашивает данные от ведомых устройств (например, серводвигателей). Это используется, например, в диагностика или управление состоянием.В стандартных приложениях может быть от 0 до 127 ведомых устройств. Обратите внимание, что в одной сети CANopen могут использоваться разные хост-контроллеры. тот же уровень канала передачи данных.

Пример обслуживания: NMT

Клиент / Сервер

Клиент отправляет запрос данных на сервер, который отвечает запрошенными данными. Используется, например, когда ведущему приложению нужны данные от OD ведомого. Чтение из сервер – это «загрузка», а запись – «загрузка» (в терминологии используется перспектива «на стороне сервера»).

Пример обслуживания: SDO

Потребитель / Производитель

Здесь узел-производитель передает данные в сеть, которые потребляются узлом-потребителем. Производитель либо отправляет эти данные по запросу (модель pull), либо без конкретный запрос (модель push).

Пример обслуживания: Heartbeat

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

Рама CANopen

Чтобы понять связь CANopen, необходимо разбить CANopen CAN-фрейм :

11-битный CAN ID называется идентификатором объекта связи ( COB-ID ) и делится на две части:
По умолчанию первые 4 бита равны код функции и следующие 7 битов содержат идентификатор узла .

Чтобы понять, как работает COB-ID, давайте начнем с предопределенного распределения идентификаторов, используемых в простых сетях CANopen (см. Таблицу).

Примечание. Ниже мы будем ссылаться на идентификаторы COB-ID и идентификаторы узлов в HEX.

Как видно, COB-ID (например, 381, 581,…) связаны со службами связи (передача PDO 3, передача SDO,…).

Таким образом, COB-ID указывает, какой узел отправляет / принимает данные и какая служба используется .

Устройство CANopen с идентификатором узла 5 будет передавать SDO через 11-битный идентификатор CAN 585 .

Это соответствует двоичному коду функции 1011 и идентификатору узла 5 (двоичный: 0000101) – см. Иллюстрацию:

Онлайн-конвертер CANopen COB-ID

Наш конвертер COB-ID позволяет быстро найти CANopen COB-ID, чтобы получить основные сведения, включаякод функции и идентификатор узла.

Протоколы / услуги связи CANopen

Ниже мы кратко опишем 7 упомянутых типов услуг, в т.ч. как они используют 8 байтов CAN кадра .

Что это такое? Служба NMT используется для управления состоянием устройств CANopen (например, предварительная эксплуатация, работа, остановка) с помощью NMT. команды (например, пуск, останов, сброс).

Как это работает? Чтобы изменить состояние, мастер NMT отправляет 2-байтовое сообщение с CAN ID 0 (т.е.е. код функции 0 и идентификатор узла 0). Все подчиненные узлы обрабатывают это сообщение. 1-й байт данных CAN содержит запрошенное состояние, а 2-й байт данных CAN содержит идентификатор целевого узла. Идентификатор узла 0 указывает на широковещательная команда.

Возможные команды включают переход в рабочий (состояние 01), в остановленный (состояние 02), предрабочий (состояние 80), а также приложение сброса (81) и сброс связь (82).

Что это? Используется сообщение SYNC e.грамм. для синхронизации обнаружения входов и срабатывания нескольких устройств CANopen – обычно запускается мастер приложения.

Как это работает? Мастер приложения отправляет сообщение SYNC (COB ID 080) в сеть CANopen (со счетчиком SYNC или без него). Множественный раб узлы могут быть настроены так, чтобы реагировать на SYNC и отвечать, передавая входные данные, захваченные в одно и то же время, или устанавливая выход в то же время, что и узлы, участвующие в синхронной операции.С помощью счетчика SYNC можно настроить несколько групп синхронно работающих устройств.

Что это? Служба экстренной помощи используется в случае, если в устройстве произошла фатальная ошибка (например, отказ датчика), что позволяет сообщить об этом остальная часть сети.

Как это работает? Затронутый узел отправляет одно сообщение EMCY (например, с COB-ID 085 для узла 5) в сеть с высоким приоритетом.Байты данных содержат информация об ошибке, в которой можно найти подробности.

Что это? С помощью этой услуги связи можно распределить глобальное сетевое время. Сервис TIME содержит 6-байтовую информацию о дате и времени.

Как это работает? Мастер приложения отправляет сообщение TIME с CAN ID 100, где начальные 4 байта данных содержат время в мс после полночь и следующие 2 байта содержат количество дней с 1 января 1984 года.

Что это? Служба PDO используется для передачи данных в реальном времени между устройствами – например, измеренные данные, такие как положение или командные данные, такие как крутящий момент Запросы. В этом отношении он похож, например, на передаваемые параметры данных в J1939.

Как это работает? Мы подробно рассмотрим это ниже.

Что это? Службы SDO используются для доступа / изменения значений в объектном словаре устройства CANopen – e.грамм. когда мастеру приложения нужно изменить определенные конфигурации устройства CANopen.

Как это работает? Мы подробно рассмотрим это ниже.

Что это? Служба Heartbeat имеет две цели: предоставить «живое» сообщение и подтвердить команду NMT.

Как это работает? Подчиненное устройство NMT периодически отправляет (например,каждые 100 мс) сообщение Heartbeat (например, с CAN ID 705 для узла 5) с «Состояние» в 1-м байте данных

«Потребитель» сообщения Heartbeat (например, главное устройство NMT и, возможно, любое другое устройство) затем реагирует, если сообщение не получено в течение определенного периода времени.

Услуги PDO и SDO особенно важны, поскольку они составляют основу для большинства коммуникаций CANopen.

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

Словарь объектов CANopen

Все узлы CANopen должны иметь словарь объектов (OD) – но что это такое?

Словарь объектов – это стандартизированная структура, содержащая все параметры, описывающие поведение узла CANopen.

записей OD ищутся через 16-битный индекс и 8-битный субиндекс. Например, индекс 1008 (субиндекс 0) CANopen-совместимого узла OD содержит устройство узла . название .

В частности, запись в словаре объектов определяется атрибутами:

• Индекс: 16-битный базовый адрес объекта
• Название объекта: Название устройства производителя
• Код объекта: Массив, переменная или запись
• Тип данных: Например, VISIBLE_STRING, или UNSIGNED32, или имя записи
• Доступ: rw (чтение / запись), ro (только чтение), wo (только запись)
• Категория: Указывает, является ли этот параметр обязательным / необязательным (M / O)

НД стандартизованные секции

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

Важно отметить, что записи OD устройства (например, ведомого) могут быть доступны другому устройству (например, ведущему) через CAN, например, ОРС.

Например, это может позволить главному устройству приложения изменять, регистрирует ли подчиненный узел данные через определенный входной датчик – или как часто подчиненный узел отправляет контрольный сигнал.

Ссылка на электронную таблицу данных и файл конфигурации устройства

Чтобы понять OD, полезно взглянуть на «удобочитаемую форму»: электронную таблицу данных и файл конфигурации устройства.

Электронный лист данных (EDS)

На практике настройка / управление сложными сетями CANopen будет выполняться с использованием соответствующих программных инструментов.

Чтобы упростить это, стандарт CiA 306 определяет удобочитаемый (и удобный для машины) формат файла INI, действующий как «шаблон» для OD устройства – например, «ServoMotor3000». Этот EDS обычно предоставляется поставщиком и содержит информацию обо всех объектах устройства (но не значениях).

Файл конфигурации устройства (DCF)

Предположим, фабрика купила ServoMotor3000 для интеграции в конвейерную ленту. При этом оператор редактирует ЭЦП устройства и добавляет специфический параметр. значения и / или изменяет названия каждого объекта, описанного в EDS.

При этом оператор эффективно создает так называемый файл конфигурации устройства (DCF). После этого ServoMotor3000 готов к интеграции в конкретная сеть CANopen на месте.

Просмотр реальных примеров EDS / DCF – один из лучших способов действительно понять объектный словарь CANopen – см., Например, разница между EDS и DCF запись объекта ниже. Мы рекомендуем ознакомиться со стандартом CiA 306, чтобы получить более глубокое понимание OD, EDS и DCF с практическими примерами.

Как уже упоминалось, DCF обычно создается при интеграции устройства. Однако часто бывает необходимо прочитать и / или изменить значения объекта узла после первоначального конфигурация – здесь в игру вступает служба SDO.

SDO – настройка сети CANopen

Что такое SDO-сервис?

Служба SDO позволяет узлу CANopen читать / редактировать значения словаря объектов другого узла по сети CAN.

Как упоминалось в разделе «Модели связи», службы SDO используют поведение «клиент / сервер».

В частности, «клиент» SDO инициирует связь с одним выделенным «сервером» SDO.

Целью может быть обновление записи OD (так называемая «загрузка SDO») или чтение записи («загрузка SDO»).

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

Пример: загрузка SDO клиентского узла

Клиентский узел может инициировать загрузку SDO на узел 5 путем широковещательной передачи ниже кадра CAN, который запускает узел 5 (и игнорируется другими узлами, см. Иллюстрацию выше). SDO “получить” (т.е. запрос) CAN кадр выглядит следующим образом:

• Во-первых, COB-ID 605 отражает использование «приема SDO» (COB-ID 600 + идентификатор узла).
• CCS (спецификатор команды клиента) – это тип передачи (например, 1: Загрузить, 2: Загрузить)
• n – это # ​​байтов в байтах данных 4-7, которые не содержат данных (действительно, если установлены e & s)
• Если установлено, e указывает на «ускоренную передачу» (все данные находятся в одном кадре CAN)
• Если установлено, s указывает, что размер данных показан в n
• Индекс (16 бит) и субиндекс (8 бит) отражают адрес OD, к которому будет осуществляться доступ
• Наконец, байты 4-7 содержат данные для загрузки на узел 5

После того, как главный (клиент) отправляет кадр CAN, подчиненный узел 5 (сервер) отвечает посредством «передачи SDO» с COB-ID 585.Ответ содержит индекс / субиндекс и 4 пустых байты данных. Естественно, если клиентский узел запросил загрузку вместо (т.е. чтение данных из OD узла 5), узел 5 ответил бы соответствующими данными, содержащимися в байты 4-7.

Несколько комментариев:

• Как видно, каждый SDO использует 2 идентификатора, создавая «канал SDO».
• Пример упрощен как «ускоренный» (данные содержатся в 4 байтах)
• Для сценариев с большими данными может использоваться сегментация SDO / блочная передача

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

PDO – работа в сети CANopen

Прежде всего: что такое служба CANopen PDO?

Служба PDO используется для эффективного обмена оперативными данными в реальном времени между узлами CANopen.

Например, PDO будет нести данные давления с датчика давления или данные температуры с датчика температуры.

Но подождите: служба SDO не может просто сделать это?

Да, в принципе для этого можно использовать службу SDO.Однако один ответ SDO может нести только 4 байта данных из-за служебных данных (байт команды и адреса OD). Дальше, скажем, главному узлу нужны два значения параметра (например, “SensTemp2” и “Torque5”) от узла 5 – чтобы получить их через SDO, потребуется 4 полных CAN-кадра (2 запроса, 2 ответы).

Напротив, сообщение PDO может содержать 8 полных байтов данных – и может содержать несколько значений параметров объекта в одном кадре. Таким образом, для чего потребуется не менее 4 кадры с SDO потенциально могут быть выполнены с помощью 1 кадра в службе PDO.

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

Для PDO используется терминология потребителя / производителя. Таким образом, производитель «производит данные», которые он передает «потребителю» (мастеру) с использованием передаваемого PDO (TPDO). И наоборот, это может получать данные от потребителя через принимающий PDO (RPDO).

Узлы-производители могут, например, быть настроенным для ответа на триггер SYNC, передаваемый потребителем каждые 100 мс.Узел 5 может, например, трансляция ниже передает PDO с COB-ID 185:

Обратите внимание, как байты данных упакованы с 3 значениями параметров. Эти значения отражают данные в реальном времени конкретных записей OD узла 5. Узлы, которые используют эту информацию ( потребители) конечно должны знать, как интерпретировать байты данных PDO.

Разве служба PDO немного похожа на PGN и SPN J1939?

Да, в некоторой степени это похоже на то, как конкретная группа параметров J1939 (PG) будет содержать несколько SPN / сигналов (также называемых параметрами данных) в 8 байтах данных.Фрейму J1939 CAN не нужно тратить байты данных на «декодирование» информации, потому что это известно соответствующими узлами (и внешними инструментами, например, через файлы J1939 DBC или стандарты PDF J1939). Проблема в том, что в CANopen эти «сопоставления PDO» часто настраивается и может быть изменен во время создания DCF и / или через службу SDO.

Подробнее о PDO см. В этой статье (стр. 5).

Регистрация данных CANopen – примеры использования

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

Например, CANedge позволяет записывать данные CANopen на SD-карту емкостью 8–32 ГБ. Просто подключите его к своему приложению, чтобы начать регистрацию – и обрабатывать данные с помощью бесплатного программного обеспечения / API.

, такие как CANedge, позволяют использовать несколько сценариев использования протоколирования CANopen:

Регистрация данных узла CANopen

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

Управление складским парком

CANopen часто используется в вилочных погрузчиках EV / AGV на складах, где мониторинг, например, SoC помогает уменьшить поломки и продлить срок службы батареи

Профилактическое обслуживание

Промышленное оборудование можно контролировать с помощью логгеров IoT CAN в облаке для прогнозирования и предотвращения поломок на основе данных CANopen

Черный ящик для диагностики машин

Регистратор CAN может служить «черным ящиком» для промышленного оборудования, предоставляя данные для e.грамм. диагностика споров или редких проблем

Необходимо регистрировать / передавать данные CANopen?

Получите свой CAN-логгер сегодня!

Рекомендовано для вас

GitHub – CANopenNode / CANopenNode: стек протоколов CANopen

• Почему именно GitHub? Особенности →
  • Обзор кода
  • Управление проектами
  • Интеграции
  • Действия
  • Пакеты
  • Безопасность
  • Управление командой
  • Хостинг
  • мобильный
  • Истории клиентов →
  • Безопасность →
• команда
• предприятие
• Проводить исследования
  • Изучите GitHub →

  Учитесь и вносите свой вклад

  • Темы
  • Коллекции
  • В тренде
  • Учебная лаборатория
  • Руководства с открытым исходным кодом

  Общайтесь с другими

  • События
  • Форум сообщества

CAN в автоматизации (CiA): протоколы специальных функций

CANopen предлагает три специальных протокола для создания особого сетевого поведения:

• Протокол SYNC обеспечивает синхронное сетевое поведение.
• Протокол отметок времени используется для настройки уникального сетевого времени.
• Экстренный протокол может использоваться для информирования других участников сети о внутренних ошибках устройства.

Протокол синхронизации (SNYC)

Протокол SYNC периодически передается производителем SYNC.Период времени между двумя последовательными сообщениями SYNC – это период цикла связи. Сообщение SYNC отображается в один кадр CAN с идентификатором 80 _h в соответствии с заранее определенным набором соединений. По умолчанию сообщение SYNC не содержит никаких данных (DLC = 0). Устройства, поддерживающие CiA 301 версии 4.1 или выше, могут дополнительно предлагать сообщение SYNC, которое предоставляет 1-байтовое значение счетчика SYNC. Поэтому синхронное поведение нескольких устройств можно более комфортно согласовать.

Аварийный протокол

Экстренные сообщения вызываются внутренней ошибкой устройства. Сообщение Emergency, передаваемое производителем Emergency, отображается в один кадр CAN, который охватывает до восьми байтов данных. Содержимое данных определяется как 1-байтовый регистр ошибок (индекс 1001 _h локального объектного словаря), 16-битный код аварийной ошибки и до 5 байтов информации об ошибках производителя. По умолчанию устройство, которое поддерживает функцию аварийного производителя, назначает CAN-идентификатор 80 _h + (идентификатор узла) аварийному сообщению.Экстренное сообщение передается только один раз за событие ошибки. Пока на устройстве не возникает новых ошибок, дальнейшие сообщения о чрезвычайных ситуациях не передаются. Эти сообщения могут получать ноль или более потребителей Чрезвычайных ситуаций и могут инициировать соответствующие меры противодействия для конкретного приложения.

Протокол отметок времени

Протокол отметок времени позволяет пользователю систем CANopen настраивать уникальное сетевое время. Отметка времени отображается в один единственный кадр CAN с кодом длины данных 6 байт.Эти шесть байтов данных содержат информацию «Время суток». Эта информация дается в миллисекундах после полуночи (Datatype: Unsigned28) и в днях, прошедших с 1 января 1984 г. (Datatype: Unsigned16). Соответствующий CAN-кадр по умолчанию имеет CAN-идентификатор 100 _h .