Универсальный внешний накопитель для всех iOS-устройств, совместим с PC/Mac, Android
Header Banner
8 800 100 5771 | +7 495 540 4266
c 9:00 до 24:00 пн-пт | c 10:00 до 18:00 сб
0 Comments

Содержание

Расширение возможностей автоматизации с помощью CANopen

Введение

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

Шина CAN (Controller Area Network — местная контроллерная сеть, определение дано согласно ГОСТ Р ИСО 11898-2-2015) — это стандарт промышленной сети, ориентированный прежде всего на объединение в одну сеть различных исполнительных устройств и датчиков. Это протокол на основе сообщений, который стал предпочтительным стандартом для широкого спектра отраслей промышленности [2]. В этих отраслях существуют многочисленные протоколы разного уровня, каждый со своей специализацией и отраслевыми особенностями. В свою очередь, CANopen был создан как высокоуровневый сетевой протокол, работающий поверх физического CAN. Сейчас это один из самых популярных протоколов, а с развитием интеллектуальной, или «умной» автоматизации и «Интернета вещей» (Internet of Things, IoT) он становится все более и более востребованным [3].

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

 

Общие сведения

CAN-шина

Controller Area Network (шина CAN) — это внутренняя коммуникационная сеть, которая изначально была разработана для автомобилей. Использовать ее предложил Роберт Бош (Robert Bosch), владелец компании Robert Bosch GmbH, — для снижения стоимости производства автомобилей. Шина CAN стала альтернативой толстым многожильным кабелям, необходимым для подключения датчиков и узлов внутренней электроники автомобилей, которых становилось все больше, и позволила упростить прокладку кабелей благодаря использованию многоузловых шин. Когда шина CAN была впервые представлена в автомобиле BMW 850 в 1986 г., этот интерфейс позволил сэкономить более 2 км проводов! Кроме того, значительно уменьшилось количество разъемов, повысилась надежность, а оценочная экономия веса составила 50 кг [12]. В 1993 г. Международная организация по стандартизации приняла шину CAN в качестве международного стандарта [4].

Одним из основных преимуществ шины CAN является то, что она обеспечивает связь между устройствами и микроконтроллерами без необходимости использования главного компьютера. Устройства подключаются через один витой провод, а сигналы, передаваемые любым из них, принимаются всеми остальными устройствами, подключенными по шине CAN [5]. Для определения предполагаемых получателей сообщений, передаваемых по шине CAN, в каждом сообщении используются идентификаторы узла, а сами узлы определяются через так называемый словарь объектов (рис. 1).

Рис. 1. Организация сети CAN на основе одной витой пары

Что же касается CANopen, он использует кадры CAN в качестве носителей данных. Кадры CAN доставляют данные от одного узла сети к другим, т. е. выполняют задачу канального уровня (data link layer) модели OSI. Таким образом, CANopen использует протокол CAN на канальном уровне. С помощью CAN-кадров можно обмениваться любыми данными (до 8 байт), вне зависимости от их предназначения. Используя CAN, пришлось бы придумывать свои правила обмена (свой протокол). Так, например, в центральных процессорах (CPU) программируемых логических контролеров (ПЛК) потребовалось бы записывать микропрограмму для формирования последовательности байтов данных в кадре, а в модуле — микропрограмму для их интерпретации. В реальных ПЛК обмен между CPU и модулями проходит неявно, то есть без участия программы пользователя. Подобного функционала не хватает CAN. Эти функции обеспечивают протоколы прикладного уровня CANopen, описанные в стандарте CiA DS 301 [13] (CiA — компания CAN in Automation [6]). Эта спецификация определяет прикладной уровень CANopen, в том числе типы данных, правила кодирования и объекты словаря объектов, коммуникационные сервисы и протоколы CANopen, а также сервисы и протоколы управления сетью CANopen.

Архитектура нижнего уровня CAN определяет только физическую структуру сети CANopen. По сути она ничем не отличается от других сетей CAN: используется линейная (шинная) топология, где все устройства параллельно подключены к одной двухпроводной линии связи. Чтобы избежать паразитных отражений сигнала, оба конца сети должны быть нагружены на терминирующую нагрузку (два резистора по 120 Ом, показанные на рис. 1). Кроме того, должны быть учтены максимально допустимые длины сегментов сети между отдельными сетевыми узлами — в зависимости от скорости передачи и параметров линии.

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

