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

Будет ли интерфейсная карта CAN, скорее всего, установлена как порт COM? Как я могу разбить сообщение, которое будет отправлено в качестве отдельных периодах? Как насчет сборки данных из нескольких…

Фон Я должен создать программу Java на ноутбуке, чтобы получать / отправлять сообщения CANopen. RJ45 выбран в качестве физической среды сети. Я новичок в программировании коммуникаций CANopen и…

У нас есть проект робота, где контроллеры двигателей используют CANopen для связи. Мне нужно связаться с этими контроллерами двигателей с помощью master microcontroller. Проблема в том, что мне…

Я ищу фреймворк CAN-Bus, который может генерировать мне полный формат фрейма, предоставляя ему мои данные. Мне это нужно для приложения android. Соединение с CAN-шиной и все обнаружение столкновений…

Я пытаюсь вытащить VGM CAN message из Reachstacker 42-45 tonnes где я использую arduino MEGA 2560 с CAN-BUS shield это мой текущий код: #include <SPI.h> #include mcp_can.h // the cs pin of the…

Я пытаюсь подключить ICP CON i-7565 (USB<->CAN интерфейс) к изготовленному на заказ устройству (поддерживающему CAN2. 0B, доказавшему работу с картой PCL-841) Хотя я думаю, что правильно настроил…

Я хочу изучить и внедрить протокол CAN BUS. Я реализовал протокол UART,SPI,I2C и One Wire Bus с использованием панели запуска MSP430 в программном обеспечении. Теперь я хочу узнать о протоколе CAN…

Я хотел бы получить совет по поводу связи шины CAN с планшетом Android. Я работаю над проектом электромобиля вместе с коллегой. У нас есть шина CAN связи между BMS, инвертором и логикой управления….

Здравствуйте, я студент учусь протокола CANopen. Какова связь между COB-ID и идентификатором CAN в Canopen? Я читал на домашней странице CIA, что COB-ID-это не CAN ID, но я этого не понимаю….

Мне нужно установить протокол HMI на основе CAN, который обеспечивает одновременную связь прикладного устройства с устройством HMI? Ограничение заключается в том, что CAN может быть реализован как. ..

CANopen это просто (реализация обмена по протоколу CANopen в контроллерах, сервоприводах и преобразователях частоты Delta Electronics)

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

Рассмотрим следующий по доступности и востребованности протокол – CAN, точнее его реализацию CANopen (кстати DeviceNet – это тоже реализация CAN, а еще профиль устройства CANopen может быть реализован поверх другого транспортного протокола, например EtherCAT, что собственно и можно увидеть на сервоприводах Delta Electronics).  

Первое беглое представление о стандарте CANopen можно (а возможно даже нужно) получить в Википедии или ином источнике, где можно посмотреть какие-то общие моменты, здесь я это описывать не стану, но постараюсь расставить акценты.  Если оставить временно в стороне вопросы общего характера, такие как количество узлов сети, уникальность номеров, описание самого физического уровня со всеми принципами доминантности, правила формирования COBID итд итп тк многое уже реализовано на уровне программного обеспечения, с практической точки зрения нас должны интересовать следующие: CANopen разработан как надстройка, работающий поверх физического протокола CAN (Controller Area Network), то есть для организации сети не забываем про терминальный резистор 120 Ом, документ The CANopen Application Layer and Communication Profile (CiA Draft Standard 301 или просто DS 301) представляет собой основной документ, в котором описаны основные положения и принципы работы CANopen, соответственно DS 301 выбирается в качестве настройки связи, если конечно это не обеспечено Special driver или еще каким-либо образом. Для специализированных применений имеются CiA 401 для модулей ввода-вывода и CiA DS 402 для управления движением (сервоприводы и преобразователи частоты). Именно эти документы, точнее их интерпретации под используемое оборудование необходимо использовать для настройки связи. Для ASDA-A2 это “CANopen technical guide for ASDA-A2_eng.pdf”.

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

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

1. сообщения управления сетью, например Layer Management (LMT) и Network Management (NMT) сообщения
2. Service Data Objects (SDO) механизм обычно используется для конфигурирования устройств, достоинство это то, что имеется возможность контролировать соединение и ответ устройства. Недостатки – более низкий приоритет по сравнению с PDO и невозможность организации синхронной передачи данных.
3. Process Data Objects (PDO) механизм используется для передачи с высокой скоростью высокоприоритетных данных, так как PDO сообщения не содержат никаких дополнительных протокольных данных. Обычно используется для заранее сконфигурированного регулярного обмена информацией. При этом используется инструмент так называемый Маппинг (Mapping), при котором происходит отображение сетевого обмена на встроенные регистры ПЛК.
4. Предопределенные сообщения (Sync Object, Time Stamp Object, Emergency Object)

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

Основной функциональной единицей протокола является объект. Под объектом может пониматься любой набор данных, например, текущая скорость или задание положения сервопривода. Поэтому для устройства (узла) необходимым условием работы в сети является наличие словаря (OD), описывающего связь между объектом и его индексом/субиндексом. С каждым устройством, использующим интерфейс CANopen, производитель должен предоставить файл с расширением *. eds (Electronic DataSheet), содержащий словарь объектов и дополнительную информацию. Опять же если брать дельту – то это файл “CANopen technical guide for ASDA-A2_eng.pdf” либо программное обеспечение CANopen Builder, например, “CANopen_Builder-V5.00_SW_20141128.zip-V5.00_SW_20141128.zip”.

Давайте перейдем к практике: откроем простой проект для ПЛК AS228T-A и для начала воспользуемся документацией “AS_OM_EN_20200707.pdf”. В разделе “Chapter 10 CANopen Function and Operation” мы найдем “The Input/Output Mapping Areas”, где будет указано, что регистры D25000–D25031 используются составления пакета отправки SDO (а также NMT), а D24000–D24031 для получения ответа и анализа. Следующие же за ними D25032–D25978 и D24032–D24978 для маппинга отправляемых запросов RxPDO и получаемых в ответ TxPDO, конфигурация распределения которых настраивается в CANopen Builder. В проекте ПЛК дважды щелкнем левой кнопкой на HWCONFIG в дереве проекта. В появившемся окне левой кнопкой щелкнем на Built-in CAN communication. В случае выбора другого ПЛК, например, AS332T-A, нужно доустановить плату AS-FCOPM во второй (нижний слот) и щелкнуть по Function Card 2 Settings.

