Войти
CANopen - это протокол связи и спецификация профиля устройства для встроенных систем, используемых в автоматизации. Что касается модели OSI , CANopen реализует вышеперечисленные уровни, включая сетевой уровень . Стандарт CANopen состоит из схемы адресации, нескольких небольших протоколов связи и прикладного уровня, определенного профилем устройства. Коммуникационные протоколы поддерживают управление сетью, мониторинг устройств и связь между узлами, включая простой транспортный уровень для сегментации / десегментации сообщений. Протокол нижнего уровня, реализующий канал передачи данных и физические уровни, обычно представляет собой Controller Area Network (CAN), хотя устройства, использующие другие средства связи (например, Ethernet Powerlink, EtherCAT ) также может реализовать профиль устройства CANopen.
Базовое устройство CANopen и коммуникационные профили приведены в спецификации CiA 301, выпущенной CAN in Automation. Профили для более специализированных устройств построены на основе этого базового профиля и определены во многих других стандартах, выпущенных CAN в автоматизации, таких как CiA 401 для модулей ввода-вывода и CiA 402 для управления движением.
Каждое устройство CANopen должно реализовывать определенные стандартные функции в своем управляющем программном обеспечении.
Устройства CANopen должны иметь словарь объектов, который используется для настройки и связи с устройство. Запись в словаре объектов определяется:
Основные типы данных для значений словаря объектов, таких как логические, целые числа и с плавающей запятой определены в стандарте (их размер в битах опционально сохраняется в определении связанного типа, диапазон индекса 0x0001–0x001F), а также составные типы данных, такие как строки, массивы и записи (определены в индексе ra nge 0x0040–0x025F). Составные типы данных могут быть субиндексированы с помощью 8-битного индекса; значение в субиндексе 0 массива или записи указывает количество элементов в структуре данных и имеет тип UNSIGNED8.
Например, параметры связи устройства, стандартизированные в базовом профиле устройства CiA 301, отображаются в диапазоне индексов 0x1000–0x1FFF («область профиля связи»). Первые несколько записей в этой области следующие:
| Индекс | Имя объекта | Имя | Тип | Атрибут | M / O |
|---|---|---|---|---|---|
| 0x1000 | VAR | тип устройства | UNSIGNED32 | ro | M |
| 0x1001 | VAR | регистр ошибок | UNSIGNED8 | ro | M |
| ... | |||||
| 0x1008 | VAR | имя устройства производителя | Vis-String | const | O |
| ... |
При наличии подходящих инструментов содержимое объектного словаря устройства на основе электронного листа данных (EDS) можно настроить для устройства файл конфигурации (DCF) для интеграции устройства в конкретную сеть CANopen. Согласно CiA 306 формат EDS-файла - это формат INI-файла. В ближайшее время появится формат в стиле XML, описанный в CiA 311.
CAN-шина, уровень канала данных CANopen, может только передавать короткие пакеты, состоящие из 11-битного идентификатора, бита запроса удаленной передачи (RTR) и от 0 до 8 байтов данных. Стандарт CANopen делит 11-битный идентификатор кадра CAN на 4-битный код функции и 7-битный идентификатор узла CANopen. Это ограничивает количество устройств в сети CANopen до 127 (0 зарезервировано для широковещательной передачи). Расширение стандарта шины CAN (CAN 2.0 B) позволяет использовать расширенные идентификаторы кадров длиной 29 бит, но на практике сети CANopen, достаточно большие, чтобы требовать расширенного диапазона идентификаторов, встречаются редко.
В CANopen 11-битный идентификатор CAN-кадра известен как идентификатор объекта связи или COB-ID. В случае коллизии передачи, арбитраж шины, используемый в шине CAN, позволяет фрейму с наименьшим идентификатором быть переданным первым и без задержки. Использование низкого кода для критичных по времени функций обеспечивает минимально возможную задержку.
Содержимое 11-битного кадра CANopen:
| CAN-ID | RTR | Длина данных | Данные | |
|---|---|---|---|---|
| Длина | 11 бит | 1 бит | 4 бита | 0-8 байтов |
Кадр данных с 11-битным идентификатором также называется «форматом основного кадра». ".
При отображении CAN-ID по умолчанию кадры сортируются путем присвоения кода функции (NMT, SYNC, EMCY, PDO, SDO...) первым 4 битам, так что критически важные функции получают приоритет. Однако это сопоставление можно настроить для специальных целей (за исключением NMT и SDO, необходимых для базовой связи).
| Код функции | ID узла | |
|---|---|---|
| Длина | 4 бита | 7 бит |
Стандарт резервирует определенные идентификаторы CAN-ID для управления сетью и передачи SDO. Некоторые функциональные коды и CAN-ID должны быть сопоставлены со стандартными функциями после инициализации устройства, но могут быть настроены для других целей позже.
Для простых сетевых структур CANopen поддерживает предопределенное распределение идентификаторов сообщений.
| Коммуникационный объект | COB-ID в шестнадцатеричном формате | Ведомые узлы | Спецификация |
|---|---|---|---|
| Управление узлом NMT | 000 | Только прием | CiA 301 |
| Глобальная команда отказоустойчивости | 001 | ? | CiA 304 |
| Sync | 080 | Только прием | CiA 301 |
| Авария | 080 + NodeID | Передача | CiA 301 |
| TimeStamp | 100 | Только прием | CiA 301 |
| PDO | 180 + NodeID. 200 + NodeID. 280 + NodeID. 300 + NodeID. 380 + NodeID. 400 + NodeID. 480 + NodeID. 500 + NodeID | 1. Передать PDO. 1. Получить PDO. 2. Передать PDO. 2. Получить PDO. 3. Передать PDO. 3. Получить PDO. 4. Передать PDO. 4. Прием PDO | CiA 301 |
| SDO | 580 + NodeID. 600 + NodeID | Передача. Прием | CiA 301 |
| Мониторинг узла NMT (защита узла / сердцебиение) | 700 + NodeID | Передача | CiA 301 |
| LSS | 7E4. 7E5 | Передача. Прием | CiA 305 |
При обмене сообщениями между узлами CANopen используются разные типы моделей связи.
В отношениях главный / подчиненный один узел CANopen назначается в качестве главного, который отправляет или запрашивает данные у подчиненных. Протокол NMT является примером модели связи ведущий / ведомый.
A клиент / сервер отношения реализованы в протоколе SDO, где клиент SDO отправляет данные (индекс словаря объектов и субиндекс) на сервер SDO, который отвечает одним или несколькими пакетами SDO, содержащими запрошенные данные ( содержимое объектного словаря по данному индексу). Модель
A производитель / потребитель используется в протоколах Heartbeat и Node Guarding. В модели выталкивания производитель / потребитель производитель отправляет данные потребителю без специального запроса, тогда как в модели выталкивания потребитель должен запрашивать данные у производителя.
Протоколы NMT используются для выдачи команд изменения конечного автомата (например, для запуска и остановки устройств), обнаружения удаленных загрузок устройств и условия ошибки.
Протокол управления модулем используется мастером NMT для изменения состояния устройств. COB-ID CAN-кадра этого протокола всегда равен 0, что означает, что он имеет код функции 0 и идентификатор узла 0, что означает, что каждый узел в сети будет обрабатывать это сообщение. Фактический идентификатор узла, для которого предназначена команда, дается в части данных сообщения (во втором байте). Это также может быть 0, что означает, что все устройства на шине должны перейти в указанное состояние.
| COB-ID | Байт данных 0 | Байт данных 1 |
|---|---|---|
| 0x000 | Запрошенное состояние | Адресный узел |
| Код команды NMT | Значение |
|---|---|
| 0x01 | Перейти в «рабочий» |
| 0x02 | Перейти в «остановлено» |
| 0x80 | Перейти в ' предоперационный ' |
| 0x81 | Перейти к «сбросу узла» |
| 0x82 | Перейти к «сбросу связи» |
Используется протокол Heartbeat для мониторинга узлов в сети и проверки их работоспособности. Производитель пульса (обычно ведомое устройство) периодически отправляет сообщение с двоичным функциональным кодом 1110 и своим идентификатором узла (COB-ID = 0x700 + идентификатор узла). Часть кадра с данными содержит байт, указывающий состояние узла. Эти сообщения читает потребитель пульса. Если сообщения не приходят в течение определенного периода времени (определенного в объектном словаре устройств), потребитель может предпринять действия, например, сбросить устройство или указать ошибку. Формат кадра:
| COB-ID | Байт данных 0 |
|---|---|
| 0x700 + идентификатор узла | Состояние |
| Код состояния NMT | Представленное состояние |
|---|---|
| 0x00 | Загрузка (инициализация) |
| 0x04 | Остановлено |
| 0x05 | В рабочем состоянии |
| 0x7f | Предварительно в работе |
Устройства CANopen должны автоматически переходить из состояния Initializing в Pre-Operational во время загрузки. Когда этот переход выполняется, на шину отправляется одно контрольное сообщение. Это протокол загрузки. .
Протокол ответа / ответа (модель вытягивания), называемый охраной узла, существует для мониторинга подчиненного устройства.
Протокол SDO используется для настройки и чтения значений из объектного словаря удаленного устройства. Устройство, к объектному словарю которого осуществляется доступ, является сервером SDO, а устройство, обращающимся к удаленному устройству, является клиентом SDO. Связь всегда инициируется SDO-клиентом. В терминологии CANopen связь просматривается с сервера SDO, так что чтение из объектного словаря приводит к загрузке SDO, а запись в статью словаря - это загрузка SDO.
Поскольку значения словаря объектов могут быть больше восьми байтов, установленных для кадра CAN, протокол SDO реализует сегментацию и десегментацию более длинных сообщений. Собственно, таких протоколов два: загрузка / выгрузка SDO и загрузка / выгрузка блока SDO. Передача блоков SDO - это новое дополнение к стандарту, которое позволяет передавать большие объемы данных с немного меньшими издержками протокола.
COB-ID соответствующих сообщений передачи SDO от клиента к серверу и от сервера к клиенту могут быть установлены в словаре объектов. В объектном словаре по адресам 0x1200 - 0x127F можно настроить до 128 серверов SDO. Точно так же клиентские соединения SDO устройства можно настроить с помощью переменных 0x1280 - 0x12FF. Однако предопределенный набор соединений определяет канал SDO, который можно использовать даже сразу после загрузки (в предоперационном состоянии) для настройки устройства. COB-ID этого канала: 0x600 + идентификатор узла для приема и 0x580 + идентификатор узла для передачи.
Чтобы инициировать загрузку, SDO-клиент отправляет следующие данные в CAN-сообщении с COB-ID «получения» SDO-канала.
| Номер байта: | Байт 1 | Байт 2-3 | Байт 4 | Байт 5-8 | ||||
|---|---|---|---|---|---|---|---|---|
| Длина: | 3 бита | 1 бит | 2 бита | 1 бит | 1 бит | 2 байта | 1 байт | 4 байта |
| Значение: | ccs = 1 | зарезервировано (= 0) | n | e | s | индекс | субиндекс | data |
Протокол объекта данных процесса используется для обработки данных в реальном времени между различными узлами. Вы можете передавать до 8 байтов (64 бит) данных на один PDO с устройства или на устройство. Один PDO может содержать несколько записей словаря объектов, а объекты в одном PDO настраиваются с помощью сопоставления и записей словаря объектов параметров.
Есть два типа PDO: передаваемые и принимаемые PDO (TPDO и RPDO). Первый предназначен для данных, поступающих с устройства (устройство является производителем данных), а второй - для данных, поступающих на устройство (устройство является потребителем данных); то есть с помощью RPDO вы можете отправлять данные на устройство, а с помощью TPDO вы можете читать данные с устройства. В предопределенном наборе соединений доступны идентификаторы для четырех (4) TPDO и четырех (4) RPDO. В конфигурации возможно 512 PDO.
PDO можно отправлять синхронно или асинхронно. Синхронные PDO отправляются после сообщения SYNC, тогда как асинхронные сообщения отправляются после внутреннего или внешнего триггера. Например, вы можете сделать запрос к устройству на передачу TPDO, который содержит необходимые вам данные, отправив пустой TPDO с флагом RTR (если устройство настроено для приема запросов TPDO).
С помощью RPDO вы можете, например, запустить два устройства одновременно. Вам нужно только сопоставить один и тот же RPDO с двумя или более разными устройствами и убедиться, что эти RPDO сопоставлены с одним и тем же COB-ID.
Sync-Producer предоставляет сигнал синхронизации для Sync-Consumer. Когда Sync-Consumer получает сигнал, он начинает выполнять свои синхронные задачи.
В общем, фиксация времени передачи синхронных сообщений PDO в сочетании с периодичностью передачи объекта синхронизации гарантирует, что сенсорные устройства могут организовать выборку переменных процесса и что исполнительные устройства могут применять свое срабатывание в скоординированном мода.
Идентификатор объекта синхронизации доступен по индексу 1005h.
Обычно объект отметки времени представляет время в виде 6-байтового поля: счетчик миллисекунд после полуночи (не более 27 бит, хранящихся в 32-битное поле) и 16-битное количество дней без знака с 1 января 1984 г. (7 июня 2163 г. оно будет переполнено.)
Для некоторых критичных по времени приложений, особенно в больших сетях с пониженной скоростью передачи, требуется очень точная синхронизация; может потребоваться синхронизировать локальные часы с точностью порядка микросекунд. Это достигается за счет использования дополнительного протокола синхронизации с высоким разрешением, который использует специальную форму сообщения с отметкой времени для регулировки неизбежного дрейфа локальных часов.
Отметка времени с высоким разрешением кодируется как unsigned32 с разрешением 1 микросекунда, что означает, что счетчик времени перезапускается каждые 72 минуты. Он настраивается путем отображения метки времени высокого разрешения (объект 1013h) в PDO.
Аварийные сообщения запускаются при возникновении ситуации внутренней фатальной ошибки устройства и передаются от соответствующего прикладного устройства к другим устройствам с высоким приоритетом. Это делает их подходящими для предупреждений об ошибках типа прерывания. Экстренная телеграмма может быть отправлена только один раз на «событие ошибки», т.е. экстренные сообщения не должны повторяться. До тех пор, пока на устройстве не возникает новых ошибок, дальнейшее сообщение об аварийной ситуации не отправляется. С помощью профиля связи CANopen определены коды аварийных ошибок, регистр ошибок и дополнительная информация, относящаяся к устройству, указываются в профилях устройства.
Пример трассировки связи между главным устройством и двумя подчиненными датчиками давления, настроенными для идентификатора 1 и идентификатора узла 2.
| CAN ID | ДЛИНА ДАННЫХ | ДАННЫЕ | Описание |
|---|---|---|---|
| 0x0 | 2 | 01 00 | Мастер переводит все устройства на шине в рабочий режим |
| 0x80 | 0 | Мастер отправляет сообщение SYNC, которое запускает устройства для отправки данных | |
| 0x181 | 4 | CD 82 01 00 | Узел с ID 1 (CID-0x180), считывание давления 0x0182CD (99021) паскалей |
| 0x182 | 4 | E5 83 01 00 | Узел с ID 2 (CID-0x180), давление считывания 0x0183E5 (99301) паскалей |
Электронный лист данных (EDS) - это формат файла, определенный в CiA306, который описывает поведение связи и записи словаря объектов устройства. Это позволяет таким инструментам, как сервисные инструменты, инструменты конфигурации, инструменты разработки и другие, правильно обращаться с устройствами.
Эти файлы EDS являются обязательными для прохождения теста на соответствие CiA CANopen.
С конца 2007 года в CiA311 определен новый формат на основе XML, называемый XDD. XDD соответствует стандарту ISO 15745.
.