CAN-протоколы высшего уровня

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

Существует широкий спектр высоко­уровневых протоколов на основе CAN, многие из которых предназначены для конкретных отраслей или даже для использования одним производителем. Среди наиболее распространенных стандартизированных протоколов высокого уровня — CANopen, DeviceNet и SAE J1939. Примеры более специализированных протоколов — GMLAN (для General Motors), RV-C (для транспортных средств для отдыха) и космический протокол CubeSat (для CubeSats) [6].

CAN в автоматизации

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

CANopen разрабатывается и поддерживается CAN in Automation (CiA) — международной некоммерческой организацией для пользователей и производителей CAN [7].

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

Устройства CANopen

Устройства CANopen, обычно называемые узлами, должны иметь словарь объектов (OD, OBD object dictionary) — стандартизированную таблицу, в которой хранятся данные, относящиеся к узлу и его работе. Через объектный словарь можно обратиться ко всем объектам CANopen-устройства. OD разделен на область с общей информацией об устройстве, такой как название производителя и т. д., область, содержащую параметры связи, и область, которая описывает специфичную для устройства функциональность. Через записи (объекты) OD прикладные объекты устройства, такие как входные и выходные сигналы, параметры устройства, сервисы устройства или сетевые переменные, становятся доступными по сети в стандартизированной форме.

OD образует интерфейс между сетью и прикладным программным обеспечением.

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

Обмен данными в CANopen реализуется в соответствии с архитектурой Master/Slave: одно из устройств является ведущим (Master) и осуществляет управление сетью (Network Management, NMT). Все остальные имеют статус ведомых (Slaves). Кроме того, протокол CANopen позволяет применять коммуникационные модели Producer/Consumer (производитель/потребитель, иногда также называется поставщик/потребитель) и Client/Server (клиент/сервер).

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

В модели «клиент — сервер» «клиенты» читают или записывают данные с «серверов». Наконец, в модели связи «производитель — потребитель» «производители» передают данные всем другим узлам, то есть «потребителям».

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

Еще одна важная услуга связи — это периодические контрольные сообщения (heartbeat), посылаемые по линии связи, которую узлы регулярно передают друг другу, указывая тем самым, что они все еще активны [10].

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

2).

Рис. 2. Сообщения CANopen следуют стандартному формату, который определяет источник передачи и ретранслирует до 64 бит данных на один цикл передачи

Первая часть сообщения CANopen содержит 11-битный длинный CAN-ID, идентифицирующий передающее устройство, за которым следует управляющий бит. Эта часть сообщения обычно называется идентификатором объекта связи, или COB-ID. Она создает коммуникационное соединение между передаваемым и принимаемыми коммуникационными объектами и в то же время определяет приоритет сообщения. Удаленный запрос передачи — RTR. Идентификатор 0 с наивысшим приоритетом зарезервирован для сервисов управления сетью. Следующие четыре бита сообщают приемным устройствам, какова длина сообщения, чтобы они могли определить, в какой точке передачи сообщение заканчивается. Последняя часть сообщения CANopen представляет собой фактические данные, длина которых может достигать 8 байт (или 64 бит). Фактическая длина сообщения зависит от типа передаваемых данных. Подробнее про формат кадра передачи данных CAN можно прочитать в статьях [6, 11].

 

Проблемы

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

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

Трудности в сфере автоматизации

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

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

Сложность расширения интерфейса

Сложность систем, используемых на «умных» предприятиях, является одним из ключевых вызовов для любой новой системы внутренней коммуникации. Из-за огромного количества различных устройств (каждое из них — со своими индивидуальными и запутанными функциями и компоновкой аппаратного обеспечения) расширение интерфейса, необходимое для реализации такой системы, как CANopen, может выглядеть пугающим, если не просто невозможным.

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

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

Проблемы среды эксплуатации

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

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

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

 

Решения

Карты расширения шины CAN