При этом выбрать для CAN working mode – CANopen DS301, выставить необходимую скорость, проверить что на всех устройствах стоит именно эта скорость, а адрес node ID не совпадает с адресами узлов сети. Если используются встроенные функциональные блоки INITC, CASD, ASDON, COPRW, DDRVAC, то выбирается Delta Special driver & AS Remote Mode, а адрес платы выставить равным 18, но это совсем другой режим и совсем другая история.

Для дальнейшего конфигурирования вызывается CANopen Builder из контекстного меню как Communication software->CANopen Builder. В программе добавляются необходимые узлы перетаскиванием Device List, при необходимости туда могут быть импортированы сторонние устройства посредством импорта их EDS-файлов. Дважды щелкнув левой клавишей по узлу (в нашем случае это сервопривод) открываем конфигурацию.

Если кого-то напугает обилие индексов, не обращайте внимания, наши индексы – это индексы словаря устройства, приведённые здесь индексы – это коммуникационные индексы, относятся к коммуникационным объектам, нас они волновать не должны.

В нижней части приведена простейшая настройка (да ничего не делая там уже есть). Дважды щелкнув по строке с Description RxPDO1 мы увидим:

А это стандартный объект всех устройств, поддерживающих CANopen DS402 – слово управления. Не забывая про то, что PDO поддерживает отправку всего 8 байт информации можем добавить объекты из верхней части Aviable Objects нажимая стрелку “вниз” и убрать стрелкой “вверх”, если объем отправляемых данных превысит 8 байт, программа не добавить объект и выведет предупреждающее сообщение. Если все равно нужно добавить еще один объект, то нужно нажав ОК в текущем PDO Mapping, дважды щелкнуть левой кнопкой в окне Node Configuration на следующий по порядку Recive PDO Communication Parameter (в нашем случае с индексом 1401). Здесь можно добавить параметры, изменяемые нами в процессе управления сервоприводом, например Target position:607Ah или Profile velocity:6081h. Аналогичные действия доступны и с Transmit PDO Communication Parameter, где приведен по умолчанию Statusword или слово состояния и можно поместить например параметры для мониторинга (Position actual value:6064h, Velocity actual value:606Ch). Если нажать на кнопку Properties на выбранном в нижнем поле PDO можно увидеть и поменять при необходимости Transmitiom Type, который по умолчанию стоит асинхронный 255.

Завершает настройку следующая процедура: дважды щелкаем на ПЛК, выбираем в левом верхнем поле Aviable Nodes наш сервопривод и дважды щелкаем по нему левой кнопкой мыши (можно нажать на кнопку-стрелку “направо”) так, чтобы он попал в правое верхнее поле Node List, а в нижнем поле регистрам ПЛК будут присвоены наши данные, это и есть Mapping. сохраняем настройку и заливаем ее в ПЛК.

Но не все же нам PDO работать, мы можем конфигурировать и с помощью SDO, что в принципе нам и потребуется.

Давайте попробуем настроить работу ПЛК в Profile Position Mode или другими словами заставим сервопривод двигаться в режиме контура положения, осуществить трапецеидальный профиль движения (другие варианты могут быть, но на ASDA-A2 объявлен только этот профиль). Для этого нам необходимо сконфигурировать следующую последовательность:

1. определить режим (Setting [Mode of operations:6060h] to profile position mode=1),
2. выставить коэффициенты электронного редуктора, ведь те, что введены в сервопривод не действуют в режиме CANopen (Setting [Position factor:6093h] Position factor =Numerator / Feed_constant),
3. выставить ускорения и замедления (Setting [Profile acceleration:6083h] to plan acceleration slope, Setting [Profile deceleration:6084h] to plan deceleration slope),
4. выставить окно Position window (Setting [Position window:6067h] to 0).

Для этого изучим раздел “AS_OM_EN_20200707.pdf” 10.4 Sending SDO, NMT and Reading Emergency Message through the Ladder Diagram

Что стоит здесь прокомментировать, так это заполнение поля ReqID – при смене отправляемого SDO необходимо менять это поле, например инкрементируя его. Это необходимо для отслеживания протоколом, тк если поле не изменится, то обмена не произойдет. Поле Size определяется типом объекта, точнее его длинной, обычно это указано в словаре. Type: 01 для операции чтения; 02 для операции записи. Node ID – адрес узла, которому предназначен для отправки SDO.

Обычно перед отправкой SDO идут команды очистки буферов ZRST D24000 D24031, ZRST D25000 D25031.

Для приема и обработки служит следующий буфер:

Status code я приводить не буду, но любой вариант отличный от 1 должен заставить задуматься о достоверности полученных данных.

Ниже приведен пример отправки настройки режима работы сервопривода – режим PPM Position profile mode (Setting [Mode of operations:6060h]:8bit to profile position mode=1). В случае отправки 16 битных данных поле Size заполняется значением 6, а в случае 32 битных – 8.

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

Само слово управления описано в “CANopen technical guide for ASDA-A2_eng.pdf” по индексу 6040h и стоит прокомментировать это следующим образом: если мы хотим запустить привод, точнее выставить сигнал Servo On или для отправки на “обнуление”, выставляем биты 0,1,2,3, если снять Servo On – сбрасываем биты 0,1,2,3. Для подтверждения задания положения/скорости для PPM Mode выставляем бит 4 в единичку. Дополнительные биты 5 и 6 для PPM служат для настройки системы получения нового задания, бит 5 позволяет получать задание “на лету”, то есть не дожидаясь выхода сервопривода в предыдущее полученное задание, другими словами без остановки. В паре с 6-ым битом можно в абсолютной системе координат менять скорость (бит 6 сброшен для абсолютной) не меняя координаты, а можно и координату менять. Если необходима пауза – выставляется бит 8 Halt, при этом старое задание сохраняется и при подаче нового в относительных координатах (бит 6 выставлен для относительной) добавляется. Остановка осуществляется сбросом бита 2 Quick Stop, но стоит учесть, что для него существует свое время замедления. Сброс ошибки осуществляется выставлением 7 бита. Важно сбрасывать биты 4, 7, 8, после выполнения команды, тк повторное выполнение команды возможно по фронту.

 Слово состояние тоже описано в “CANopen technical guide for ASDA-A2_eng.pdf” по индексу 6041h, и думаю в особых комментариях не нуждается.

Контроллеры CANopen – Продукция Hilscher

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

В сетях CAN используется шинная топология, так что каждое устройство сети «слышит» все остальные. Протокол CANopen использует синхронный алгоритм доступа CSMA/CA и обеспечивает скорость передачи данных от 10 Кбит/с до 1 Мбит/с. Структура сети позволяет объединять до 127 устройств с общей длиной линии до 5 км. Четыре  различных механизма передачи данных позволяют пересылать пакеты данных  циклически, по запросу и по событию.  Первый из них, SDO (Service Data Object), используется для пересылки нограниченного количества данных с низким приоритетом и различной служебной информации. Второй, PDO (Process Data Object), позволяет быстро передавать до 8 байт данных с высоким приоритетом. Ещё 2 механизма осуществляют контроль за передачей данных, выявление ошибок, опрос оборудования на предмет сбоев.

Протокол CANopen в настоящее время поддерживается  организацией CiA.

Параметры интерфейсной платы:

Комплект поставки:

• Интерфейсная плата
• DRV-TKIT – Библиотека функций языка «C»  
• DRV-COM – COM -кабель
• DRV-WIN – Драйвер Windows
• DRV-LNX  – Драйвер Linux
• CD-SYS – Документация на CD
• Базовая версия конфигуратора SyCon (на 2 устройства)

Опционально:

• SYCON-CO – Конфигуратор SyCon для шины CANopen на 3 и более устройства
• DRV-CE – Драйвер Windows CE
• SRV-OPC –  ОРС-сервер для работы со SCADA-системами
• Драйвер для QNX 4. 25, 6.2, 6.3
• CAB-SRV – кабель для диагностики

Инновационные приводы с поддержкой популярных коммуникационных протоколов

Эффективность функционирования современной промышленной техники в значительной степени зависит от того, насколько быстро она реагирует на сигналы компонентов и данные, получаемые из различных источников. Будь то CAN J1939, IO-Link или другой протокол, использование приводов со встроенным контроллером LINAK^® IC  обеспечит быструю и относительно простую интеграцию функции перемещения.

Ниже приведены короткое описание коммуникационных протоколов и вспомогательная литература (руководства пользователя, указания по установке и т.п.).

IO-Link – это промышленный сетевой стандарт сквозной передачи данных, используемый для подключения цифровых датчиков и приводов к полевой шине или сети Ethernet. Для реализации этого протокола требуется простой трёхпроводной кабель без дополнительного экранирования. Двусторонняя связь обеспечивает быструю установку параметров и диагностику, повышая таким образом эффективность и готовность к работе средств промышленной автоматизации, упаковочного и другого оборудования.
Краткое руководство

Шина коммутируемой локальной сети (LIN) является экономичным дополнением шины CAN. Общая эффективность и надёжность сети в этом случае ниже по сравнению с шиной CAN, однако данный протокол отлично поддерживает менее важные функции (например, регулировку положения кресла или окон в каюте).

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

Вспомогательная литература о протоколе Modbus

Перечень параметров и разъяснения

Скачать бесплатное ПО BusLink v1. 20 для конфигурирования приводов и считывания сервисной информации. Основные функции объяснены здесь. Для каждого коммуникационного протокола предлагаются руководства и средства расширения функциональности.

CAN in Automation (CiA): Introduction Russian

Внимание – на данный момент вы находитесь на вебсайте CiA на русском языке.

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

Об организации CiA

CiA – международное сообщество производителей и пользователей сети контроллеров CAN (Controller Area Network) и связанных с этим технологий. Физический и канальный уровни CAN определены в серии международных стандартов ISO 11898. Сообщество было образовано в 1992 году. Цель организации заключается в предоставлении независимой платформы для будущего развития CAN технологии и в продвижении CAN имиджа. В начале 2020 года 670 компаний были членами CiA. Более подробную информацию вы найдете здесь.

CiA объединяет не только устройства

CiA поддерживает развитие и принимает участие в разработке спецификаций и стандартов, основанных на технологиях CAN. Одна из важнейших целей работы организации направлена на разработку протоколов высокого уровня CANopen и CANopen FD и основанных на них профилях устройств и приложений.

CiA организовывает международные маркетинговые мероприятия для распространения информации о CAN и его протоколах высокого уровня. Для этого CiA принимает участие в выставках, проводит CiA technology days, а также ежегодно устраивает международную CAN конференцию iCC. Кроме того, CiA предлагает различные семинары и участвует в конференциях других организаций. Важным источником информации является вебсайт CiA. Дополнительно, CiA распространяет информацию через свои публикации, в социальных сетях и через рассылку информационной электронной почты (CAN Info Mail email service).

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

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

CAN охватывает разные отрасли промышленности

CAN широко используется во встроенных сетях управления. Все производители автомобилей используют сеть CAN для связи электронных блоков управления (electronic control units). CAN был, есть и будет ведущей системой для связи внутренних электронных сетей в различных видах транспорта. Первые автомобили уже задействуют CAN FD электронные блоки управления. В этом десятилетии, автостроители будут постепенно заменять классические CAN сети на CAN FD.

CiA в содействии со своими членами давно начали использование CAN в различных областях применения. В своей большей части сети CAN используются для соединения модулей ввода/вывода, датчиков, а также электрических и гидравлических приводов с главными контроллерами. Многие из таких систем управления используют интернационально стандартизированный прикладной уровень CANopen (EN 50325-4) и многократно проверенные на практике CANopen профили устройств и CANopen профили приложений. Особенно в приложениях с небольшим и средним числом используемых CAN узлов требуется применение стандартных протоколов высокого уровня и стандартных профилей. Разработчики систем могут выбирать подходящие CANopen устройства из продукции различных производителей и легко внедрять их в свои системы управления.

Мы определяем и стандартизируем

CiA разрабатывает спецификации и рекомендации для всех уровней эталонной модели взаимодействия открытых систем (Open Systems Interconnect (OSI) reference model). CiA всячески поддерживает интернациональную стандартизацию в ISO, IEC и других стандартизирующих организациях. При возможности, CiA передает свои спецификации стандартизирующей организации для более широкого распространения. Используя стандарты, разработчики устройств могут уделять большее внимание реализации функций самих устройств, нежели их коммуникационным особенностям. Это позволяет разработчикам систем использовать совместимые устройства различных производителей в одной системе.

Техническая горячая линия

Сотрудники CiA предлагают ответы на вопросы касающиеся CAN протоколов, физической реализации систем, а также помощь при толковании стандартов и спецификаций. Вы можете задать ваш вопрос по электронной почте (service(at)can-cia.org), или по телефону (+49-911-928819-0).

Семинары и прочие услуги обучения

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

Такие семинары рекомендуется посетить инженерам разработчикам и интеграторам систем. Обучение ведется на немецком или английском языке. Если потребуется, CiA может провести семинары на китайском или русском языке. Членские компании CiA могут предоставить наглядный материал для демонстрации изучаемых тем.

Семинары на специальные темы могут проводиться прямо на территории заинтересованных предприятий (in-house seminars). Содержание такого семинара определяется в зависимости от запросов клиента. Инженеры CiA могут обучать разработчиков устройств и систем, продавцов и заказчиков, а также технический персонал.

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