Требования к оборудованию для реализации системы шины CAN, например системы, в которой используются протоколы высокого уровня CANopen или SAE J1939, могут быть удовлетворены с минимальными затратами и с большой гибкостью благодаря использованию плат расширения шины CAN. Платы расширения шины CAN, которые используют стандартные входные разъемы, такие как mPCIe, 5-контактный разъем и M.2, и общие интерфейсы (USB и PCI-Express), обеспечивают высокую степень гибкости, что позволяет использовать их в самых разных областях автоматизации, измерительных приборах и оборудовании. Таким образом, системным операторам не нужно перепроектировать устройства или их аппаратное обеспечение для поддержки шины CAN. Вместо этого достаточно использовать карты расширения CAN, которые для обеспечения желаемой функциональности можно легко подключить к уже существующим портам расширения (рис. 3).

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

Поддержка интерфейса и программное обеспечение

При использовании плат расширения шины CAN системным интеграторам необходимо учитывать целый ряд важных моментов. В первую очередь они должны убедиться в том, что карты расширения поддерживают желаемые протоколы более высокого уровня, например CANopen и SAE J1939. Также важно понять, могут ли карты расширения быть реализованы в програм­мной среде, будь то система на основе Linux или Windows, и работают ли они на процессорах архитектуры ARM или x86.

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

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

Специально разработанное оборудование

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

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

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

 

Заключение

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

Facebook

Twitter

Вконтакте

Google+

Интерфейсы CANopen и DeviceNet – rentamatic

CAN (Controller Area Network) был разработан для применения в электрооборудовании автомобилей. В последнее время CAN также широко применяется и в индустрии. CAN является мультимастерной системой, т.е. каждое устройство может в любой момент времени, если шина свободна, иметь доступ к шине. CAN работает не с адресами в своем смысле, а с идентификаторами сообщений. Это означает, что доступ к шине осуществляется по принципу CSMA / CA (Carrier Sense Multiple Access with Collision Avoidance), т.е. каждое устройство «прослушивает» шину и может посылать данные, если шина свободная. Если два устройства стартуют посылку данных одновременно, то право доступа к шине получает устройство с найвысшим приоритетом (сообщение с найменьшей величиной идентификатора). Устройство с более низким приоритетом прекращает трансфер данных и пытается возобновить доступ к шине, если шина опять свободная. Передаваемые данные могут быть приняты любым устройством. Благодаря специальному приемному фильтру каждое устройство в отдельности принимает лишь те данные, которые для него предназначены.

Сенсоры фирмы Fraba Posital поддерживают два CAN -протокола: CANopen и DeviceNet.

CANopen

Техника передачи: Двухпроводная
Скорость передачи: 20 kBaud – 1 mBaud
Устройства: макс. 127
Длина линии связи: 30 м при 1 mBaud 5000 m при 20 kBaud

DeviceNet

Техника передачи: Двухпроводная
Скорость передачи: макс. 500 kBaud
Устройства: макс. 64
Длина линии связи: 100 м при 500 kBaud

CANopen

Передача данных осуществляется телеграммами сообщений. В основном телеграммы состоят из так называемых COB -идентификаторов и максимум 8 последующих байтов. COB -идентификатор, который определяет приоритетность сообщений, состоит из функционального кода и номера узла. Каждому устройству однозначно присваевается номер узла. Для этой цели все сенсоры фирмы Fraba Posital оснащены вращающимися цифро-кодированными переключателями для установки/присвоения номера узла. Функциональный код учитывает разные способы передачи данных.

Административные сообщения ( LMT , NMT )
Сервизные данные сообщений ( SDO )
Процессные данные сообщений ( PDO )
Предварительно дефинированные сообщения (синхронизационные-, аварийные сообщения)

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

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

Датчики угла поворота фирмы Fraba с CANopen интерфейсом

Датчики фирмы Fraba поддерживают все функции CANopen. Следующие режимы работы могут быть запрограммированы:

Polled Mode : Значение угла поворота (позиционное значение) может быть передано лишь по запросу.
Cyclic Mode : Позиционное значение выдается циклически (интервал устанавливается).
Sync Mode : Актуальное позиционное значение датчик посылает после приема синхронизирующей телеграммы. Синхро-счетчик может быть так запрограммирован, что датчик посылает свои значения лишь после определенного количества телеграмм синхронизации.
Chance of State Mode: Датчик посылает лишь изменившееся позиционное значение.

Дополнительно могут быть параметрированы такие функции как: направление вращения (направления счета – возрастающее или спадающее), разрешение и т.д.