Вебинары и CiA technology days

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

Однодневное мероприятие CiA technology day предоставляет участникам свежую информацию о развитии актуальных проектов и будущих направлений развития CAN технологий. Они предназначены для инженеров и технических менеджеров и проводятся в различных местах по всему миру.

Плагфесты CiA и услуги по тестированию

CiA организовывает плагфесты (например для CANopen или CANopen Lift устройств). Они предназначены для разработчиков и интеграторов систем из членских компаний CiA. Целью данных мероприятий является проверка совместимости CANopen (или CANopen Lift) устройств и возможность помочь инженерам усовершенствовать программное обеспечение своих устройств. В добавок, инженеры получают более глубокое понимание проблем возникающих при реализации систем. Кроме того, результаты теста могут использоваться для улучшения CANopen спецификаций используемых при реализации устройств.

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

CiA центр тестирования предлагает проверку соответствия CANopen устройств. Здесь проводится тест CANopen устройств на соответствие спецификации CiA 301 (CANopen conformance test), а также тестирование взаимодействия данного устройства внутри CANopen системы.

Маркетинговая деятельность CiA

CiA предлагает своим членским компаниям принимать участие в различных маркетинговых мероприятиях, что позволяет им повысить известность своих брэндов. Члены CiA могут представлять свои продукты и услуги на выставочных стендах, в публикациях, а также в видеозаписях предлагаемых CiA. Кроме того, члены могут спонсировать мероприятия CiA, например проведение международной CAN конференции (iCC). Также компании могут представить свою продукцию на выставочных столах на так называемых tabletop exhibitions.

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

Публикации CiA

Журнал CAN Newsletter, выпускаемый с 1992 года – ведущее в мире издательство для инженеров разработчиков и пользователей CAN систем. Oн выпускается в формате PDF и может быть бесплатно скачан на вебсайте CiA. Журнал содержит статьи подробно описывающие различные технические новинки и приложения. Дополнительно, CAN Newsletter Online публикует короткие новости и более ориентируется на описание CAN продуктов.

Один раз в месяц CiA рассылает своим подписчикам CAN Info Mail (CIM) по электронной почте. CIM содержит обзор свежих новостей о CAN технологии и о предстоящих мероприятиях CiA. Также, один раз в месяц, CiA рассылает CAN Member News (CMN) предназначенные только для членов CiA и содержащие эксклюзивную информацию.

CiA онлайн каталог продуктов для CAN, CANopen и J1939 помогает пользователям найти устройства, инструментарий программного обеспечения и услуги разработчиков различных компаний.

Как работает CiA

Каждая членская компания имеет одно право голоса на главном ежегодном собрании CiA (CiA General Assembly) независимо от размера и количества сотрудников компании. На главном собрании избирается совет из трех директоров. Технический директор является председателем технического комитета CiA. Бизнес директор председательствует в CiA бизнес комитете. Руководящий директор CiA заведует работой CiA офиса.

На главном ежегодном собрании проводятся выборы технического комитета и бизнес комитета. Технический комитет утверждает и координирует CiA Interest Groups – группы, созданные по общим технологическим интересам нескольких компаний. Бизнес комитет разрабатывает основные маркетинговые стратегии и предлагает годовой бюджет рассматривающийся на главном ежегодном собрании.

Преимущества членства в CiA

Существует множество причин стать членом CiA. Следующий список преимуществ описывает большую часть из них:

Станьте членом сообщества, чтобы выгодно пользоваться услугами CiA.

Основы CANopen – NI

В следующем разделе объясняются основные концепции, относящиеся к прикладному уровню протокола CANopen. Этот документ предназначен только в качестве общего обзора, и пользователям рекомендуется ознакомиться со спецификацией CiA DS 301 для получения дополнительной информации.

Одна из центральных тем CANopen – это объектный словарь (OD), который, по сути, представляет собой таблицу, в которой хранятся данные конфигурации и процесса. Для всех устройств CANopen требуется реализовать словарь объектов.Стандарт CANopen определяет 16-битный индекс и 8-битный субиндекс. То есть в каждом индексе допускается иметь до 65536 индексов и до 256 подстатьей. Стандарт определяет, что определенные адреса и диапазоны адресов должны содержать определенные параметры. Например, стандарт определяет, что индекс 1008h, субиндекс 00h, должен содержать имя устройства. Таким образом, любое ведущее устройство CANopen может считывать этот индекс из сети ведомых устройств CANopen, чтобы однозначно идентифицировать каждое ведомое устройство по имени. Некоторые индексы объектного словаря, такие как тип устройства (1000h), являются обязательными, а другие, например, версия программного обеспечения производителя (100Ah), являются необязательными.Набор обязательных индексов представляет собой минимальный словарь объектов, необходимый для маркировки устройства, совместимого с CANopen.

Объектный словарь – это метод, с помощью которого можно установить связь с устройством CANopen. Например, можно записать значение true в индекс в разделе объектного словаря, зависящем от производителя (2000h-5FFFh), который устройство может интерпретировать как разрешающий сигнал для получения данных со входа напряжения. И наоборот, ведущее устройство может также захотеть прочитать информацию из объектного словаря, чтобы получить полученные данные или узнать, как в настоящее время настроено устройство. Двумя механизмами связи для доступа к словарю объектов являются объекты служебных данных (SDO) и объекты данных процесса (PDO), которые будут объяснены позже в этом документе.

Основными типами данных, включенными в словарь объектов, являются: логический, void (заполнитель), целое число без знака, целое число со знаком, число с плавающей точкой и символ. Более сложные типы данных, такие как строки, дата и время, могут быть построены из основных типов данных. Эти типы данных могут использоваться для определения пользовательских типов данных, специфичных для CANopen, таких как запись параметра PDO / SDO и параметр сопоставления PDO.Пользователю рекомендуется ознакомиться со спецификацией CANopen для получения дополнительных сведений о компонентах сложных и настраиваемых типов данных.

Формат сообщения CANopen

Формат сообщения для кадра CANopen основан на формате кадра CAN. В протоколе CAN данные передаются в кадрах, состоящих из 11-битного или 29-битного CAN-ID, управляющих битов, таких как бит удаленной передачи (RTR), стартовый бит и 4-битное поле длины данных, а также от 0 до 8 байт данных. COB-ID, обычно называемый в CANopen, состоит из CAN-ID и управляющих битов.В CANopen 11-битный CAN ID разделен на две части: 4-битный код функции и 7-битный идентификатор узла CANopen. Ограничение размера в 7 бит ограничивает количество устройств в сети CANopen до 127 узлов.

Формат кадра CANopen (показаны биты, кроме поля данных)

Все COB-ID должны быть уникальными, чтобы предотвратить конфликты на шине. В SDO-связи всегда должен быть только один узел, которому требуется доступ к индивидуальным индексам объектного словаря подчиненных узлов.

Объекты служебных данных (SDO)

Протокол CANopen также указывает, что каждый узел в сети должен реализовать сервер, который обрабатывает запросы чтения / записи в свой словарь объектов.Это позволяет мастеру CANopen действовать как клиент для этого сервера. Механизм прямого доступа (чтения / записи) к объектному словарю сервера – это Service Data Object (SDO) . Узел, к объектному словарю которого осуществляется доступ, называется SDO-сервером, а узел, захватывающий данные, называется SDO-клиентом. Передача всегда запускается SDO-клиентом.

Обычно главный узел CANopen отправляет запрос в сеть, а интересующий узел отвечает запрашиваемыми данными.CANopen использует зарезервированные идентификаторы сообщений, чтобы облегчить эту связь. Когда SDO-клиент хочет запросить информацию с сервера, он отправляет SDO-запрос, используя CAN-ID 600h + Node ID. Затем сервер ответит, используя CAN-ID 580h + ID узла. Идентификатор узла указывает, с какого ведомого узла приходит сообщение. В примере, показанном ниже, главный узел (клиент SDO) отправляет сообщение в сеть с CAN-ID 603h. Хотя все узлы видят это сообщение, все узлы, кроме целевого узла, игнорируют его, потому что сообщение не предназначено для них.Целевой узел понимает, что сообщение с ID 603h означает, что сообщение предназначено для этого узла, что является запросом SDO. В поле данных сообщения будет указан индекс и субиндекс объекта, к данным которого мастер хотел бы получить доступ. Затем целевой узел отвечает сообщением с идентификатором 583h. Поле данных ответного сообщения будет содержать запрошенные данные.

SDO Пример

Помимо конкретного CAN-ID, раздел данных кадра CANopen также следует определенному формату для SDO.Раздел данных кадра CAN разделен на три части: один байт для спецификатора, три байта для индекса узла и субиндекса и четыре байта для фактических данных при передаче. Байт спецификатора разбит на диаграмму, показанную выше. Три бита байта спецификатора называются спецификатором команды клиента (ccs), который указывает, какой тип сообщения передается (т. Е. Чтение, запись и прерывание). Четвертый бит зарезервирован. Пятый и шестой биты указывают количество байтов в части данных сообщения, которые не содержат фактических данных.Седьмой бит указывает, является ли передача ускоренной или сегментированной. Последний бит указывает, указан ли объем данных в пятом / шестом битах или он указан в части данных сообщения.

Кадр SDO – детали раздела данных

Сегментированная передача выбирается, когда все данные, которые необходимо передать, не помещаются в одно сообщение, и поэтому данные должны передаваться с использованием нескольких сообщений или «сегментов». Напротив, при ускоренной передаче все данные отправляются в виде одного сообщения. На этапе инициализации (см. Раздел NMT) SDO могут передавать до четырех байтов данных. Необязательно, передача SDO также может происходить в серии блоков. Каждый блок состоит из 127 сегментов. Блочная передача выполняется быстрее, чем сегментированная передача больших наборов данных.

Объекты данных процесса (PDO)

Данные процесса представляют собой данные, которые могут изменяться во времени, например, входы (например, датчики) и выходы (т.е. моторные приводы) контроллера узла. Данные процесса также хранятся в объектном словаре. Однако, поскольку связь SDO позволяет получить доступ только к одному индексу объектного словаря за раз, может возникнуть много накладных расходов для доступа к постоянно меняющимся данным. Кроме того, протокол CANopen требует, чтобы узел мог отправлять свои собственные данные без необходимости опрашивания мастером CANopen. Таким образом, для передачи данных процесса используется другой метод, использующий метод связи, называемый Объекты данных процесса (PDO).

Есть два типа PDO: передаваемые PDO (TPDO) и принимающие PDO (RPDO). TPDO – это данные, поступающие от узла (произведенные), а RPDO – это данные, поступающие на узел (потребляемые). Кроме того, есть два типа параметров для PDO: параметры конфигурации и параметры отображения. Раздел объектного словаря, зарезервированный для информации о конфигурации и отображении PDO, – это индексы 1400h-1BFFh.

Параметры конфигурации определяют COB-ID, тип передачи, время запрета (только TPDO) и таймер событий, которые объясняются в этом разделе.Есть разные методы, с помощью которых может быть инициирована передача PDO. Эти методы включают в себя управляемый событиями, управляемый временем, индивидуальный опрос и синхронизированный опрос. Тип передачи указывается в параметрах конфигурации PDO. В случае передачи, управляемой событиями, передача PDO инициируется при изменении данных процесса в ней. При передаче, управляемой временем, передача PDO происходит в фиксированный интервал времени. При индивидуальном опросе передача PDO инициируется с помощью механизма, называемого удаленным запросом, который обычно не используется.При синхронизированном опросе передача PDO инициируется с помощью сигнала SYNC. Сигнал синхронизации часто используется в качестве глобального таймера. Например, если мастер CANopen отправляет сообщение SYNC, несколько узлов могут быть настроены для просмотра этого SYNC и ответа на него. Таким образом, мастер может получить «снимок» нескольких объектов процесса одновременно.

Пример передачи объектов PDO, управляемых событиями

Параметры отображения определяют, какие значения словаря объектов отправляются одним сообщением PDO.Например, одно сообщение PDO может содержать данные из объектных индексов 2001h, 2003h и 2005h.

Пример словаря объектов TPDO

Обзор сетевого управления (NMT)

Услуги сетевого управления включают в себя возможность изменять состояние ведомого устройства между инициализацией, предоперационным, рабочим и остановленным. Протокол NMT позволяет сети CANopen управлять состоянием связи отдельных узлов. Предоперационное состояние в основном используется для настройки устройств CANopen.Таким образом, обмен данными PDO не разрешен в предоперационном состоянии. Связь PDO становится возможной в рабочем состоянии. В остановленном состоянии узел может выполнять только охрану узла или контрольные сигналы, но не может принимать или передавать сообщения. Определенные типы связи CANopen разрешены в разных состояниях. Например, объекты SDO разрешены в предоперационном состоянии, а объекты PDO – нет. Это связано с тем, что SDO часто используются для инициализации параметров объектного словаря, тогда как PDO часто используются для передачи постоянно обновляемых данных.

Guarding и Heartbeats