Датчики фирмы Fraba соответствуют 2 классу профиля для датчиков угла поворота (DSP 406), в котором определены особенности датчиков угла поворота с CANopen -интерфейсом. Подключение датчика к шине осуществляется через клеммы в устройстве подключения, в котором могут быть также установлены номер узла и скорость передачи с помощью вращающегося переключателя. Для проектировния и параметрирования существует программное обепечение разных производителей. С помощью поставляемого EDS -файла предоставляется возможным простое взятие в эксплуатацию и программирование датчиков.

DeviceNet

Этот протокол применятется преимущественно фирмой Allen Bradley. Особенностью структуры протокола является огрниченное до 64 количество устройств подключенных к шине. Максимальная скорость передачи данных составляет 500 kBaud. Коммуникация осуществляется также с помощью телеграмм сообщений, которые состоят из 11 битного идентификатора и 8 последующих байтов.

CAN-ID Message
Header
Message
Body
11 Bit 1 Byte 7 Byte

DeviceNet -протокол базируется на идее соединений; Для того, чтобы с одним устройством обменяться информацией, должна быть сначала установлена связь с ним. CAN -идентификатор используется для оценки этого соединения.

Датчики фирмы Fraba с DeviceNet-интерфейсом

Датчики фирмы Fraba Posital поддерживют все DeviceNet -функции. Следующие режимы работы могут быть выбраны:

Polled Mode : Значение угла поворота (позиционное значение) может быть передано лишь по запросу.
Chance of State Mode: Датчик посылает лишь изменившееся позиционное значение.
Cyclic Mode : Позиционное значение выдается циклически (интервал устанавливается)

Также как и в CANopen предусматривается программирование таких параметров как: направление вращения (направления счета – возрастающее или спадающее), разрешение и Preset -значение (значение после сброса).

Установка номера узла (устройства) и скорость передачи устанавливается также как и в датчиках с CANopen -интерфейсом, с помощью переключателя в устройстве подключения. С помощью поставляемого EDS-файла и актуальных проектирующих средств предоставляется возможным проектирование и простое взятие датчиков в эксплуатацию.

Дополнительная информация: www.datamicro.ru – Хороший сайт по полевой шине CAN – bus, есть много статей.

CANopen / CAN bus, что мне нужно, включая протокол (OD?), для связи между модулем устройства PC terminal и CAN



У меня есть dsPIC33 с ECAN и я хочу установить протокол (используя SDO , если это возможно) таким образом, чтобы он взаимодействовал между terminal программным обеспечением и dsPIC33, где я могу выполнять диагностику в dsPIC33 и поддерживать ICs.

Я не знаю, что требуется, так что же такое недорогой способ сделать это? Я мог бы использовать устройство CAN-to-USB, но я не уверен, что это сработает. Какой протокол внутри CANUSB оборачивается вокруг сообщения на основе ASCII?

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

c embedded network-protocols can-bus
Поделиться Источник riscy     15 августа 2011 в 19:41

2 ответа


  • Поиск фреймворка CAN-Bus для Android или Java

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

  • использование arduino с can bus sheild

    Я пытаюсь вытащить 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 version after v1.1 is default to D9 // v0.9b and v1.0 is default D10 const int SPI_CS_PIN = 9;...



4

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