Спецификация CANopen требует, чтобы узлы использовали какой-либо метод, чтобы проверить, является ли узел «живым» или нет. Доступны два метода: защита узлов и тактовые импульсы, причем последний метод является предпочтительным.

В протоколе пульса узел CANopen периодически отправляет сообщение пульса, которое позволяет мастеру CANopen или потребителю пульса знать, что узел все еще жив. Если контрольное сообщение не приходит в течение определенного периода времени, мастер может предпринять определенное действие.Таким действием может быть сброс узла или сообщение об ошибке оператору. Контрольное сообщение идентифицируется CAN-ID 0x700 + ID узла, где первый байт данных равен 1110.

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

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

Экстренные сообщения

Каждому узлу в сети CANopen назначается одно аварийное сообщение (EMCY), которое сообщает о состоянии узла. Обратите внимание, что протокол пульса и защиты узла предназначен для передачи сообщений о сбоях связи, в то время как аварийные сообщения используются для передачи ошибок внутри узла (например, сбоя датчика). Сообщение EMCY идентифицируется COB-ID 80h + Node ID. Часть данных сообщения EMCY содержит информацию о произошедшей ошибке.

Уровень приложений CAN и CANopen

Словарь объектов (OD) – это центральная концепция, вокруг которой построен CANopen. Это группа предопределенных объектов CANopen, использующая индексы и субиндексы для доступа к объектам через сеть. Словарь объектов – это интерфейс между приложением и устройством, который предоставляет методы для настройки и связи с устройством. Информация, хранящаяся в словаре объектов в виде записей объектов, включает:

• Параметры профиля связи и приложения
• Параметры стандартизированного профиля устройства
• Параметры профиля устройства, определенные производителем
• Типы статических данных профиля устройства
• Сложные типы данных профиля устройства
• Сложные и статические типы данных
• Типы данных, специфичные для производителя
• и т. Д.

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

Поля в записях словаря объектов включают:

Основной индекс: 16-битный индекс, который напрямую указывает на записи в словаре объектов. Для простых переменных индекс ссылается непосредственно на значение переменной, а для сложных типов – на все записи или массивы.

Субиндекс: 8-битный субиндекс, который указывает на отдельные поля данных, такие как элементы массива или значения записи в сложной структуре данных, на которую указывает основной индекс.

Объект: символьное имя типа объекта в записи. Например: VAR, ARRAY, RECORD и т. Д.

Имя: строка, описывающая запись.

Тип: модификатор типа данных записи. Например: UNSIGNED32, BOOLEAN и т. Д.

Атрибут: значение права доступа для этой записи. Например: чтение-запись, только чтение, только запись

Обязательный / Необязательный: , является ли устройство обязательным или необязательным для реализации этой конкретной записи объекта.

Различные группы параметров объекта сгруппированы в диапазоны индексов, как показано ниже:

CANopen – автоматизация в реальном времени

CANopen ™ – это еще один протокол прикладного уровня CAN, такой как DeviceNet и J1939. Как и другие уровни приложений, CANopen – это протокол низкого уровня промышленного уровня для приложений автоматизации.CANopen соединяет устройства автоматизации вместе с помощью однорангового обмена сообщениями. CANopen, построенный на стандартном стандарте физической связи CAN (Controller Area Network), использует оборудование CAN для определения протокола прикладного уровня, который структурирует задачи настройки, доступа и обмена сообщениями между различными типами устройств автоматизации. Структура данных CANopen также является основой нового высокоскоростного протокола EtherCAT.

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

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

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

Устройства CANopen не являются строго одноранговыми устройствами и не являются строго устройствами Master-Slave.Устройство CANopen может быть ведущим для другого устройства CANopen и давать ему команду на выполнение определенных действий. В то же время это может быть подчиненное устройство для другого устройства CANopen, которое желает дать ему команду на выполнение определенных действий. И в то же время он может обмениваться одноранговыми данными с еще одним устройством CANopen.

Нравится то, что вы читаете?

Подпишитесь на нашу серию электронных писем Automation Education, чтобы изучать все тонкости ведущих промышленных протоколов в еженедельном формате размером в байт!

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

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

Согласно спецификации, обязательные объекты должны быть включены в каждое устройство CIP. Эти объекты включают объект Identity, объект Message Router и объект Network.

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

Чтобы упростить настройку устройств и избежать проблемы настройки всех PDO в обоих устройствах CANopen, спецификация CANopen определяет набор предопределенных соединений. Это просто набор предварительно сконфигурированных, хорошо понятных PDO. Используя PreDefined Connection Set, вам не нужно беспокоиться о настройке PDO на обеих сторонах, проверяя их соответствие и проверяя связь.У вас есть набор PDO, у которых уже есть предварительно настроенные COB-ID, которые вы можете использовать. Набор Predefined Connect включает четыре передаваемых PDO, четыре принимаемых PDO, 1 SDO, 1 аварийный объект и 1 идентификатор контроля ошибок узла.

Объекты служебных данных поддерживают передачу асинхронных команд и данных между двумя устройствами CANopen. SDO существуют в основном для настройки, хотя некоторые производители, похоже, предпочитают использовать их для передачи данных. Целью SDO-сообщения, словаря объектов, по которому выполняются действия, является сервер для SDO.Инициатор – Клиент SDO.

SDO преследуют две цели; для чтения записи каталога объектов в другом устройстве CANopen или для записи записи словаря объектов в другом устройстве CANopen. Каждый SDO содержит полный набор из 8 байтов данных, хотя иногда байты данных не используются. В отличие от PDO, передачи SDO всегда подтверждаются получателем. Также в отличие от PDO, SDO могут передавать гораздо больше данных и иметь несколько типов.

Чтобы упростить настройку устройств и снова избежать проблемы настройки всех SDO в обоих устройствах CANopen, спецификация CANopen определяет предопределенный набор соединений.Набор предопределенных соединений содержит по одному SDO в каждом направлении.

Как и в случае с предварительно заданным соединением, установленным для PDO, идентификаторы соединения SDO конфигурируются с адресом узла устройства CANopen, чтобы устройство типа Maser могло легко отправлять SDO на устройство и получать ответные сообщения SDO.

CANopen также поддерживает ряд других типов сообщений:

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

Набор сообщений, которые Мастер использует с набором ведомых устройств CANopen, реализующих набор предопределенных соединений. Протокол NMT (управление сетью) реализуется с использованием одного кадра CAN и получает CAN ID с наивысшим приоритетом (0). Команда NMT состоит из командного байта, указывающего действие, которое необходимо выполнить, и идентификатора узла.Нулевой идентификатор узла используется для обозначения того, что все устройства в сети должны выполнить данную команду.

Набор сообщений, используемых устройством CANopen для передачи некоторой внутренней ошибки. Аварийный протокол передает объект аварийных данных один раз при возникновении внутренней ошибки устройства. Никакие дополнительные сообщения не передаются, если не возникает другое состояние внутренней ошибки устройства. Как правило, главное устройство CANopen – единственное устройство, которое принимает сообщение Emergency Protocol.

Один кадр CAN, который периодически передает текущее состояние NMT устройства.

CiA (CAN In Automation) предоставляет как сертификационную испытательную лабораторию, так и испытательный инструмент. Сертификационная лаборатория тестирует устройства и сертифицирует их на совместимость со спецификацией CANopen. Инструмент тестирования оценивает, правильно ли ведет себя устройство в сети CANopen. Инструмент для тестирования можно приобрести в CiA.

Для получения дополнительной информации о наших продуктах и ​​услугах звоните по телефону 1-800-249-1612.

Хотите узнать больше или у вас есть проект, который вы хотели бы обсудить с нами?

Протокол CANopen – EMCL2

CANopen – это стандартизированный на международном уровне (EN 50325-4) протокол верхнего уровня на основе CAN для встроенной системы управления, разработанный и поддерживаемый членами CiA. Набор спецификаций CANopen включает уровень приложения и профиль связи, а также профили приложений, устройств и интерфейсов. CANopen обеспечивает очень гибкие возможности конфигурации, и по этой причине сети CANopen используются в очень широком диапазоне областей применения, таких как управление машинами, медицинские устройства, внедорожные и железнодорожные транспортные средства, морская электроника, автоматизация зданий, производство электроэнергии и т. Д.

Протокол CANopen определяет в основном два аспекта протокола связи: , как, , должна быть отформатирована связь (кадр CANopen), и , какие объекты определены совместно. Эти объекты могут использоваться для настройки или арбитража связи или просто для обмена данными приложения. Коммуникационные объекты доступны:

• Обмен данными процессов и услуг.
• Синхронизация времени процесса или системы.
• Ошибка контроля состояния.
• Контроль и мониторинг состояний узлов.

Это показано на следующем интерактивном рисунке:

Для получения дополнительной информации о протоколе CANopen перейдите по этой ссылке.

Фрейм CANopen

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

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

Дополнительную информацию о спецификации CAN см. В разделе CAN.

Поле арбитража

В сообщениях CANopen часть идентификатора поля арбитража известна как идентификатор объекта связи (COB-ID).Он разделен на 4-битную часть , функциональный код и 7-битный идентификатор узла, как показано:

Параллельно с CAN, каждый узел в сети CANopen должен иметь уникальный идентификатор узла. Диапазон допустимых значений от 1 до 127. Ноль не допускается.

Точно так же приоритет определяется битами COB-ID и RTR. Как и ожидалось, бит RTR в поле арбитража используется для запроса информации от удаленного узла. В частности, он используется для реализации функций защиты узла , и TPDO, которые описаны в следующих главах.За исключением этих двух обстоятельств, бит RTR всегда устанавливается в ноль.

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

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

• Широковещательные сообщения CANopen:

прием)

SDO Идентификатор узла

0x1567

Поле данных

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

Данные сохраняются и передаются в формате little endian , что означает, что младший байт данных помещается в первую позицию. Например, число 0x15542612 будет представлено как:

Базовые знания CANopen • KUNBUS GmbH

CANopen – это протокол связи, используемый для встроенных систем автоматизации процессов.Таким образом, его можно использовать для организации сети в сложных устройствах. Этот стандарт состоит из адресации, нескольких небольших протоколов связи и прикладного уровня, который определяется устройством. Протоколы связи поддерживают управление сетью, мониторинг устройств и связь между различными узлами. Как правило, нижним уровнем CANopen для реализации соединения для передачи данных является сеть контроллеров (CAN). Однако устройства, основанные на других протоколах связи (например, Ethernet, Powerlink, EtherCAT), также могут обрабатывать профиль CANopen.

Устройства CANopen и коммуникационные профили управляются в спецификации CiA 301 «CAN в автоматизации». Основным регионом распространения является Европа, но также наблюдается прогресс в Северной Америке и Азии. Профили для более специализированных устройств построены на этом базовом профиле и перечислены во многих других стандартах, опубликованных в «CAN в автоматизации».

Модель устройства

Каждое устройство CANopen должно поддерживать определенные стандартные функции в своем программном обеспечении.

• Блок связи реализует протоколы для сообщений другим узлам в сети.
• Запуск и сброс устройства происходит через контролируемый блок управления состоянием. Он должен включать состояния «инициализация», «предварительная эксплуатация», «сама задача» и «остановка». Переходы между состояниями устанавливаются сетевым управлением (NMT).
• Каталог объектов – это поле переменных с 16-битным индексом. Более того, каждая переменная может иметь 8-битную подблоку. Переменные можно использовать для настройки устройства.
• Часть приложения выполняет фактическое приложение, которое должно быть выполнено после того, как блок управления статусом предоставил разрешение.Приложение определяется переменными в каталоге объектов, а данные передаются и принимаются через уровень связи.

Каталог объектов

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

• Индекс: 16-битный адрес объекта в каталоге
• Название объекта
• Имя: строка символов, описывающая запись
• Тип: указывает тип данных переменной (или тип данных всех переменных массива).
• Переменная атрибута: предоставляет информацию о правах доступа. Это может быть чтение и запись, только чтение или запись.
• Обязательный / необязательный (M / O): указывает, может ли устройство выполнять требуемую задачу в соответствии со спецификациями устройства или нет.

Объекты связи

Шина CAN, физическая основа CANopen, может передавать только короткие пакеты.Он состоит из 11-битного идентификатора, бита запроса удаленной передачи (RTR) и от 0 до 8 байтов данных. Стандарт CANopen подразделяет 11-битный идентификатор CAN на 4-битный код функции и 7-битный идентификатор узла. Это ограничивает количество устройств в сети CANopen до 127. Расширение стандарта CAN-шины CAN 2.0 B позволяет использовать до 29 бит, однако на практике сети CANopen в большинстве своем достаточно велики, так что расширенный диапазон идентификаторов требуется редко. .

В CANopen 11-битный идентификатор известен как идентификатор объекта связи, COB-ID.В случае ошибки передачи это позволяет устройству с наименьшим идентификатором передать данные первым и без задержки. Таким образом, критичной ко времени информации всегда следует давать низкий код.

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

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

• В методе мазер / подчиненный один узел определяется как главный, который запрашивает данные у подчиненного устройства или отправляет данные подчиненному устройству. Протокол NMT является примером связи ведущий / ведомый.
• Отношения клиент / сервер используются в протоколе SDO, где клиент SDO отправляет данные на сервер SDO, который отвечает на запрошенные данные одним или несколькими пакетами SDO.
• Модель производитель / потребитель используется с «протоколом проверки пульса и защиты узлов». В режиме извлечения производитель отправляет данные потребителю без специального запроса, в то время как в режиме извлечения потребитель запрашивает данные у производителя.

Объекты связи

Доступны следующие услуги связи:

• Объекты управления сетью (NMT) для управления контроллером состояния и для узлов мониторинга.
• Объекты служебных данных (SDO) для определения записей каталога объектов
• Объекты данных процесса (PDO) для передачи данных в реальном времени
• Объект синхронизации (SYNC)
• Система отметок времени и сообщений об ошибках (EMCY)

Электронные паспорта

CANopen для работы требуются электронные таблицы данных (так называемые файлы EDS). Они существуют в стандартизированном текстовом формате, который описывает наиболее важные параметры объекта и физические параметры.Это используется, например, для определения поддерживаемых скоростей передачи. Файлы EDS можно читать с помощью средств связи. Это разрешает связь с соответствующим устройством. На основе этого также может иметь место конфигурация. Для проверки правильности синтаксиса можно использовать свободно доступное программное обеспечение.
С 2007 года также доступен формат на основе XML. Этот формат XDD стандартизирован в ISO 15745 и позволяет подробно описывать различные функции устройств. Таким образом, приложение описывается независимо от протокола.Для этого нового формата XDD также доступен бесплатный редактор.

CANopen, стек протоколов, исходный код

Наш стек протокола CANopen предоставляет простой программный интерфейс (API) для отправки и получения сообщений CANopen. Наше программное обеспечение стека протоколов CANopen абстрагируется от технических деталей и многих сложностей, связанных с синхронизацией сообщений и взаимодействием с сетями CANopen. Это повышает простоту вашего прикладного программного обеспечения, повышает надежность и сокращает время вывода продукта на рынок.

Программное обеспечение CANopen имеет небольшой размер ПЗУ / ОЗУ и поддерживает несколько каналов CAN с максимум 512 TPDO и RPDO. Также поддерживаются ускоренные передачи SDO, сообщения NMT, создание тактовых импульсов и таймеры событий / запрета PDO.

Simma Software использовались в более чем миллионе встраиваемых систем крупнейшими производителями автомобилей и более чем в 200 проектах реального времени.

• Соответствует MISRA C
• Исходный код ANSI C
• Использование с ОСРВ или без нее
• Используется с 8, 16, 32 или 64-битным ЦП
• Используйте с загрузчиком Flash для обновления продукта
• Справочное руководство пользователя CANopen

Введение в CANopen

Эта статья предназначена для того, чтобы дать инженерам краткий обзор протокола CANopen, который определен CiA 301 и поддерживается CAN в автоматизации. Для получения подробной информации о самой спецификации посетите CAN in Automation (CiA). Вот версия для печати этого введения в CANopen.

CANopen – это протокол реального времени, используемый в автоматизации, автомобильном и медицинском оборудовании. CANopen управляет каналом передачи данных, транспортным протоколом, сетевым управлением и уровнями приложений. Обычно CANopen использует CAN в качестве физического уровня со скоростью передачи от 125 Кбит / с до 1 Мбит / с.

Существует несколько различных прикладных уровней, известных как профили устройств.Например, CiA 401 определяет уровень приложения (т. Е. Профиль устройства) для общего устройства ввода-вывода, а CiA 402 определяет работу сервоприводов, преобразователей частоты и шаговых двигателей. Всего существует более 50 отдельных и определенных профилей устройств.

Обзор CANopen

CANopen – это протокол связи высокого уровня, работающий на шине сети контроллеров (CAN). CiA 301 в сочетании с профилем устройства (например, CiA 401) образуют полную спецификацию, которая точно определяет, как информация (например, CiA 401). грамм. частота вращения серводвигателя) меняется между электронными блоками управления (ЭБУ).

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

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

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

Все данные хранятся в виде записей в заранее определенных местах словаря объектов. Индекс записей и субиндекс перечислены в CiA 301 и соответствующем профиле устройства. Запись OD имеет индекс, имя объекта, описание, тип, атрибут и необязательное поле.

Объект данных процесса (PDO)

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

Есть два типа PDO: принимающие и передающие PDO (RPDO и TPDO). RPDO используется, когда узлу необходимо получить данные (т.е. читать данные), а TPDO используется, когда узлу необходимо передать данные (т.е. запись данных). CiA 301 определяет восемь идентификаторов, четыре для RPDO и четыре для TPDO.

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

Объект служебных данных (SDO)

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

Пример чтения SDO – это когда узел запрашивает имя устройства производителя и / или тип устройства другого узла.

стеков протокола CANopen | MicroControl

CANopen® – это открытый протокол уровня 7, основанный на CAN (Controller Area Network). CANopen® в основном применяется в машинах как встроенная сетевая система и как общепромышленная система связи.

MicroControl используются во всем мире многими компаниями. Они были специально разработаны для сочетания низких требований к памяти с оптимальной производительностью. Просто изменив драйвер CAN CANpie FD, все стеки протоколов можно легко адаптировать к целевому оборудованию.

MicroControl теперь оснащены CANpie FD (среда интерфейса программирования CAN для гибкой скорости передачи данных).Этот стандартизированный интерфейс драйвера облегчает интеграцию различных контроллеров. Переход с CANopen Classic на CANopen FD возможен в любое время и только в зависимости от вашего предпринимательского решения. Долговременная эффективность этого нового поколения стеков протоколов является стандартной функцией, и в то же время выполняются требования Индустрии 4.0.

Для различных требований мы предлагаем следующие решения:

Наш главный стек протоколов CANopen идеально подходит для сложных систем управления и предлагает функциональные возможности стандартов CANopen® CiA 301, CiA 302 и CiA 305.

Наш стек протоколов CANopen / CANopen FD slave облегчает разработку интеллектуальных датчиков и исполнительных механизмов в соответствии со спецификацией CANopen® CiA 301.

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

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

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

Пользователи стеков протоколов MicroControl получают бесплатную поддержку в течение 12 месяцев с даты покупки. Последующее соглашение о дополнительном обслуживании будет содержать автоматические обновления программного обеспечения.

Клиенты MicroControl также получают выгоду от экономичной корпоративной лицензии (по сравнению с обычными лицензиями на выполнение).Вам интересно? Мы будем рады ответить на ваши вопросы об аспектах и ​​содержании нашей политики честного партнерства.