Если вы не хотите приобретать какое-либо стороннее программное обеспечение, то вы должны:

  1. Реализуйте базовый драйвер CAN для dsPIC33 (передача и прием базового кадра).
  2. Реализуйте протокол CANopen SDO поверх вашего базового драйвера на dsPIC33.
  3. Приобретите недорогой интерфейс CAN<->USB (который должен поставляться вместе с DLLs, что позволит вам развиваться в C, C++ или C#.
  4. Напишите приложение PC, используя файлы DLL, которые реализуют протокол CANopen SDO.

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

Поделиться Tim Henigan     15 августа 2011 в 20:23


Поделиться Ulrik Hagström     16 августа 2011 в 05:38


Похожие вопросы:


Программист, пытающийся понять CANopen

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


Java и CANopen

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


Как запрограммировать простой слой CANopen

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


Поиск фреймворка CAN-Bus для Android или Java

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


использование arduino с can bus sheild

Я пытаюсь вытащить 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...


Как устранить неполадки CAN bus communication

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


Реализация протокола CAN Bus

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


CAN bus и Android коммуникационные советы

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


Идентификатор CAN и COB-ID

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


CAN Bus: возможна ли имитационная связь?

Мне нужно установить протокол 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

PLC device  Request message
  High byte Low byte 
D25000 Message Header   ReqID Command (Fixed to 01)
D25001 Reserved Size
D25002 Type Node ID
D25003     Message Data High byte of main index Low byte of main index
D25004 Reserved Sub-index
D25005 Data 1  Data 0
D25006 Data 3  Data 2
D25007 - D25031 Reserved

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

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

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

PLC device  Response message
  High byte Low byte 
D24000 Message Header   ResID Status code
D24001 Reserved Size
D24002 Type Node ID
D24003     Message Data High byte of main index Low byte of main index
D24004 Reserved Sub-index
D24005 Data 1  Data 0
D24006 Data 3  Data 2
D24007 - D24031 Reserved

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.

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

Тип «Slave» (-COS)               Тип «Master» (-СОМ)
32 Rx-/32 Tx-PDOПоддержка до 127 узлов
Объем данных ввода/вывода: 510 байтОбъем данных ввода/вывода: 7168 байт
Тип PDO: асинхронный, по запросу PDO: Cyclic, Acyclic, AsyncТип PDO: асинхронный, переодидический, апереодический, по запросу
Тип интерфейса: ISO 11898, изолированный, DSub-male

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

  • Интерфейсная плата
  • 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 Synopsis

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

Тип сети: Система связи ведомого устройства с несколькими ведущими
Топология: Линия с магистральной линией, дроплайн с оконечным подключением на каждом конце
8 2 данные 2 мощность)
Скорость передачи данных: 125K, 250K, 500K, 1M
Максимальное количество устройств: 127

Структура данных 9014pen9 is an

объектный протокол связи. Словарь объектов описывает полную функциональность устройства. Словарь объектов - это точка соединения между интерфейсом связи и прикладной программой. Все коммуникационные объекты описаны в Словаре объектов стандартизированным образом. Эти объекты доступны по 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 инициируются либо внутренним устройством, либо каким-либо внешним сообщением.

Чтобы упростить настройку устройств и избежать проблемы настройки всех 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 также поддерживает ряд других типов сообщений:

SYNC-сообщения

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

Сообщения NMT

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

АВАРИЙНЫЕ сообщения

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

Сообщения HEARTBEAT

Один кадр 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:
NM

Связь Объект

прием)

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

0x1567

Связь Объект

Код функции (двоичный)

COB-ID (шестнадцатеричный)

903 903 служба

0000b

0x000

SYNC

0001b

0x080

Код функции (двоичный)

COB-ID (шестнадцатеричный)

Диапазон допустимых COB-ID (шестнадцатеричный)

АВАРИЯ

0001b

0x80 + идентификатор узла

0x81 - 0x0FF

PDO1 (передача)

0011b

0x180 + идентификатор узла

0100b

0x200 + ID узла

0x201 - 0x27F

PDO2 (передача)

0103

0101 - 0x2FF

PDO2 (прием)

0110b

0x300 + ID узла

0x301 - 0x37F)

0x380 + ID узла

0x381 - 0x3FF

PDO3 (получение)

9015 8

1000b

0x400 + ID узла

0x401 - 0x47F

PDO4 (передача)

1001b

1001b

PDO4 (прием)

1010b

0x500 + ID узла

0x501 - 0x57F

0x581 - 0x5FF

SDO (получение)

1100b

0x600 + идентификатор узла

0x1567

1110b

0x700 + ID узла

0x701 - 0x77F

Поле данных

Содержимое поля данных зависит от типа сообщения 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 на сообщение
(прибл. Для ЦП C2000)
Сравнение размера кода CANopen
(приблизительно для ЦП C2000)

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

Стеки протоколов, драйверы устройств и загрузчики

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

Программный протокол CANopen Сведения о стеке:
  • Соответствует 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® в основном применяется в машинах как встроенная сетевая система и как общепромышленная система связи.

Модульные стеки протоколов CANopen / CANopen FD

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

Стеки протоколов CAN

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 также получают выгоду от экономичной корпоративной лицензии (по сравнению с обычными лицензиями на выполнение).Вам интересно? Мы будем рады ответить на ваши вопросы об аспектах и ​​содержании нашей политики честного партнерства.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *