Подробное, простое описание протокола Modbus TCP с примерами команд
В этой статье вы узнаете о протоколе Modbus TCP, который является развитием протокола Modbus RTU. Англоязычная версия статьи доступна на ipc2u.com.
Оглавление:
Куда посылать команду Modbus TCP?
В сети Ethernet адресом устройства является его IP-адрес. Обычно устройства находятся в одной подсети, где IP адреса отличаются последними цифрами 192.168.1.20 при использовании самой распространённой маски подсети 255.255.255.0.
Интерфейсом является сеть Ethernet, протоколом передачи данных – TCP/IP.
Используемый TCP-порт: 502.
Наверх к оглавлению
Описание протокола Modbus TCP
Команда Modbus TCP состоит из части сообщения Modbus RTU и специального заголовка.
О Modbus RTU написано в этой статье.
Из сообщения Modbus RTU удаляется SlaveID адрес в начале и CRC контрольная сумма в конце, что образует PDU, Protocol Data Unit.
Ниже приведен пример запроса Modbus RTU для получения значения AO аналогового выхода (holding registers) из регистров от #40108 до 40110 с адресом устройства 17.
11 03 006B 0003 7687
| 11 | Адрес устройства SlaveID (17 = 11 hex) |
| 03 | Функциональный код Function Code (читаем Analog Output Holding Registers) |
| 006B | Адрес первого регистра (40108-40001 = 107 =6B hex) |
| 0003 | Количество требуемых регистров (чтение 3-х регистров с 40108 по 40110) |
| 7687 | Контрольная сумма CRC |
Отбрасываем адрес устройства SlaveID и контрольную сумму CRC и получаем PDU:
03 006B 0003
К началу получившегося сообщения PDU добавляется новый 7-байтовый заголовок, который называется MBAP Header (Modbus Application Header). Этот заголовок имеет следующие данные:
Transaction Identifier (Идентификатор транзакции): 2 байта устанавливаются Master, чтобы однозначно идентифицировать каждый запрос.
Может быть любыми. Эти байты повторятся устройством Slave в ответе, поскольку ответы устройства Slave не всегда могут быть получены в том же порядке, что и запросы.
Protocol Identifier (Идентификатор протокола): 2 байта устанавливаются Master, всегда будут = 00 00, что соответствует протоколу Modbus.
Length (Длина): 2 байта устанавливаются Master, идентифицирующие число байтов в сообщении, которые следуют далее. Считается от Unit Identifier до конца сообщения.
Unit Identifier (Идентификатор блока или адрес устройства): 1 байт устанавливается Master. Повторяется устройством Slave для однозначной идентификации устройства Slave.
Итого получаем:
| Modbus RTU | Slave ID | Запрос | CRC |
|---|---|---|---|
| Modbus RTU | 11 | 03 006B 0003 | 7687 |
| Modbus TCP | 0001 0000 0006 11 | 03 006B 0003 | |
| Modbus TCP | MBAP Header | PDU | |
| Modbus TCP | ADU, Application Data Unit | ||
Где:
| 0001 | Идентификатор транзакции | Transaction Identifier |
| 0000 | Идентификатор протокола | Protocol Identifier |
| 0006 | Длина (6 байтов идут следом) | Message Length |
| 11 | Адрес устройства (17 = 11 hex) | Unit Identifier |
| 03 | Функциональный код (читаем Analog Output Holding Registers) | Function Code |
| 006B | Адрес первого регистра (40108-40001 = 107 =6B hex) | Data Address of the first register |
| 0003 | Количество требуемых регистров (чтение 3-х регистров с 40108 по 40110) | The total number of registers |
В ответе от Modbus TCP Slave устройства мы получим:
0001 0000 0009 11 03 06 022B 0064 007F
Где:
| 0001 | Идентификатор транзакции | Transaction Identifier |
| 0000 | Идентификатор протокола | Protocol Identifier |
| 0009 | Длина (9 байтов идут следом) | Message Length |
| 11 | Адрес устройства (17 = 11 hex) | Unit Identifier |
| 03 | Функциональный код (читаем Analog Output Holding Registers) | Function Code |
| 06 | Byte Count | |
| 02 | Значение старшего разряда регистра (02 hex) | Register value Hi (AO0) |
| 2B | Значение младшего разряда регистра (2B hex) | Register value Lo (AO0) |
| 00 | Значение старшего разряда регистра (00 hex) | Register value Hi (AO1) |
| 64 | Значение младшего разряда регистра (64 hex) | Register value Lo (AO1) |
| 00 | Значение старшего разряда регистра (00 hex) | Register value Hi (AO2) |
| 7F | Значение младшего разряда регистра (7F hex) | Register value Lo (AO2) |
Регистр аналогового выхода AO0 имеет значение 02 2B HEX или 555 в десятичной системе.
Регистр аналогового выхода АО1 имеет значение 00 64 HEX или 100 в десятичной системе.
Регистр аналогового выхода АО2 имеет значение 00 7F HEX или 127 в десятичной системе.
Наверх к оглавлению
Типы команд Modbus TCP
Приведем таблицу с кодами функций чтения и записи регистров Modbus TCP.
| Код функции | Что делает функция | Тип значения | Тип доступа | |
|---|---|---|---|---|
| 01 (0x01) | Чтение DO | Read Coil Status | Дискретное | Чтение |
| 02 (0x02) | Чтение DI | Read Input Status | Дискретное | Чтение |
| 03 (0x03) | Чтение AO | Read Holding Registers | 16 битное | Чтение |
| 04 (0x04) | Чтение AI | Read Input Registers | 16 битное | Чтение |
| 05 (0x05) | Запись одного DO | Force Single Coil | Дискретное | Запись |
| 06 (0x06) | Запись одного AO | 16 битное | Запись | |
| 15 (0x0F) | Запись нескольких DO | Force Multiple Coils | Дискретное | Запись |
| 16 (0x10) | Запись нескольких AO | Preset Multiple Registers | 16 битное | Запись |
Наверх к оглавлению
Как послать команду Modbus TCP на чтение дискретного вывода? Команда 0x01
Эта команда используется для чтения значений дискретных выходов DO.
В запросе PDU задается начальный адрес первого регистра DO и последующее количество необходимых значений DO. В PDU значения DO адресуются, начиная с нуля.
Значения DO в ответе находятся в одном байте и соответствуют значению битов.
Значения битов определяются как 1 = ON и 0 = OFF.
Младший бит первого байта данных содержит значение DO адрес которого указывался в запросе. Остальные значения DO следуют по нарастающей к старшему значению байта. Т.е. справа налево.
Если запрашивалось меньше восьми значений DO, то оставшиеся биты в ответе будут заполнены нулями (в направлении от младшего к старшему байту). Поле Byte Count Количество байт далее указывает количество полных байтов данных в ответе.
| Байт | Запрос | Байт | Ответ |
|---|---|---|---|
| (Hex) | Название поля | (Hex) | Название поля |
| 01 | Идентификатор транзакции | 01 | Идентификатор транзакции |
| 02 | 02 | ||
| 00 | Идентификатор протокола | 00 | Идентификатор протокола |
| 00 | 00 | ||
| 00 | Длина сообщения | 00 | Длина сообщения |
| 06 | 04 | ||
| 01 | Адрес устройства | 01 | Адрес устройства |
| 01 | Функциональный код | 01 | Функциональный код |
| 00 | Адрес первого регистра Hi байт | 01 | Количество байт далее |
| 00 | Адрес первого регистра Lo байт | 02 | Значение регистра DO 0-1 |
| 00 | Количество регистров Hi байт | ||
| 02 | Количество регистров Lo байт | ||
Состояния выходов DO0-1 показаны как значения байта 02 hex, или в двоичной системе 0000 0010.
Значение DO1 будет вторым справа, а значение DO0 будет первым справа (младший бит).
Шесть остальных битов заполнены нулями до полного байта, т.к. их не запрашивали.
| Каналы | – | – | – | – | – | – | DO 1 | DO 0 |
| Биты | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
| Hex | 02 | |||||||
Модули с дискретным выводом: ioLogik E1211, ET-7060, ADAM-6060
Наверх к оглавлению
Как послать команду Modbus TCP на чтение дискретного ввода? Команда 0x02
Эта команда используется для чтения значений дискретных входов DI.
Запрос и ответ для DI похож на запрос для DO.
| Байт | Запрос | Байт | Ответ |
|---|---|---|---|
| (Hex) | Название поля | (Hex) | Название поля |
| 01 | Идентификатор транзакции | 01 | Идентификатор транзакции |
| 02 | 02 | ||
| 00 | Идентификатор протокола | 00 | Идентификатор протокола |
| 00 | 00 | ||
| 00 | Длина сообщения | 00 | Длина сообщения |
| 06 | 04 | ||
| 01 | Адрес устройства | 01 | Адрес устройства |
| 02 | Функциональный код | 02 | Функциональный код |
| 00 | Адрес первого регистра Hi байт | 01 | Количество байт далее |
| 00 | Адрес первого регистра Lo байт | 03 | Значение регистра DI 0-1 |
| 00 | Количество регистров Hi байт | ||
| 02 | Количество регистров Lo байт | ||
Состояния выходов DI 0-1 показаны как значения байта 03 hex, или в двоичной системе 0000 0011.
Значение DI1 будет вторым справа, а значение DI0 будет первым справа (младший бит).
Шесть остальных битов заполнены нулями.
Модули с дискретным вводом: ioLogik E1210, ET-7053, ADAM-6050
Наверх к оглавлению
Как послать команду Modbus TCP на чтение аналогового вывода? Команда 0x03
Эта команда используется для чтения значений аналоговых выходов AO.
| Байт | Запрос | Байт | Ответ |
|---|---|---|---|
| (Hex) | Название поля | (Hex) | Название поля |
| 01 | Идентификатор транзакции | 01 | Идентификатор транзакции |
| 02 | 02 | ||
| 00 | Идентификатор протокола | 00 | Идентификатор протокола |
| 00 | 00 | ||
| 00 | Длина сообщения | 00 | Длина сообщения |
| 06 | 07 | ||
| 01 | Адрес устройства | 01 | Адрес устройства |
| 03 | Функциональный код | 03 | Функциональный код |
| 00 | Адрес первого регистра Hi байт | 04 | Количество байт далее |
| 00 | Адрес первого регистра Lo байт | 02 | Значение регистра Hi (AO0) |
| 00 | Количество регистров Hi байт | 2B | Значение регистра Lo (AO0) |
| 02 | Количество регистров Lo байт | 00 | Значение регистра Hi (AO1) |
| 64 | Значение регистра Lo (AO1) | ||
Состояния выхода AO0 показаны как значения байта 02 2B hex, или в десятичной системе 555.
Состояния выхода AO1 показаны как значения байта 00 64 hex, или в десятичной системе 100.
Модули с дискретным вводом: ioLogik E1210, ET-7053, ADAM-6050
Наверх к оглавлению
Как послать команду Modbus TCP на чтение аналогового ввода? Команда 0x04
Эта команда используется для чтения значений аналоговых входов AI.
| Байт | Запрос | Байт | Ответ |
|---|---|---|---|
| (Hex) | Название поля | (Hex) | Название поля |
| 01 | Идентификатор транзакции | 01 | Идентификатор транзакции |
| 02 | 02 | ||
| 00 | Идентификатор протокола | 00 | Идентификатор протокола |
| 00 | 00 | ||
| 00 | Длина сообщения | 00 | Длина сообщения |
| 06 | 07 | ||
| 01 | Адрес устройства | 01 | Адрес устройства |
| 04 | Функциональный код | 04 | Функциональный код |
| 00 | Адрес первого регистра Hi байт | 04 | Количество байт далее |
| 00 | Адрес первого регистра Lo байт | 00 | Значение регистра Hi (AI0) |
| 00 | Количество регистров Hi байт | 0A | Значение регистра Lo (AI0) |
| 02 | Количество регистров Lo байт | 00 | Значение регистра Hi (AI1) |
| 64 | Значение регистра Lo (AI1) | ||
Состояния выхода AI0 показаны как значения байта 00 0A hex, или в десятичной системе 10.
Состояния выхода AI1 показаны как значения байта 00 64 hex, или в десятичной системе 100.
Модули с аналоговым вводом: ioLogik E1240, ET-7017-10, ADAM-6217
Наверх к оглавлению
Как послать команду Modbus TCP на запись дискретного вывода? Команда 0x05
Эта команда используется для записи одного значения дискретного выхода DO.
Значение FF 00 hex устанавливает выход в состояние включен ON.
Значение 00 00 hex устанавливает выход в состояние выключен OFF.
Все остальные значения недопустимы и не будут влиять на состояние выхода.
Нормальный ответ на такой запрос – это эхо (повтор запроса в ответе), возвращается после того, как состояние DO было изменено.
| Байт | Запрос | Байт | Ответ |
|---|---|---|---|
| (Hex) | Название поля | (Hex) | Название поля |
| 01 | Идентификатор транзакции | 01 | Идентификатор транзакции |
| 02 | 02 | ||
| 00 | Идентификатор протокола | 00 | Идентификатор протокола |
| 00 | 00 | ||
| 00 | Длина сообщения | 00 | Длина сообщения |
| 06 | 06 | ||
| 01 | Адрес устройства | 01 | Адрес устройства |
| 05 | Функциональный код | 05 | Функциональный код |
| 00 | Адрес регистра Hi байт | 00 | Адрес регистра Hi байт |
| 01 | Адрес регистра Lo байт | 01 | Адрес регистра Lo байт |
| FF | Значение Hi байт | FF | Значение Hi байт |
| 00 | Значение Lo байт | 00 | Значение Lo байт |
Состояние выхода DO1 поменялось с выключен OFF на включен ON.
Модули с дискретным выводом: ioLogik E1211, ET-7060, ADAM-6060
Наверх к оглавлению
Как послать команду Modbus TCP на запись аналогового вывода? Команда 0x06
Эта команда используется для записи одного значения аналогового выхода AO.
| Байт | Запрос | Байт | Ответ |
|---|---|---|---|
| (Hex) | Название поля | (Hex) | Название поля |
| 01 | Идентификатор транзакции | 01 | Идентификатор транзакции |
| 02 | 02 | ||
| 00 | Идентификатор протокола | 00 | Идентификатор протокола |
| 00 | 00 | ||
| 00 | Длина сообщения | 00 | Длина сообщения |
| 06 | 06 | ||
| 01 | Адрес устройства | 01 | Адрес устройства |
| 06 | Функциональный код | 06 | Функциональный код |
| 00 | Адрес регистра Hi байт | 00 | Адрес регистра Hi байт |
| 01 | Адрес регистра Lo байт | 01 | Адрес регистра Lo байт |
| 55 | Значение Hi байт | 55 | Значение Hi байт |
| FF | Значение Lo байт | FF | Значение Lo байт |
Состояние выхода AO0 поменялось на 55 FF hex, или в десятичной системе 22015.
Модули с аналоговым выводом: ioLogik E1241, ET-7028, ADAM-6224
Наверх к оглавлению
Как послать команду Modbus TCP на запись нескольких дискретных выводов? Команда 0x0F
Эта команда используется для записи нескольких значений дискретного выхода DO.
| Байт | Запрос | Байт | Ответ |
|---|---|---|---|
| (Hex) | Название поля | (Hex) | Название поля |
| 01 | Идентификатор транзакции | 01 | Идентификатор транзакции |
| 02 | 02 | ||
| 00 | Идентификатор протокола | 00 | Идентификатор протокола |
| 00 | 00 | ||
| 00 | Длина сообщения | 00 | Длина сообщения |
| 08 | 06 | ||
| 01 | Адрес устройства | 01 | Адрес устройства |
| 0F | Функциональный код | 0F | Функциональный код |
| 00 | Адрес первого регистра Hi байт | 00 | Адрес первого регистра Hi байт |
| 00 | Адрес первого регистра Lo байт | 00 | Адрес первого регистра Lo байт |
| 00 | Количество регистров Hi байт | 00 | Кол-во записанных рег. Hi байт |
| 02 | Количество регистров Lo байт | 02 | Кол-во записанных рег. Lo байт |
| 01 | Количество байт далее | ||
| 02 | Значение байт | ||
Состояние выхода DO1 поменялось с выключен OFF на включен ON.
Состояние выхода DO0 осталось выключен OFF.
Модули с дискретным выводом: ioLogik E1211, ET-7060, ADAM-6060
Наверх к оглавлению
Как послать команду Modbus TCP на запись нескольких аналоговых выводов? Команда 0x10
Эта команда используется для записи нескольких значений аналогового выхода AO.
| Байт | Запрос | Байт | Ответ |
|---|---|---|---|
| (Hex) | Название поля | (Hex) | Название поля |
| 01 | Идентификатор транзакции | 01 | Идентификатор транзакции |
| 02 | 02 | ||
| 00 | Идентификатор протокола | 00 | Идентификатор протокола |
| 00 | 00 | ||
| 00 | Длина сообщения | 00 | Длина сообщения |
| 0B | 06 | ||
| 01 | Адрес устройства | 01 | Адрес устройства |
| 10 | Функциональный код | 10 | Функциональный код |
| 00 | Адрес первого регистра Hi байт | 00 | Адрес первого регистра Hi байт |
| 00 | Адрес первого регистра Lo байт | 00 | Адрес первого регистра Lo байт |
| 00 | Количество регистров Hi байт | 00 | Кол-во записанных рег. Hi байт |
| 02 | Количество регистров Lo байт | 02 | Кол-во записанных рег. Lo байт |
| 04 | Количество байт далее | ||
| 00 | Значение Hi AO0 байт | ||
| 0A | Значение Lo AO0 байт | ||
| 01 | Значение Hi AO1 байт | ||
| 02 | Значение Lo AO1 байт | ||
Состояние выхода AO0 поменялось на 00 0A hex, или в десятичной системе 10.
Состояние выхода AO1 поменялось на 01 02 hex, или в десятичной системе 258.
Модули с аналоговым выводом: ioLogik E1241, ET-7028, ADAM-6224
Наверх к оглавлению
Ошибки запроса Modbus TCP
Если после получения запроса устройство не может обработать его, то будет отослан ответ с кодом ошибки.
Ответ будет содержать измененный Функциональный код, его старший бит будет равен 1.
Пример:
| Было | Стало |
|---|---|
| Функциональный код в запросе | Функциональный код ошибки в ответе |
| 01 (01 hex) 0000 0001 | 129 (81 hex) 1000 0001 |
| 02 (02 hex) 0000 0010 | 130 (82 hex) 1000 0010 |
| 03 (03 hex) 0000 0011 | 131 (83 hex) 1000 0011 |
| 04 (04 hex) 0000 0100 | 132 (84 hex) 1000 0100 |
| 05 (05 hex) 0000 0101 | 133 (85 hex) 1000 0101 |
| 06 (06 hex) 0000 0110 | 134 (86 hex) 1000 0110 |
| 15 (0F hex) 0000 1111 | 143 (8F hex) 1000 1111 |
| 16 (10 hex) 0001 0000 | 144 (90 hex) 1001 0000 |
Пример запроса и ответ с ошибкой:
| Байт | Запрос | Байт | Ответ |
|---|---|---|---|
| (Hex) | Название поля | (Hex) | Название поля |
| 01 | Идентификатор транзакции | 01 | Идентификатор транзакции |
| 02 | 02 | ||
| 00 | Идентификатор протокола | 00 | Идентификатор протокола |
| 00 | 00 | ||
| 00 | Длина сообщения | 00 | Длина сообщения |
| 06 | 03 | ||
| 0A | Адрес устройства | 0A | Адрес устройства |
| 01 | Функциональный код | 81 | Функциональный код с измененным битом |
| 04 | Адрес первого регистра Hi байт | 02 | Код ошибки |
| A1 | Адрес первого регистра Lo байт | ||
| 00 | Количество регистров Hi байт | ||
| 01 | Количество регистров Lo байт | ||
Расшифровка кодов ошибок
| 01 | Принятый код функции не может быть обработан. |
| 02 | Адрес данных, указанный в запросе, недоступен. |
| 03 | Значение, содержащееся в поле данных запроса, является недопустимой величиной. |
| 04 | Невосстанавливаемая ошибка имела место, пока ведомое устройство пыталось выполнить затребованное действие. |
| 05 | Ведомое устройство приняло запрос и обрабатывает его, но это требует много времени. Этот ответ предохраняет ведущее устройство от генерации ошибки тайм-аута. |
| 06 | Ведомое устройство занято обработкой команды. Ведущее устройство должно повторить сообщение позже, когда ведомое освободится. |
| 07 | Ведомое устройство не может выполнить программную функцию, заданную в запросе. Этот код возвращается для не успешного программного запроса, использующего функции с номерами 13 или 14. Ведущее устройство должно запросить диагностическую информацию или информацию об ошибках от ведомого. |
| 08 | Ведомое устройство при чтении расширенной памяти обнаружило ошибку паритета. Ведущее устройство может повторить запрос, но обычно в таких случаях требуется ремонт. |
| 10 (0A hex) | Шлюз неправильно настроен или перегружен запросами. |
| 11 (0B hex) | Slave устройства нет в сети или от него нет ответа. |
Наверх к оглавлению
Программы для работы с протоколом Modbus TCP
Ниже представлены программы, которые помогут легко взаимодействовать с устройствами Modbus TCP.
Modbus Master Tool с поддержкой Modbus RTU, ASCII, TCP. Скачать
Modbus TCP client с поддержкой Modbus TCP. Скачать
Наверх к оглавлению
Оборудование с поддержкой протокола Modbus TCP
Наверх к оглавлению
За более подробной информацией обращайтесь к специалистам IPC2U по телефону: +7 (495) 232 0207 или по e-mail: [email protected]
PROFIBUS vs PROFINET
PROFIBUS и PROFINET – два протокола, широко распространенные в сфере автоматизации.
PROFIBUS – протокол с классической шинной топологией, PROFINET – стандарт промышленной сети Ethernet с дополнительными возможностями, которые позволяют сделать обмен данными более быстрым и гибким. Далее будут подробно рассмотрены их сходства и различия и изложена стратегия бесшовного перехода от PROFIBUS к PROFINET.
Основные характеристики протоколов PROFIBUS / PROFINET:
| PROFIBUS | PROFINET | |
| организация | PROFIBUS & PROFINET International | |
| конфигурационный файл | GSD (General Station Description) | |
| профили | PROFIsafe, PROFIenergy, PROFIdrive | |
| физический уровень | RS-485 | Ethernet |
| скорость | 12Mбит/с | 1Гбит/с или 100Mбит/с |
| max размер блока данных | 244 байт | 1440 байт |
| Количество устройств | 126 | неограниченно |
| Сеть | master/slave | provider/consumer |
| беспроводная среда | возможна | Wi-Fi, Bluetooth |
| Детерминированный режим | есть | есть |
| M2M-взаимодействие | нет | есть |
| Топология | шина | любая |
Оба протокола были созданы при участии компании Siemens AG и поддерживаются консорциумом PROFIBUS & PROFINET International (PI).
Конфигурация устройств описывается GSD-файлом (General Station Description) в виде ASCII-файла для PROFIBUS и XML-файла для PROFINET соответственно. У PROFIBUS и PROFINET также есть общие профили для определенных устройств или приложений, например:
- PROFIsafe: профиль функциональной безопасности
- PROFIenergy: профиль организации электроснабжения
- PROFIdrive: профиль управления приводами
Протокол PROFIBUS был разработан в 1989 году компанией Siemens для собственных промышленных контроллеров Simatic. В глобальном смысле это был качественный переход от аналоговых сигналов 4-20 мА к цифровым промышленным сетям (RS-485), на базе которых были разработаны несколько совместимых друг с другом спецификаций Profibus PA, Profibus DP и Profibus FMS. В настоящее время наблюдается качественный переход от RS-485 к быстро распространяющимся промышленным стандартам Ethernet. PROFINET, используя коммерческий успех Ethernet, в какой-то степени «предвидел будущее» оценив скоростные характеристики Ethernet (100 Мбит/с, сегодня может работать на скоростях Gigabit Ethernet и выше).
Протокол Ethernet характеризуется высокой пропускной способностью, большим размером передаваемого пакета данных и неограниченным адресным пространством (ограничение только пределами производительности контроллера).
Скорость PROFINET увеличилась благодаря модели provider/consumer (поставщик / потребитель) и дуплексному характеру Ethernet. В модели поставщик/потребитель любой узел сети взаимодействует, когда ему это необходимо, и, поскольку сеть Ethernet – это сеть с коммутацией, в ней нет конфликтов. Полный дуплекс означает, что ведомые устройства могут отправлять и получать данные от Master независимо от других ведомых устройств. В сети PROFIBUS нет коллизий благодаря использованию модели master/slave (ведущий/ведомый): эта связь эффективна, но медленна. Ведущее устройство руководит сетью, ведомые устройства отвечают только тогда, когда их опрашивает Master в порядке общей очереди.
PROFIBUS может передавать сообщения по беспроводной сети, что часто требует специализированных средств от того же производителя.
PROFINET, будучи стандартом, основанным на Ethernet, использует беспроводные спецификации IEEE 802.11, 15.1.
На многих предприятиях используются шлюзы для перехода из локальных сетей Ethernet в сеть PROFIBUS, либо из PROFINET в PROFIBUS. Пример подобного шлюза изображен на рис. 1
Но так как использование PROFINET является качественно новым подходом, позволяющим связать в единую сеть реального времени практически все устройства предприятия, возникает проблема организации данной связи. Для комплексного решения этой задачи рекомендуется использовать мощный прокси-сервер. Прокси-сервер используется как шлюз для перевода данных одного протокола в другой, при этом поддержка протоколов может быть очень обширной. Например возможность работы сразу с PROFIBUS DP, PROFIBUS РА, AS-интерфейса, IO-Link, сетей DeviceNet, Foundation Fieldbus, CANopen, Modbus, HART и т.
д. Например, IO-Link и AS-интерфейс позволяют контактировать с интеллектуальными устройствами минуя Ethernet- порт.Во многих случаях, когда требуется установить связь между сетями fieldbus и Ethernet, прокси-сервер позволяет сделать эту связь бесшовной. Ниже представлена графическая схема магистральной шины PROFINET, прокси-сервера и PROFIBUS-устройств.
Рис 2. Прокси-сервер между PROFINET и PROFIBUS
В сети PROFIBUS данные от ведомого устройства проходят в сеть PROFINET через прокси-сервер (Master в модели ведущий/ведомый по отношению к PROFIBUS-устройствам). Прокси-сервер может быть выполнен, в том числе, для взрывоопасных сред.
Современные стандарты
PI (PROFIBUS & PROFINET International) ежегодно проводит аудит новых узлов. По итогам 2016 года, к устройствам с PROFIBUS и PROFINET добавилось 2,4 м и 3,6 млн. устройств соответственно. 2016 год стал первым годом, в котором PROFINET-устройств было продано больше, чем устройств стандарта PROFIBUS, общее количество которых в мире составляет более 56,1 млн.
Рис 3. Количество устройств, присоединенных к PROFINET
Рис 4. Процентное соотношение PROFINET и PROFIBUS
Резюме
Существует достаточно различий между PROFIBUS и PROFINET, например, в пропускной способности, возможности использования протокола TCP/IP. Но, несмотря на то, что распространение PROFINET в настоящий момент опережает PROFIBUS, этот стандарт еще долго будет использоваться во многих областях промышленности, транспорте, энергетике, где задачи управления обладают приоритетом над скоростью и гибкостью. В конце концов, переход промышленных систем от сетей PROFIBUS на новые технологии, такие как PROFINET, должен проводиться поэтапно, согласованно с задачами непрерывного управления производством. Существуют разные стратегии перехода, но в целом с помощью технологий консорциума PI обеспечена плавная и экономичная миграция в современный и гибкий стандарт путем интеграции последовательной шины fieldbus через прокси-сервер в PROFINET.
CANopen — НПФ ВЕКТОР
На данной странице представлено программное обеспечение, разработанное фирмой ООО «НПФ Вектор». ПО RTCON, COODEdit, ScopeOpenGL и драйвер CANopen работают совместно и представляют комплектное решение для настройки и отладки низкоуровневых систем управления на базе микроконтроллеров. Рекомендуется ознакомиться с вводной обзорной статьей по данным продуктам — «Способы отладки встраиваемых микропроцессорных систем в преобразовательной технике» или с аналогичной в нашем блоге на ресурсе habr.com.
RTCON
Управляющий интерфейс RTCON – это набор программных средств, позволяющих осуществлять мониторинг, параметрирование CANopen совместимых устройств посредством ПК, подключаемого через физический интерфейс CAN.
ПОДРОБНЕЕ
ScopeOpenGL
Программа для осциллографирования, визуализации и анализа процессов сложного объекта управления, включающего в себя от одного до нескольких десятков микропроцессорных устройств, объединенных CAN-сетью.
ПОДРОБНЕЕ
CoodEdit
Программа для редактирования словаря объектов CANopen. Программа позволяет управлять объектами словаря полностью в графическом режиме, а затем произвести генерирование кода со словарем объектов для микроконтроллера. Программа предназначена только для драйвера CANopen разработки ООО «НПФ Вектор».
ПОДРОБНЕЕ
Драйвер CANopen
Программа для микроконтроллера, реализующая протокол CANopen на основе интерфейса связи CAN. Драйвер ООО «НПФ ВЕКТОР» имеет расширения по сравнению со стандартным CANopen, однако они организованы в рамках протокола CANopen и являются «надстройками», не нарушая стандарт.
ПОДРОБНЕЕ
Обзор предлагаемых решений в виде лекции подготовлен одним из наших сотрудников и доступен в трех частях на следующих видео. Первое видео — введение с обзором предлагаемых решений. На следующих двух видео проводится лабораторная работа по настройке ПИ-регуляторов тока в электроприводе и запуску векторной бездатчиковой системы управления: демонстрируется работа программного обеспечения RTCON и CoodEdit.
CANopen для отладки систем управления. Часть 1: Введение
CANopen для отладки систем управления. Часть 2: Настройка регуляторов тока
CANopen для отладки систем управления. Часть 3: Запуск векторного управления
Объяснение CANopen – простое введение (2020)
Требуется простое и практичное введение в CANopen?
В этом руководстве мы познакомим вас с основами протокола CANopen, в т.ч. словарь объектов, службы, SDO, PDO и ведущие / ведомые узлы.
Примечание: CANopen может показаться сложным – так что это руководство является визуальным введением в терминах непрофессионала.
Прочтите ниже, чтобы полностью понять CANopen.
Вы также можете посмотреть наше вступительное видео о CANopen выше.
Что такое CANopen?
CANopen – это протокол связи на основе CAN.
Стандарт CANopen полезен, поскольку он обеспечивает готовую совместимость между устройствами (узлами), например, в промышленное оборудование. Кроме того, он предоставляет стандартные методы для настройка устройств – также после установки.
CANopen изначально был разработан для систем управления машинами, ориентированных на движение.
Сегодня CANopen широко используется в управлении двигателями (шаговые / серводвигатели), но также и в широком спектр других приложений:
Медицинский
Рентгеновские генераторы, инжекторы, столы для пациентов и диализные устройства
CANopen – протокол более высокого уровня
Важно понимать следующее:
CANopen – это «протокол более высокого уровня», основанный на шине CAN.
Это означает, что шина CAN (ISO 11898) служит «транспортным средством» (например, грузовиком) для сообщений CANopen (например, контейнеров).
Вы можете просматривать CANopen из 7-уровневой модели OSI, см. Ниже.
CANopen в контексте модели OSIМодель OSI – это концептуальная модель, стандартизирующая коммуникационные функции в различных коммуникационных технологиях. Нижние уровни описывают основные коммуникации (например, необработанные битовые потоки), в то время как более высокие уровни описывают такие вещи, как сегментация длинных сообщений и услуг, таких как инициирование, указание, ответ и подтверждение сообщений.
Шина CANпредставляет два нижних уровня (1: физический, 2: канал передачи данных). Это означает, что CAN просто разрешает передачу кадров с 11-битным CAN ID , удаленным бит передачи (RTR) и 64 бита данных (поля, относящиеся к протоколам более высокого уровня).
Другими словами, шина CAN играет в CANopen ту же роль, что и, например, в протокол J1939.
Как очевидно выше, CANopen реализует 7-й уровень модели OSI (приложение) через набор стандартов.В рамках этого он добавляет несколько важных концепции, которые мы подробно рассмотрим ниже.
Стоит отметить, что CANopen также может быть адаптирован к другим протоколам канального уровня, отличным от CAN (например, EtherCAT, Modbus, Powerlink).
Чтобы полностью разобраться в сравнении CAN-шины и CANopen, см. Также наше вводное руководство по CAN-шине.
CANopen FDВ этой статье мы в первую очередь сосредоточимся на CANopen, основанном на классической CAN. Однако стоит отметить, что по мере развертывания CAN FD CANopen FD может играть все более важную роль в качестве следующего поколения CANopen.Для получения дополнительной информации см. Обзор CAN в автоматизации на CANopen FD.
Шесть основных концепций CANopen
Даже если вы знакомы с CAN-шиной и, например, J1939, CANopen добавляет ряд важных новых концепций:
Коммуникационные модели
Существует 3 модели для связи устройства / узла: ведущий / ведомый, клиент / сервер и производитель / потребитель
Протоколы связи
Протоколы используются для связи, например.грамм. настройка узлов (SDO) или передача данных в реальном времени (PDO)
Устройство
Состояния
Устройство поддерживает разные состояния. «Главный» узел может изменять состояние «подчиненного» узла – например, сбросить его
Словарь объектов
Каждое устройство имеет OD с записями, которые определяют, например, конфигурация устройства. Доступ к нему можно получить через SDO
Электронный лист данных
EDS – это стандартный формат файла для записей OD, позволяющий e.грамм. сервисные инструменты для обновления устройств
Профили устройств
Стандартыописывают, например, Модули ввода / вывода (CiA 401) и управление движением (CiA 402) для независимости от производителя
На иллюстрации ниже показано, как концепции CANopen связаны друг с другом, и мы подробно рассмотрим каждую из них:
Основы связи CANopen
В сети CANopen несколько устройств должны обмениваться данными.
Например, в системе промышленной автоматизации у вас может быть рука робота с несколькими узлами серводвигателей и интерфейсом управления / узлом ПК.
Для облегчения связи существует три модели внутри CANopen, каждая из которых тесно связана с протоколами CANopen, которые мы вскоре рассмотрим. См. Краткое введение ниже:
Коммуникационные модели CANopenГлавный / Подчиненный
Один узел (например, интерфейс управления) действует как мастер приложения или хост-контроллер. Он отправляет / запрашивает данные от ведомых устройств (например, серводвигателей). Это используется, например, в диагностика или управление состоянием.В стандартных приложениях может быть от 0 до 127 ведомых устройств. Обратите внимание, что в одной сети CANopen могут использоваться разные хост-контроллеры. тот же уровень канала передачи данных.
Пример обслуживания: NMT
Клиент / Сервер
Клиент отправляет запрос данных на сервер, который отвечает запрошенными данными. Используется, например, когда мастеру приложения нужны данные от OD ведомого устройства. Чтение из сервер – это «загрузка», а запись – «загрузка» (в терминологии используется перспектива «на стороне сервера»).
Пример обслуживания: SDO
Потребитель / Производитель
Здесь узел-производитель передает данные в сеть, которые потребляются узлом-потребителем. Производитель отправляет эти данные по запросу (модель pull) или без конкретный запрос (модель push).
Пример обслуживания: Heartbeat
Как видно, модели практически идентичны, но мы различаем их для единообразия терминологии.
Рама CANopen
Чтобы понять связь CANopen, необходимо разбить CANopen CAN-фрейм :
11-битный CAN ID называется идентификатором объекта связи ( COB-ID ) и делится на две части:
По умолчанию первые 4 бита равны код функции и следующие 7 битов содержат идентификатор узла .
Чтобы понять, как работает COB-ID, давайте начнем с предопределенного распределения идентификаторов, используемых в простых сетях CANopen (см. Таблицу).
Примечание. Ниже мы будем ссылаться на идентификаторы COB-ID и идентификаторы узлов в шестнадцатеричном формате.
Как видно, COB-ID (например, 381, 581,…) связаны с услугами связи (передача PDO 3, передача SDO,…).
Таким образом, COB-ID указывает, какой узел отправляет / принимает данные и какая служба используется .
ПримерУстройство CANopen с идентификатором узла 5 будет передавать SDO через 11-битный идентификатор CAN 585 .
Это соответствует двоичному коду функции 1011 и идентификатору узла 5 (двоичный: 0000101) – см. Иллюстрацию:
Онлайн-конвертер CANopen COB-ID
Наш конвертер COB-ID позволяет быстро найти CANopen COB-ID, чтобы получить основные сведения, включаякод функции и идентификатор узла.
Протоколы / услуги связи CANopen
Ниже мы кратко опишем 7 упомянутых типов услуг, в т.ч. как они используют 8 байтов данных CAN кадра .
# 1 Управление сетью (NMT)Что это такое? Служба NMT используется для управления состоянием устройств CANopen (например, до начала работы, в рабочем состоянии, остановлено) с помощью NMT. команды (например, пуск, останов, сброс).
Как это работает? Чтобы изменить состояние, мастер NMT отправляет 2-байтовое сообщение с CAN ID 0 (т.е.е. код функции 0 и идентификатор узла 0). Все подчиненные узлы обрабатывают это сообщение. 1-й байт данных CAN содержит запрошенное состояние, а 2-й байт данных CAN содержит идентификатор целевого узла. Идентификатор узла 0 указывает на широковещательная команда.
Возможные команды включают переход в рабочий (состояние 01), в остановленный (состояние 02), предрабочий (состояние 80), а также приложение сброса (81) и сброс связь (82).
# 2 Синхронизация (SYNC)Что это? Используется сообщение SYNC e.грамм. для синхронизации считывания входов и срабатывания нескольких устройств CANopen – обычно запускается мастер приложения.
Как это работает? Мастер приложения отправляет сообщение SYNC (COB ID 080) в сеть CANopen (со счетчиком SYNC или без него). Множественный раб узлы могут быть настроены так, чтобы реагировать на SYNC и отвечать, передавая входные данные, захваченные в одно и то же время, или устанавливая выход в то же время, что и узлы, участвующие в синхронной операции.С помощью счетчика SYNC можно настроить несколько групп синхронно работающих устройств.
# 3 Emergency (EMCY)Что это? Служба экстренной помощи используется в случае, если в устройстве произошла фатальная ошибка (например, отказ датчика), что позволяет ему сообщить об этом остальная часть сети.
Как это работает? Затронутый узел отправляет одно сообщение EMCY (например, с COB-ID 085 для узла 5) в сеть с высоким приоритетом.Байты данных содержат информация об ошибке, в которой можно найти подробности.
# 4 Отметка времени (TIME) [PDO]
Что это? С помощью этой услуги связи можно распределить глобальное сетевое время. Сервис TIME содержит 6-байтовую информацию о дате и времени.
Как это работает? Мастер приложения отправляет сообщение TIME с CAN ID 100, где начальные 4 байта данных содержат время в мс после полночь и следующие 2 байта содержат количество дней, прошедших с 1 января 1984 года.
# 5 Объект данных процесса [PDO]
Что это такое? Служба PDO используется для передачи данных в реальном времени между устройствами – например, измеренные данные, такие как положение или командные данные, такие как крутящий момент Запросы. В этом отношении он похож, например, на транслировал параметры данных в J1939.
Как это работает? Мы подробно рассмотрим это ниже.
# 6 Объект служебных данных [SDO]Что это? Службы SDO используются для доступа / изменения значений в объектном словаре устройства CANopen – e.грамм. когда мастеру приложения нужно изменить определенные конфигурации устройства CANopen.
Как это работает? Мы подробно рассмотрим это ниже.
# 7 Мониторинг узла (Heartbeat) [SDO]Что это? Служба Heartbeat имеет две цели: предоставить «живое» сообщение и подтвердить команду NMT.
Как это работает? Подчиненное устройство NMT периодически отправляет (например, каждые 100 мс) сообщение Heartbeat (e.грамм. с CAN ID 705 для узла 5) с узлом «Состояние» в 1-м байте данных
«Потребитель» сообщения Heartbeat (например, главное устройство NMT и, возможно, любое другое устройство) затем реагирует, если сообщение не получено в течение определенного периода времени.
Услуги PDO и SDO особенно важны, поскольку они составляют основу для большинства коммуникаций CANopen.
Ниже мы подробно рассмотрим каждый из них, но сначала нам нужно представить основную концепцию CANopen: объектный словарь .
Словарь объектов CANopen
Все узлы CANopen должны иметь словарь объектов (OD) – но что это такое?
Словарь объектов – это стандартизированная структура, содержащая все параметры, описывающие поведение узла CANopen.
записей OD ищутся через 16-битный индекс и 8-битный субиндекс. Например, индекс 1008 (субиндекс 0) CANopen-совместимого узла OD содержит устройство узла . название .
В частности, запись в объектном словаре определяется атрибутами:
- Индекс: 16-битный базовый адрес объекта
- Имя объекта: Название устройства производителя
- Код объекта: Массив, переменная или запись
- Тип данных: Например, VISIBLE_STRING, или UNSIGNED32, или имя записи
- Доступ: rw (чтение / запись), ro (только чтение), wo (только запись)
- Категория: Указывает, является ли этот параметр обязательным / необязательным (M / O)
OD стандартизованные секции
Словарь объектов разделен на стандартизированных разделов , где некоторые записи являются обязательными, а другие полностью настраиваемыми.
Важно отметить, что записи OD устройства (например, ведомого) могут быть доступны другому устройству (например, ведущему) через CAN, например, с помощью SDO.
Например, это может позволить главному устройству приложения изменять, регистрирует ли подчиненный узел данные через определенный входной датчик – или как часто подчиненное устройство отправляет контрольный сигнал.
Ссылка на электронную таблицу данных и файл конфигурации устройства
Чтобы понять OD, полезно взглянуть на «удобочитаемую форму»: электронную таблицу данных и файл конфигурации устройства.
Электронный лист данных (EDS)
На практике настройка / управление сложными сетями CANopen будет выполняться с использованием соответствующих программных инструментов.
Чтобы упростить это, стандарт CiA 306 определяет удобочитаемый (и машинно-удобный) формат файла INI, действующий как «шаблон» для OD устройства – например, то «ServoMotor3000». Этот EDS обычно предоставляется поставщиком и содержит информацию обо всех объектах устройства (но не значениях).
Файл конфигурации устройства (DCF)
Предположим, фабрика купила ServoMotor3000 для интеграции в конвейерную ленту. При этом оператор редактирует ЭЦП устройства и добавляет специфический параметр. значения и / или изменяет названия каждого объекта, описанного в EDS.
При этом оператор эффективно создает так называемый файл конфигурации устройства (DCF). После этого ServoMotor3000 готов к интеграции в конкретная сеть CANopen на месте.
EDS и пример DCF
Просмотр реальных примеров EDS / DCF – один из лучших способов действительно понять объектный словарь CANopen – см., Например, разница между EDS и DCF запись объекта ниже. Мы рекомендуем ознакомиться со стандартом CiA 306, чтобы получить более глубокое понимание OD, EDS и DCF с практическими примерами.
Как уже упоминалось, DCF обычно создается при интеграции устройства. Однако часто бывает необходимо прочитать и / или изменить значения объекта узла после первоначального конфигурация – здесь в игру вступает служба CANopen SDO.
SDO – настройка сети CANopen
Что такое SDO-сервис?
Служба SDO позволяет узлу CANopen считывать / редактировать значения словаря объектов другого узла по сети CAN.
Как упоминалось в разделе «Коммуникационные модели», службы CANopen SDO используют поведение «клиент / сервер».
В частности, «клиент» SDO инициирует связь с одним выделенным «сервером» SDO.
Целью может быть обновление записи OD (так называемая «загрузка SDO») или чтение записи («загрузка SDO»).
В простых сетях «ведущий / ведомый» узел с функцией ведущего устройства NMT действует как клиент для всех ведомых узлов NMT, считывающих или записывающих в свои OD.
Пример: загрузка SDO клиентского узла
Клиентский узел может инициировать загрузку SDO на узел 5 путем широковещательной передачи ниже кадра CAN, который запускает узел 5 (и игнорируется другими узлами, см. Рисунок выше). SDO “получить” (т.е. запрос) CAN кадр выглядит следующим образом:
Объяснение переменных сообщенияSDO
- Во-первых, COB-ID 605 отражает использование «приема SDO» (COB-ID 600 + идентификатор узла).
- CCS (спецификатор клиентской команды) – это тип передачи (например, 1: Загрузить, 2: Загрузить)
- n – это # байтов в байтах данных 4-7, которые не содержат данных (действительно, если установлены e & s)
- Если установлено, e указывает на «ускоренную передачу» (все данные находятся в одном кадре CAN)
- Если установлено, s указывает, что размер данных отображается в n
- Индекс (16 бит) и субиндекс (8 бит) отражают адрес OD, к которому будет осуществляться доступ
- Наконец, байты 4-7 содержат данные для загрузки на узел 5
После отправки кадра CAN ведущим (клиентом) подчиненный узел 5 (сервер) отвечает посредством «передачи SDO» с COB-ID 585.Ответ содержит индекс / субиндекс и 4 пустых байты данных. Естественно, если клиентский узел запросил загрузку вместо (т.е. чтение данных из OD узла 5), узел 5 ответит соответствующими данными, содержащимися в байты 4-7.
Несколько комментариев:
- Как видно, каждый SDO использует 2 идентификатора, создавая «канал SDO»
- Пример упрощен как «ускоренный» (данные содержатся в 4 байтах)
- Для сценариев с большими данными можно использовать сегментацию SDO / блочную передачу
SDO гибки, но несут много накладных расходов, что делает их менее идеальными для оперативных данных в реальном времени.
Вот где появляется PDO.
PDO – работа в сети CANopen
Прежде всего: что такое служба CANopen PDO?
Служба CANopen PDO используется для эффективного обмена рабочими данными в реальном времени между узлами CANopen.
Например, PDO будет нести данные давления от датчика давления или данные температуры от датчика температуры.
Но подождите: служба SDO не может просто сделать это?
Да, в принципе для этого можно использовать службу SDO.Однако один ответ SDO может нести только 4 байта данных из-за служебных данных (байт команды и адреса OD). Способствовать, скажем, главному узлу нужны два значения параметра (например, “SensTemp2” и “Torque5”) от узла 5 – чтобы получить их через SDO, потребуется 4 полных CAN-кадра (2 запроса, 2 ответы).
Напротив, сообщение PDO может содержать 8 полных байтов данных – и оно может содержать несколько значений параметров объекта в одном кадре. Таким образом, для чего потребуется не менее 4 кадры с SDO потенциально могут быть выполнены с помощью 1 кадра в службе PDO.
PDO часто рассматривается как наиболее важный протокол CANopen, поскольку он несет большой объем информации.
Как работает служба CANopen PDO?Для PDO используется терминология потребителя / производителя. Таким образом, производитель «производит данные», которые он передает «потребителю» (мастеру) с использованием передаваемого PDO (TPDO). И наоборот, это может получать данные от потребителя через принимающий PDO (RPDO).
Узлы-производители могут, например, быть настроенным для ответа на триггер SYNC, передаваемый потребителем каждые 100 мс.Узел 5 может, например, трансляция ниже передает PDO с COB-ID 185:
Обратите внимание, как байты данных упакованы с 3 значениями параметров. Эти значения отражают данные в реальном времени конкретных записей OD узла 5. Узлы, которые используют эту информацию ( потребители), конечно, нужно знать, как интерпретировать байты данных PDO.
Служба PDO в сравнении с PGN и SPN J1939Разве служба PDO немного похожа на PGN и SPN J1939?
Да, в некоторой степени это похоже на то, как конкретная группа параметров J1939 (PG) будет содержать несколько SPN / сигналов (также называемых параметрами данных) в 8 байтах данных.Фрейму CAN J1939 не нужно тратить байты данных на «декодирование» информации, потому что это известно соответствующим узлам (и внешними инструментами, например, через файлы J1939 DBC или стандарты PDF J1939). Проблема в том, что в CANopen эти «сопоставления PDO» часто настраивается и может быть изменен во время создания DCF и / или через службу SDO.
Подробнее о PDO см. В этой статье (стр. 5).
Регистрация данных CANopen – примеры использования
Поскольку CANopen является протоколом на основе CAN, можно записывать необработанные кадры CANopen с помощью регистратора данных шины CAN.
Например, CANedge позволяет записывать данные CANopen на SD-карту емкостью 8-32 ГБ. Просто подключите его к своему приложению, чтобы начать регистрацию – и обрабатывать данные с помощью бесплатного программного обеспечения / API.
учить большеДекодирование необработанных данных через файлы CANopen DBC
Поскольку CANopen основан на шине CAN, вы можете хранить свои правила декодирования CANopen в стандартизированном формате базы данных CAN, файле CAN DBC. Благодаря этому вы можете напрямую декодировать необработанные данные CANopen в программном обеспечении / инструментах API с открытым исходным кодом для CANedge, включая графический интерфейс asammdf, панели управления телематикой и инструменты Python API.
Обратите внимание, что у вас может не быть файла CANopen DBC под рукой, но правила декодирования кадра CANopen могут храниться в вашем EDS / DCF или в PDF-файле. В таком случае вы можете начать с нашего введения DBC, чтобы узнать, как создать файл CANopen DBC с нуля, используя различные бесплатные инструменты редактора.
Решения, такие как CANedge, позволяют использовать несколько сценариев использования протоколирования CANopen:
Регистрация данных узла CANopen
Как правило, регистрация данных CANopen может использоваться для e.грамм. анализировать оперативные данные. Регистраторы WiFi CAN также могут использоваться, например, для беспроводные SDO
Учить большеУправление складским парком
CANopen часто используется в вилочных погрузчиках EV / AGV на складах, где мониторинг, например, SoC помогает уменьшить поломки и продлить срок службы батареи
Учить большеПрофилактическое обслуживание
Промышленное оборудование можно контролировать с помощью логгеров IIoT CAN в облаке для прогнозирования и предотвращения поломок на основе данных CANopen
Учить большеЧерный ящик для диагностики машин
Регистратор CAN может служить «черным ящиком» для промышленного оборудования, предоставляя данные для e.грамм. диагностика споров или редких проблем
Учить большеНеобходимо регистрировать / передавать данные CANopen?
Получите свой CAN-логгер сегодня!
Рекомендуем
Объяснение CANopen – простое введение (2020)
Требуется простое и практичное введение в CANopen?
В этом руководстве мы познакомим вас с основами протокола CANopen, в т.ч. словарь объектов, службы, SDO, PDO и ведущие / ведомые узлы.
Примечание: CANopen может показаться сложным – так что это руководство является визуальным введением в терминах непрофессионала.
Прочтите ниже, чтобы полностью понять CANopen.
Вы также можете посмотреть наше вступительное видео о CANopen выше.
Что такое CANopen?
CANopen – это протокол связи на основе CAN.
Стандарт CANopen полезен, поскольку он обеспечивает готовую совместимость между устройствами (узлами) в e.грамм. промышленное оборудование. Кроме того, он предоставляет стандартные методы для настройка устройств – также после установки.
CANopen изначально был разработан для систем управления машинами, ориентированных на движение.
Сегодня CANopen широко используется в управлении двигателями (шаговые / серводвигатели), но также и в широком спектр других приложений:
Медицинский
Рентгеновские генераторы, инжекторы, столы для пациентов и диализные устройства
CANopen – протокол более высокого уровня
Важно понимать следующее:
CANopen – это «протокол более высокого уровня», основанный на шине CAN.
Это означает, что шина CAN (ISO 11898) служит «транспортным средством» (например, грузовиком) для сообщений CANopen (например, контейнеров).
Вы можете просматривать CANopen из 7-уровневой модели OSI, см. Ниже.
CANopen в контексте модели OSIМодель OSI – это концептуальная модель, стандартизирующая коммуникационные функции в различных коммуникационных технологиях. Нижние уровни описывают основные коммуникации (например, необработанные битовые потоки), в то время как более высокие уровни описывают такие вещи, как сегментация длинных сообщений и услуг, таких как инициирование, указание, ответ и подтверждение сообщений.
Шина CANпредставляет два нижних уровня (1: физический, 2: канал передачи данных). Это означает, что CAN просто разрешает передачу кадров с 11-битным CAN ID , удаленным бит передачи (RTR) и 64 бита данных (поля, относящиеся к протоколам более высокого уровня).
Другими словами, шина CAN играет в CANopen ту же роль, что и, например, в протокол J1939.
Как очевидно выше, CANopen реализует 7-й уровень модели OSI (приложение) через набор стандартов.В рамках этого он добавляет несколько важных концепции, которые мы подробно рассмотрим ниже.
Стоит отметить, что CANopen также может быть адаптирован к другим протоколам канального уровня, отличным от CAN (например, EtherCAT, Modbus, Powerlink).
Чтобы полностью разобраться в сравнении CAN-шины и CANopen, см. Также наше вводное руководство по CAN-шине.
CANopen FDВ этой статье мы в первую очередь сосредоточимся на CANopen, основанном на классической CAN. Однако стоит отметить, что по мере развертывания CAN FD CANopen FD может играть все более важную роль в качестве следующего поколения CANopen.Для получения дополнительной информации см. Обзор CAN в автоматизации на CANopen FD.
Шесть основных концепций CANopen
Даже если вы знакомы с CAN-шиной и, например, J1939, CANopen добавляет ряд важных новых концепций:
Коммуникационные модели
Существует 3 модели для связи устройства / узла: ведущий / ведомый, клиент / сервер и производитель / потребитель
Протоколы связи
Протоколы используются для связи, например.грамм. настройка узлов (SDO) или передача данных в реальном времени (PDO)
Устройство
Состояния
Устройство поддерживает разные состояния. «Главный» узел может изменять состояние «подчиненного» узла – например, сбросить его
Словарь объектов
Каждое устройство имеет OD с записями, которые определяют, например, конфигурация устройства. Доступ к нему можно получить через SDO
Электронный лист данных
EDS – это стандартный формат файла для записей OD, позволяющий e.грамм. сервисные инструменты для обновления устройств
Профили устройств
Стандартыописывают, например, Модули ввода / вывода (CiA 401) и управление движением (CiA 402) для независимости от производителя
На иллюстрации ниже показано, как концепции CANopen связаны друг с другом, и мы подробно рассмотрим каждую из них:
Основы связи CANopen
В сети CANopen несколько устройств должны обмениваться данными.
Например, в системе промышленной автоматизации у вас может быть рука робота с несколькими узлами серводвигателей и интерфейсом управления / узлом ПК.
Для облегчения связи существует три модели внутри CANopen, каждая из которых тесно связана с протоколами CANopen, которые мы вскоре рассмотрим. См. Краткое введение ниже:
Коммуникационные модели CANopenГлавный / Подчиненный
Один узел (например, интерфейс управления) действует как мастер приложения или хост-контроллер. Он отправляет / запрашивает данные от ведомых устройств (например, серводвигателей). Это используется, например, в диагностика или управление состоянием.В стандартных приложениях может быть от 0 до 127 ведомых устройств. Обратите внимание, что в одной сети CANopen могут использоваться разные хост-контроллеры. тот же уровень канала передачи данных.
Пример обслуживания: NMT
Клиент / Сервер
Клиент отправляет запрос данных на сервер, который отвечает запрошенными данными. Используется, например, когда мастеру приложения нужны данные от OD ведомого устройства. Чтение из сервер – это «загрузка», а запись – «загрузка» (в терминологии используется перспектива «на стороне сервера»).
Пример обслуживания: SDO
Потребитель / Производитель
Здесь узел-производитель передает данные в сеть, которые потребляются узлом-потребителем. Производитель отправляет эти данные по запросу (модель pull) или без конкретный запрос (модель push).
Пример обслуживания: Heartbeat
Как видно, модели практически идентичны, но мы различаем их для единообразия терминологии.
Рама CANopen
Чтобы понять связь CANopen, необходимо разбить CANopen CAN-фрейм :
11-битный CAN ID называется идентификатором объекта связи ( COB-ID ) и делится на две части:
По умолчанию первые 4 бита равны код функции и следующие 7 битов содержат идентификатор узла .
Чтобы понять, как работает COB-ID, давайте начнем с предопределенного распределения идентификаторов, используемых в простых сетях CANopen (см. Таблицу).
Примечание. Ниже мы будем ссылаться на идентификаторы COB-ID и идентификаторы узлов в шестнадцатеричном формате.
Как видно, COB-ID (например, 381, 581,…) связаны с услугами связи (передача PDO 3, передача SDO,…).
Таким образом, COB-ID указывает, какой узел отправляет / принимает данные и какая служба используется .
ПримерУстройство CANopen с идентификатором узла 5 будет передавать SDO через 11-битный идентификатор CAN 585 .
Это соответствует двоичному коду функции 1011 и идентификатору узла 5 (двоичный: 0000101) – см. Иллюстрацию:
Онлайн-конвертер CANopen COB-ID
Наш конвертер COB-ID позволяет быстро найти CANopen COB-ID, чтобы получить основные сведения, включаякод функции и идентификатор узла.
Протоколы / услуги связи CANopen
Ниже мы кратко опишем 7 упомянутых типов услуг, в т.ч. как они используют 8 байтов данных CAN кадра .
# 1 Управление сетью (NMT)Что это такое? Служба NMT используется для управления состоянием устройств CANopen (например, до начала работы, в рабочем состоянии, остановлено) с помощью NMT. команды (например, пуск, останов, сброс).
Как это работает? Чтобы изменить состояние, мастер NMT отправляет 2-байтовое сообщение с CAN ID 0 (т.е.е. код функции 0 и идентификатор узла 0). Все подчиненные узлы обрабатывают это сообщение. 1-й байт данных CAN содержит запрошенное состояние, а 2-й байт данных CAN содержит идентификатор целевого узла. Идентификатор узла 0 указывает на широковещательная команда.
Возможные команды включают переход в рабочий (состояние 01), в остановленный (состояние 02), предрабочий (состояние 80), а также приложение сброса (81) и сброс связь (82).
# 2 Синхронизация (SYNC)Что это? Используется сообщение SYNC e.грамм. для синхронизации считывания входов и срабатывания нескольких устройств CANopen – обычно запускается мастер приложения.
Как это работает? Мастер приложения отправляет сообщение SYNC (COB ID 080) в сеть CANopen (со счетчиком SYNC или без него). Множественный раб узлы могут быть настроены так, чтобы реагировать на SYNC и отвечать, передавая входные данные, захваченные в одно и то же время, или устанавливая выход в то же время, что и узлы, участвующие в синхронной операции.С помощью счетчика SYNC можно настроить несколько групп синхронно работающих устройств.
# 3 Emergency (EMCY)Что это? Служба экстренной помощи используется в случае, если в устройстве произошла фатальная ошибка (например, отказ датчика), что позволяет ему сообщить об этом остальная часть сети.
Как это работает? Затронутый узел отправляет одно сообщение EMCY (например, с COB-ID 085 для узла 5) в сеть с высоким приоритетом.Байты данных содержат информация об ошибке, в которой можно найти подробности.
# 4 Отметка времени (TIME) [PDO]
Что это? С помощью этой услуги связи можно распределить глобальное сетевое время. Сервис TIME содержит 6-байтовую информацию о дате и времени.
Как это работает? Мастер приложения отправляет сообщение TIME с CAN ID 100, где начальные 4 байта данных содержат время в мс после полночь и следующие 2 байта содержат количество дней, прошедших с 1 января 1984 года.
# 5 Объект данных процесса [PDO]
Что это такое? Служба PDO используется для передачи данных в реальном времени между устройствами – например, измеренные данные, такие как положение или командные данные, такие как крутящий момент Запросы. В этом отношении он похож, например, на транслировал параметры данных в J1939.
Как это работает? Мы подробно рассмотрим это ниже.
# 6 Объект служебных данных [SDO]Что это? Службы SDO используются для доступа / изменения значений в объектном словаре устройства CANopen – e.грамм. когда мастеру приложения нужно изменить определенные конфигурации устройства CANopen.
Как это работает? Мы подробно рассмотрим это ниже.
# 7 Мониторинг узла (Heartbeat) [SDO]Что это? Служба Heartbeat имеет две цели: предоставить «живое» сообщение и подтвердить команду NMT.
Как это работает? Подчиненное устройство NMT периодически отправляет (например, каждые 100 мс) сообщение Heartbeat (e.грамм. с CAN ID 705 для узла 5) с узлом «Состояние» в 1-м байте данных
«Потребитель» сообщения Heartbeat (например, главное устройство NMT и, возможно, любое другое устройство) затем реагирует, если сообщение не получено в течение определенного периода времени.
Услуги PDO и SDO особенно важны, поскольку они составляют основу для большинства коммуникаций CANopen.
Ниже мы подробно рассмотрим каждый из них, но сначала нам нужно представить основную концепцию CANopen: объектный словарь .
Словарь объектов CANopen
Все узлы CANopen должны иметь словарь объектов (OD) – но что это такое?
Словарь объектов – это стандартизированная структура, содержащая все параметры, описывающие поведение узла CANopen.
записей OD ищутся через 16-битный индекс и 8-битный субиндекс. Например, индекс 1008 (субиндекс 0) CANopen-совместимого узла OD содержит устройство узла . название .
В частности, запись в объектном словаре определяется атрибутами:
- Индекс: 16-битный базовый адрес объекта
- Имя объекта: Название устройства производителя
- Код объекта: Массив, переменная или запись
- Тип данных: Например, VISIBLE_STRING, или UNSIGNED32, или имя записи
- Доступ: rw (чтение / запись), ro (только чтение), wo (только запись)
- Категория: Указывает, является ли этот параметр обязательным / необязательным (M / O)
OD стандартизованные секции
Словарь объектов разделен на стандартизированных разделов , где некоторые записи являются обязательными, а другие полностью настраиваемыми.
Важно отметить, что записи OD устройства (например, ведомого) могут быть доступны другому устройству (например, ведущему) через CAN, например, с помощью SDO.
Например, это может позволить главному устройству приложения изменять, регистрирует ли подчиненный узел данные через определенный входной датчик – или как часто подчиненное устройство отправляет контрольный сигнал.
Ссылка на электронную таблицу данных и файл конфигурации устройства
Чтобы понять OD, полезно взглянуть на «удобочитаемую форму»: электронную таблицу данных и файл конфигурации устройства.
Электронный лист данных (EDS)
На практике настройка / управление сложными сетями CANopen будет выполняться с использованием соответствующих программных инструментов.
Чтобы упростить это, стандарт CiA 306 определяет удобочитаемый (и машинно-удобный) формат файла INI, действующий как «шаблон» для OD устройства – например, то «ServoMotor3000». Этот EDS обычно предоставляется поставщиком и содержит информацию обо всех объектах устройства (но не значениях).
Файл конфигурации устройства (DCF)
Предположим, фабрика купила ServoMotor3000 для интеграции в конвейерную ленту. При этом оператор редактирует ЭЦП устройства и добавляет специфический параметр. значения и / или изменяет названия каждого объекта, описанного в EDS.
При этом оператор эффективно создает так называемый файл конфигурации устройства (DCF). После этого ServoMotor3000 готов к интеграции в конкретная сеть CANopen на месте.
EDS и пример DCF
Просмотр реальных примеров EDS / DCF – один из лучших способов действительно понять объектный словарь CANopen – см., Например, разница между EDS и DCF запись объекта ниже. Мы рекомендуем ознакомиться со стандартом CiA 306, чтобы получить более глубокое понимание OD, EDS и DCF с практическими примерами.
Как уже упоминалось, DCF обычно создается при интеграции устройства. Однако часто бывает необходимо прочитать и / или изменить значения объекта узла после первоначального конфигурация – здесь в игру вступает служба CANopen SDO.
SDO – настройка сети CANopen
Что такое SDO-сервис?
Служба SDO позволяет узлу CANopen считывать / редактировать значения словаря объектов другого узла по сети CAN.
Как упоминалось в разделе «Коммуникационные модели», службы CANopen SDO используют поведение «клиент / сервер».
В частности, «клиент» SDO инициирует связь с одним выделенным «сервером» SDO.
Целью может быть обновление записи OD (так называемая «загрузка SDO») или чтение записи («загрузка SDO»).
В простых сетях «ведущий / ведомый» узел с функцией ведущего устройства NMT действует как клиент для всех ведомых узлов NMT, считывающих или записывающих в свои OD.
Пример: загрузка SDO клиентского узла
Клиентский узел может инициировать загрузку SDO на узел 5 путем широковещательной передачи ниже кадра CAN, который запускает узел 5 (и игнорируется другими узлами, см. Рисунок выше). SDO “получить” (т.е. запрос) CAN кадр выглядит следующим образом:
Объяснение переменных сообщенияSDO
- Во-первых, COB-ID 605 отражает использование «приема SDO» (COB-ID 600 + идентификатор узла).
- CCS (спецификатор клиентской команды) – это тип передачи (например, 1: Загрузить, 2: Загрузить)
- n – это # байтов в байтах данных 4-7, которые не содержат данных (действительно, если установлены e & s)
- Если установлено, e указывает на «ускоренную передачу» (все данные находятся в одном кадре CAN)
- Если установлено, s указывает, что размер данных отображается в n
- Индекс (16 бит) и субиндекс (8 бит) отражают адрес OD, к которому будет осуществляться доступ
- Наконец, байты 4-7 содержат данные для загрузки на узел 5
После отправки кадра CAN ведущим (клиентом) подчиненный узел 5 (сервер) отвечает посредством «передачи SDO» с COB-ID 585.Ответ содержит индекс / субиндекс и 4 пустых байты данных. Естественно, если клиентский узел запросил загрузку вместо (т.е. чтение данных из OD узла 5), узел 5 ответит соответствующими данными, содержащимися в байты 4-7.
Несколько комментариев:
- Как видно, каждый SDO использует 2 идентификатора, создавая «канал SDO»
- Пример упрощен как «ускоренный» (данные содержатся в 4 байтах)
- Для сценариев с большими данными можно использовать сегментацию SDO / блочную передачу
SDO гибки, но несут много накладных расходов, что делает их менее идеальными для оперативных данных в реальном времени.
Вот где появляется PDO.
PDO – работа в сети CANopen
Прежде всего: что такое служба CANopen PDO?
Служба CANopen PDO используется для эффективного обмена рабочими данными в реальном времени между узлами CANopen.
Например, PDO будет нести данные давления от датчика давления или данные температуры от датчика температуры.
Но подождите: служба SDO не может просто сделать это?
Да, в принципе для этого можно использовать службу SDO.Однако один ответ SDO может нести только 4 байта данных из-за служебных данных (байт команды и адреса OD). Способствовать, скажем, главному узлу нужны два значения параметра (например, “SensTemp2” и “Torque5”) от узла 5 – чтобы получить их через SDO, потребуется 4 полных CAN-кадра (2 запроса, 2 ответы).
Напротив, сообщение PDO может содержать 8 полных байтов данных – и оно может содержать несколько значений параметров объекта в одном кадре. Таким образом, для чего потребуется не менее 4 кадры с SDO потенциально могут быть выполнены с помощью 1 кадра в службе PDO.
PDO часто рассматривается как наиболее важный протокол CANopen, поскольку он несет большой объем информации.
Как работает служба CANopen PDO?Для PDO используется терминология потребителя / производителя. Таким образом, производитель «производит данные», которые он передает «потребителю» (мастеру) с использованием передаваемого PDO (TPDO). И наоборот, это может получать данные от потребителя через принимающий PDO (RPDO).
Узлы-производители могут, например, быть настроенным для ответа на триггер SYNC, передаваемый потребителем каждые 100 мс.Узел 5 может, например, трансляция ниже передает PDO с COB-ID 185:
Обратите внимание, как байты данных упакованы с 3 значениями параметров. Эти значения отражают данные в реальном времени конкретных записей OD узла 5. Узлы, которые используют эту информацию ( потребители), конечно, нужно знать, как интерпретировать байты данных PDO.
Служба PDO в сравнении с PGN и SPN J1939Разве служба PDO немного похожа на PGN и SPN J1939?
Да, в некоторой степени это похоже на то, как конкретная группа параметров J1939 (PG) будет содержать несколько SPN / сигналов (также называемых параметрами данных) в 8 байтах данных.Фрейму CAN J1939 не нужно тратить байты данных на «декодирование» информации, потому что это известно соответствующим узлам (и внешними инструментами, например, через файлы J1939 DBC или стандарты PDF J1939). Проблема в том, что в CANopen эти «сопоставления PDO» часто настраивается и может быть изменен во время создания DCF и / или через службу SDO.
Подробнее о PDO см. В этой статье (стр. 5).
Регистрация данных CANopen – примеры использования
Поскольку CANopen является протоколом на основе CAN, можно записывать необработанные кадры CANopen с помощью регистратора данных шины CAN.
Например, CANedge позволяет записывать данные CANopen на SD-карту емкостью 8-32 ГБ. Просто подключите его к своему приложению, чтобы начать регистрацию – и обрабатывать данные с помощью бесплатного программного обеспечения / API.
учить большеДекодирование необработанных данных через файлы CANopen DBC
Поскольку CANopen основан на шине CAN, вы можете хранить свои правила декодирования CANopen в стандартизированном формате базы данных CAN, файле CAN DBC. Благодаря этому вы можете напрямую декодировать необработанные данные CANopen в программном обеспечении / инструментах API с открытым исходным кодом для CANedge, включая графический интерфейс asammdf, панели управления телематикой и инструменты Python API.
Обратите внимание, что у вас может не быть файла CANopen DBC под рукой, но правила декодирования кадра CANopen могут храниться в вашем EDS / DCF или в PDF-файле. В таком случае вы можете начать с нашего введения DBC, чтобы узнать, как создать файл CANopen DBC с нуля, используя различные бесплатные инструменты редактора.
Решения, такие как CANedge, позволяют использовать несколько сценариев использования протоколирования CANopen:
Регистрация данных узла CANopen
Как правило, регистрация данных CANopen может использоваться для e.грамм. анализировать оперативные данные. Регистраторы WiFi CAN также могут использоваться, например, для беспроводные SDO
Учить большеУправление складским парком
CANopen часто используется в вилочных погрузчиках EV / AGV на складах, где мониторинг, например, SoC помогает уменьшить поломки и продлить срок службы батареи
Учить большеПрофилактическое обслуживание
Промышленное оборудование можно контролировать с помощью логгеров IIoT CAN в облаке для прогнозирования и предотвращения поломок на основе данных CANopen
Учить большеЧерный ящик для диагностики машин
Регистратор CAN может служить «черным ящиком» для промышленного оборудования, предоставляя данные для e.грамм. диагностика споров или редких проблем
Учить большеНеобходимо регистрировать / передавать данные CANopen?
Получите свой CAN-логгер сегодня!
Рекомендуем
Объяснение CANopen – простое введение (2020)
Требуется простое и практичное введение в CANopen?
В этом руководстве мы познакомим вас с основами протокола CANopen, в т.ч. словарь объектов, службы, SDO, PDO и ведущие / ведомые узлы.
Примечание: CANopen может показаться сложным – так что это руководство является визуальным введением в терминах непрофессионала.
Прочтите ниже, чтобы полностью понять CANopen.
Вы также можете посмотреть наше вступительное видео о CANopen выше.
Что такое CANopen?
CANopen – это протокол связи на основе CAN.
Стандарт CANopen полезен, поскольку он обеспечивает готовую совместимость между устройствами (узлами) в e.грамм. промышленное оборудование. Кроме того, он предоставляет стандартные методы для настройка устройств – также после установки.
CANopen изначально был разработан для систем управления машинами, ориентированных на движение.
Сегодня CANopen широко используется в управлении двигателями (шаговые / серводвигатели), но также и в широком спектр других приложений:
Медицинский
Рентгеновские генераторы, инжекторы, столы для пациентов и диализные устройства
CANopen – протокол более высокого уровня
Важно понимать следующее:
CANopen – это «протокол более высокого уровня», основанный на шине CAN.
Это означает, что шина CAN (ISO 11898) служит «транспортным средством» (например, грузовиком) для сообщений CANopen (например, контейнеров).
Вы можете просматривать CANopen из 7-уровневой модели OSI, см. Ниже.
CANopen в контексте модели OSIМодель OSI – это концептуальная модель, стандартизирующая коммуникационные функции в различных коммуникационных технологиях. Нижние уровни описывают основные коммуникации (например, необработанные битовые потоки), в то время как более высокие уровни описывают такие вещи, как сегментация длинных сообщений и услуг, таких как инициирование, указание, ответ и подтверждение сообщений.
Шина CANпредставляет два нижних уровня (1: физический, 2: канал передачи данных). Это означает, что CAN просто разрешает передачу кадров с 11-битным CAN ID , удаленным бит передачи (RTR) и 64 бита данных (поля, относящиеся к протоколам более высокого уровня).
Другими словами, шина CAN играет в CANopen ту же роль, что и, например, в протокол J1939.
Как очевидно выше, CANopen реализует 7-й уровень модели OSI (приложение) через набор стандартов.В рамках этого он добавляет несколько важных концепции, которые мы подробно рассмотрим ниже.
Стоит отметить, что CANopen также может быть адаптирован к другим протоколам канального уровня, отличным от CAN (например, EtherCAT, Modbus, Powerlink).
Чтобы полностью разобраться в сравнении CAN-шины и CANopen, см. Также наше вводное руководство по CAN-шине.
CANopen FDВ этой статье мы в первую очередь сосредоточимся на CANopen, основанном на классической CAN. Однако стоит отметить, что по мере развертывания CAN FD CANopen FD может играть все более важную роль в качестве следующего поколения CANopen.Для получения дополнительной информации см. Обзор CAN в автоматизации на CANopen FD.
Шесть основных концепций CANopen
Даже если вы знакомы с CAN-шиной и, например, J1939, CANopen добавляет ряд важных новых концепций:
Коммуникационные модели
Существует 3 модели для связи устройства / узла: ведущий / ведомый, клиент / сервер и производитель / потребитель
Протоколы связи
Протоколы используются для связи, например.грамм. настройка узлов (SDO) или передача данных в реальном времени (PDO)
Устройство
Состояния
Устройство поддерживает разные состояния. «Главный» узел может изменять состояние «подчиненного» узла – например, сбросить его
Словарь объектов
Каждое устройство имеет OD с записями, которые определяют, например, конфигурация устройства. Доступ к нему можно получить через SDO
Электронный лист данных
EDS – это стандартный формат файла для записей OD, позволяющий e.грамм. сервисные инструменты для обновления устройств
Профили устройств
Стандартыописывают, например, Модули ввода / вывода (CiA 401) и управление движением (CiA 402) для независимости от производителя
На иллюстрации ниже показано, как концепции CANopen связаны друг с другом, и мы подробно рассмотрим каждую из них:
Основы связи CANopen
В сети CANopen несколько устройств должны обмениваться данными.
Например, в системе промышленной автоматизации у вас может быть рука робота с несколькими узлами серводвигателей и интерфейсом управления / узлом ПК.
Для облегчения связи существует три модели внутри CANopen, каждая из которых тесно связана с протоколами CANopen, которые мы вскоре рассмотрим. См. Краткое введение ниже:
Коммуникационные модели CANopenГлавный / Подчиненный
Один узел (например, интерфейс управления) действует как мастер приложения или хост-контроллер. Он отправляет / запрашивает данные от ведомых устройств (например, серводвигателей). Это используется, например, в диагностика или управление состоянием.В стандартных приложениях может быть от 0 до 127 ведомых устройств. Обратите внимание, что в одной сети CANopen могут использоваться разные хост-контроллеры. тот же уровень канала передачи данных.
Пример обслуживания: NMT
Клиент / Сервер
Клиент отправляет запрос данных на сервер, который отвечает запрошенными данными. Используется, например, когда мастеру приложения нужны данные от OD ведомого устройства. Чтение из сервер – это «загрузка», а запись – «загрузка» (в терминологии используется перспектива «на стороне сервера»).
Пример обслуживания: SDO
Потребитель / Производитель
Здесь узел-производитель передает данные в сеть, которые потребляются узлом-потребителем. Производитель отправляет эти данные по запросу (модель pull) или без конкретный запрос (модель push).
Пример обслуживания: Heartbeat
Как видно, модели практически идентичны, но мы различаем их для единообразия терминологии.
Рама CANopen
Чтобы понять связь CANopen, необходимо разбить CANopen CAN-фрейм :
11-битный CAN ID называется идентификатором объекта связи ( COB-ID ) и делится на две части:
По умолчанию первые 4 бита равны код функции и следующие 7 битов содержат идентификатор узла .
Чтобы понять, как работает COB-ID, давайте начнем с предопределенного распределения идентификаторов, используемых в простых сетях CANopen (см. Таблицу).
Примечание. Ниже мы будем ссылаться на идентификаторы COB-ID и идентификаторы узлов в шестнадцатеричном формате.
Как видно, COB-ID (например, 381, 581,…) связаны с услугами связи (передача PDO 3, передача SDO,…).
Таким образом, COB-ID указывает, какой узел отправляет / принимает данные и какая служба используется .
ПримерУстройство CANopen с идентификатором узла 5 будет передавать SDO через 11-битный идентификатор CAN 585 .
Это соответствует двоичному коду функции 1011 и идентификатору узла 5 (двоичный: 0000101) – см. Иллюстрацию:
Онлайн-конвертер CANopen COB-ID
Наш конвертер COB-ID позволяет быстро найти CANopen COB-ID, чтобы получить основные сведения, включаякод функции и идентификатор узла.
Протоколы / услуги связи CANopen
Ниже мы кратко опишем 7 упомянутых типов услуг, в т.ч. как они используют 8 байтов данных CAN кадра .
# 1 Управление сетью (NMT)Что это такое? Служба NMT используется для управления состоянием устройств CANopen (например, до начала работы, в рабочем состоянии, остановлено) с помощью NMT. команды (например, пуск, останов, сброс).
Как это работает? Чтобы изменить состояние, мастер NMT отправляет 2-байтовое сообщение с CAN ID 0 (т.е.е. код функции 0 и идентификатор узла 0). Все подчиненные узлы обрабатывают это сообщение. 1-й байт данных CAN содержит запрошенное состояние, а 2-й байт данных CAN содержит идентификатор целевого узла. Идентификатор узла 0 указывает на широковещательная команда.
Возможные команды включают переход в рабочий (состояние 01), в остановленный (состояние 02), предрабочий (состояние 80), а также приложение сброса (81) и сброс связь (82).
# 2 Синхронизация (SYNC)Что это? Используется сообщение SYNC e.грамм. для синхронизации считывания входов и срабатывания нескольких устройств CANopen – обычно запускается мастер приложения.
Как это работает? Мастер приложения отправляет сообщение SYNC (COB ID 080) в сеть CANopen (со счетчиком SYNC или без него). Множественный раб узлы могут быть настроены так, чтобы реагировать на SYNC и отвечать, передавая входные данные, захваченные в одно и то же время, или устанавливая выход в то же время, что и узлы, участвующие в синхронной операции.С помощью счетчика SYNC можно настроить несколько групп синхронно работающих устройств.
# 3 Emergency (EMCY)Что это? Служба экстренной помощи используется в случае, если в устройстве произошла фатальная ошибка (например, отказ датчика), что позволяет ему сообщить об этом остальная часть сети.
Как это работает? Затронутый узел отправляет одно сообщение EMCY (например, с COB-ID 085 для узла 5) в сеть с высоким приоритетом.Байты данных содержат информация об ошибке, в которой можно найти подробности.
# 4 Отметка времени (TIME) [PDO]
Что это? С помощью этой услуги связи можно распределить глобальное сетевое время. Сервис TIME содержит 6-байтовую информацию о дате и времени.
Как это работает? Мастер приложения отправляет сообщение TIME с CAN ID 100, где начальные 4 байта данных содержат время в мс после полночь и следующие 2 байта содержат количество дней, прошедших с 1 января 1984 года.
# 5 Объект данных процесса [PDO]
Что это такое? Служба PDO используется для передачи данных в реальном времени между устройствами – например, измеренные данные, такие как положение или командные данные, такие как крутящий момент Запросы. В этом отношении он похож, например, на транслировал параметры данных в J1939.
Как это работает? Мы подробно рассмотрим это ниже.
# 6 Объект служебных данных [SDO]Что это? Службы SDO используются для доступа / изменения значений в объектном словаре устройства CANopen – e.грамм. когда мастеру приложения нужно изменить определенные конфигурации устройства CANopen.
Как это работает? Мы подробно рассмотрим это ниже.
# 7 Мониторинг узла (Heartbeat) [SDO]Что это? Служба Heartbeat имеет две цели: предоставить «живое» сообщение и подтвердить команду NMT.
Как это работает? Подчиненное устройство NMT периодически отправляет (например, каждые 100 мс) сообщение Heartbeat (e.грамм. с CAN ID 705 для узла 5) с узлом «Состояние» в 1-м байте данных
«Потребитель» сообщения Heartbeat (например, главное устройство NMT и, возможно, любое другое устройство) затем реагирует, если сообщение не получено в течение определенного периода времени.
Услуги PDO и SDO особенно важны, поскольку они составляют основу для большинства коммуникаций CANopen.
Ниже мы подробно рассмотрим каждый из них, но сначала нам нужно представить основную концепцию CANopen: объектный словарь .
Словарь объектов CANopen
Все узлы CANopen должны иметь словарь объектов (OD) – но что это такое?
Словарь объектов – это стандартизированная структура, содержащая все параметры, описывающие поведение узла CANopen.
записей OD ищутся через 16-битный индекс и 8-битный субиндекс. Например, индекс 1008 (субиндекс 0) CANopen-совместимого узла OD содержит устройство узла . название .
В частности, запись в объектном словаре определяется атрибутами:
- Индекс: 16-битный базовый адрес объекта
- Имя объекта: Название устройства производителя
- Код объекта: Массив, переменная или запись
- Тип данных: Например, VISIBLE_STRING, или UNSIGNED32, или имя записи
- Доступ: rw (чтение / запись), ro (только чтение), wo (только запись)
- Категория: Указывает, является ли этот параметр обязательным / необязательным (M / O)
OD стандартизованные секции
Словарь объектов разделен на стандартизированных разделов , где некоторые записи являются обязательными, а другие полностью настраиваемыми.
Важно отметить, что записи OD устройства (например, ведомого) могут быть доступны другому устройству (например, ведущему) через CAN, например, с помощью SDO.
Например, это может позволить главному устройству приложения изменять, регистрирует ли подчиненный узел данные через определенный входной датчик – или как часто подчиненное устройство отправляет контрольный сигнал.
Ссылка на электронную таблицу данных и файл конфигурации устройства
Чтобы понять OD, полезно взглянуть на «удобочитаемую форму»: электронную таблицу данных и файл конфигурации устройства.
Электронный лист данных (EDS)
На практике настройка / управление сложными сетями CANopen будет выполняться с использованием соответствующих программных инструментов.
Чтобы упростить это, стандарт CiA 306 определяет удобочитаемый (и машинно-удобный) формат файла INI, действующий как «шаблон» для OD устройства – например, то «ServoMotor3000». Этот EDS обычно предоставляется поставщиком и содержит информацию обо всех объектах устройства (но не значениях).
Файл конфигурации устройства (DCF)
Предположим, фабрика купила ServoMotor3000 для интеграции в конвейерную ленту. При этом оператор редактирует ЭЦП устройства и добавляет специфический параметр. значения и / или изменяет названия каждого объекта, описанного в EDS.
При этом оператор эффективно создает так называемый файл конфигурации устройства (DCF). После этого ServoMotor3000 готов к интеграции в конкретная сеть CANopen на месте.
EDS и пример DCF
Просмотр реальных примеров EDS / DCF – один из лучших способов действительно понять объектный словарь CANopen – см., Например, разница между EDS и DCF запись объекта ниже. Мы рекомендуем ознакомиться со стандартом CiA 306, чтобы получить более глубокое понимание OD, EDS и DCF с практическими примерами.
Как уже упоминалось, DCF обычно создается при интеграции устройства. Однако часто бывает необходимо прочитать и / или изменить значения объекта узла после первоначального конфигурация – здесь в игру вступает служба CANopen SDO.
SDO – настройка сети CANopen
Что такое SDO-сервис?
Служба SDO позволяет узлу CANopen считывать / редактировать значения словаря объектов другого узла по сети CAN.
Как упоминалось в разделе «Коммуникационные модели», службы CANopen SDO используют поведение «клиент / сервер».
В частности, «клиент» SDO инициирует связь с одним выделенным «сервером» SDO.
Целью может быть обновление записи OD (так называемая «загрузка SDO») или чтение записи («загрузка SDO»).
В простых сетях «ведущий / ведомый» узел с функцией ведущего устройства NMT действует как клиент для всех ведомых узлов NMT, считывающих или записывающих в свои OD.
Пример: загрузка SDO клиентского узла
Клиентский узел может инициировать загрузку SDO на узел 5 путем широковещательной передачи ниже кадра CAN, который запускает узел 5 (и игнорируется другими узлами, см. Рисунок выше). SDO “получить” (т.е. запрос) CAN кадр выглядит следующим образом:
Объяснение переменных сообщенияSDO
- Во-первых, COB-ID 605 отражает использование «приема SDO» (COB-ID 600 + идентификатор узла).
- CCS (спецификатор клиентской команды) – это тип передачи (например, 1: Загрузить, 2: Загрузить)
- n – это # байтов в байтах данных 4-7, которые не содержат данных (действительно, если установлены e & s)
- Если установлено, e указывает на «ускоренную передачу» (все данные находятся в одном кадре CAN)
- Если установлено, s указывает, что размер данных отображается в n
- Индекс (16 бит) и субиндекс (8 бит) отражают адрес OD, к которому будет осуществляться доступ
- Наконец, байты 4-7 содержат данные для загрузки на узел 5
После отправки кадра CAN ведущим (клиентом) подчиненный узел 5 (сервер) отвечает посредством «передачи SDO» с COB-ID 585.Ответ содержит индекс / субиндекс и 4 пустых байты данных. Естественно, если клиентский узел запросил загрузку вместо (т.е. чтение данных из OD узла 5), узел 5 ответит соответствующими данными, содержащимися в байты 4-7.
Несколько комментариев:
- Как видно, каждый SDO использует 2 идентификатора, создавая «канал SDO»
- Пример упрощен как «ускоренный» (данные содержатся в 4 байтах)
- Для сценариев с большими данными можно использовать сегментацию SDO / блочную передачу
SDO гибки, но несут много накладных расходов, что делает их менее идеальными для оперативных данных в реальном времени.
Вот где появляется PDO.
PDO – работа в сети CANopen
Прежде всего: что такое служба CANopen PDO?
Служба CANopen PDO используется для эффективного обмена рабочими данными в реальном времени между узлами CANopen.
Например, PDO будет нести данные давления от датчика давления или данные температуры от датчика температуры.
Но подождите: служба SDO не может просто сделать это?
Да, в принципе для этого можно использовать службу SDO.Однако один ответ SDO может нести только 4 байта данных из-за служебных данных (байт команды и адреса OD). Способствовать, скажем, главному узлу нужны два значения параметра (например, “SensTemp2” и “Torque5”) от узла 5 – чтобы получить их через SDO, потребуется 4 полных CAN-кадра (2 запроса, 2 ответы).
Напротив, сообщение PDO может содержать 8 полных байтов данных – и оно может содержать несколько значений параметров объекта в одном кадре. Таким образом, для чего потребуется не менее 4 кадры с SDO потенциально могут быть выполнены с помощью 1 кадра в службе PDO.
PDO часто рассматривается как наиболее важный протокол CANopen, поскольку он несет большой объем информации.
Как работает служба CANopen PDO?Для PDO используется терминология потребителя / производителя. Таким образом, производитель «производит данные», которые он передает «потребителю» (мастеру) с использованием передаваемого PDO (TPDO). И наоборот, это может получать данные от потребителя через принимающий PDO (RPDO).
Узлы-производители могут, например, быть настроенным для ответа на триггер SYNC, передаваемый потребителем каждые 100 мс.Узел 5 может, например, трансляция ниже передает PDO с COB-ID 185:
Обратите внимание, как байты данных упакованы с 3 значениями параметров. Эти значения отражают данные в реальном времени конкретных записей OD узла 5. Узлы, которые используют эту информацию ( потребители), конечно, нужно знать, как интерпретировать байты данных PDO.
Служба PDO в сравнении с PGN и SPN J1939Разве служба PDO немного похожа на PGN и SPN J1939?
Да, в некоторой степени это похоже на то, как конкретная группа параметров J1939 (PG) будет содержать несколько SPN / сигналов (также называемых параметрами данных) в 8 байтах данных.Фрейму CAN J1939 не нужно тратить байты данных на «декодирование» информации, потому что это известно соответствующим узлам (и внешними инструментами, например, через файлы J1939 DBC или стандарты PDF J1939). Проблема в том, что в CANopen эти «сопоставления PDO» часто настраивается и может быть изменен во время создания DCF и / или через службу SDO.
Подробнее о PDO см. В этой статье (стр. 5).
Регистрация данных CANopen – примеры использования
Поскольку CANopen является протоколом на основе CAN, можно записывать необработанные кадры CANopen с помощью регистратора данных шины CAN.
Например, CANedge позволяет записывать данные CANopen на SD-карту емкостью 8-32 ГБ. Просто подключите его к своему приложению, чтобы начать регистрацию – и обрабатывать данные с помощью бесплатного программного обеспечения / API.
учить большеДекодирование необработанных данных через файлы CANopen DBC
Поскольку CANopen основан на шине CAN, вы можете хранить свои правила декодирования CANopen в стандартизированном формате базы данных CAN, файле CAN DBC. Благодаря этому вы можете напрямую декодировать необработанные данные CANopen в программном обеспечении / инструментах API с открытым исходным кодом для CANedge, включая графический интерфейс asammdf, панели управления телематикой и инструменты Python API.
Обратите внимание, что у вас может не быть файла CANopen DBC под рукой, но правила декодирования кадра CANopen могут храниться в вашем EDS / DCF или в PDF-файле. В таком случае вы можете начать с нашего введения DBC, чтобы узнать, как создать файл CANopen DBC с нуля, используя различные бесплатные инструменты редактора.
Решения, такие как CANedge, позволяют использовать несколько сценариев использования протоколирования CANopen:
Регистрация данных узла CANopen
Как правило, регистрация данных CANopen может использоваться для e.грамм. анализировать оперативные данные. Регистраторы WiFi CAN также могут использоваться, например, для беспроводные SDO
Учить большеУправление складским парком
CANopen часто используется в вилочных погрузчиках EV / AGV на складах, где мониторинг, например, SoC помогает уменьшить поломки и продлить срок службы батареи
Учить большеПрофилактическое обслуживание
Промышленное оборудование можно контролировать с помощью логгеров IIoT CAN в облаке для прогнозирования и предотвращения поломок на основе данных CANopen
Учить большеЧерный ящик для диагностики машин
Регистратор CAN может служить «черным ящиком» для промышленного оборудования, предоставляя данные для e.грамм. диагностика споров или редких проблем
Учить большеНеобходимо регистрировать / передавать данные CANopen?
Получите свой CAN-логгер сегодня!
Рекомендуем
Основы 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), которые будут объяснены позже в этом документе.
Основными типами данных, включенными в словарь объектов, являются: Boolean, 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 + Node ID. Идентификатор узла указывает, с какого ведомого узла поступает сообщение. В примере, показанном ниже, главный узел (клиент SDO) отправляет сообщение в сеть с CAN-ID 603h. Хотя все узлы видят это сообщение, все узлы, кроме целевого узла, игнорируют его, потому что сообщение не предназначено для них.Целевой узел понимает, что сообщение с идентификатором 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 часто используются для передачи постоянно обновляемых данных.
Охрана и сердцебиение
Спецификация CANopen требует, чтобы узлы использовали какой-либо метод, чтобы проверить, является ли узел «живым» или нет. Доступны два метода: защита узла и тактовые импульсы, причем последний метод является предпочтительным.
В протоколе пульса узел CANopen периодически отправляет сообщение пульса, которое позволяет мастеру CANopen или потребителю пульса знать, что узел все еще жив. Если контрольное сообщение не приходит в течение определенного периода времени, мастер может предпринять определенное действие.Таким действием может быть сброс узла или сообщение об ошибке оператору. Контрольное сообщение идентифицируется CAN-ID 0x700 + ID узла, где первый байт данных равен 1110.
В протоколе защиты узлов мастер CANopen опрашивает подчиненные узлы для получения информации об их текущем состоянии. Если узел не отвечает в течение определенного периода времени, мастер предполагает, что узел мертв, и примет меры.
Протокол контрольных сообщений является предпочтительным методом, поскольку он имеет меньше накладных расходов, чем защита узла.
Экстренные сообщения
Каждому узлу в сети CANopen назначается одно аварийное сообщение (EMCY), которое сообщает состояние узла. Обратите внимание, что протокол пульса и защиты узла предназначен для передачи сообщений о сбоях связи, в то время как экстренные сообщения используются для передачи ошибок внутри узла (например, сбоя датчика). Сообщение EMCY идентифицируется COB-ID 80h + Node ID. Часть данных сообщения EMCY содержит информацию о произошедшей ошибке.
CAN в автоматизации (CiA): протокол PDO
Объекты данных процесса (PDO) используются в CANopen для передачи высокоприоритетной информации управления и статуса. PDO состоит из одного кадра CAN и передает до 8 байт чистых данных приложения. Разработчики устройств должны оценить объем данных процесса, которые устройство должно получать и передавать. Основываясь на результате этого процесса оценки, они должны предоставить соответствующее количество принимаемых и передаваемых PDO в устройстве.
Наборы параметров PDO
В случае, если предполагается, что устройство поддерживает передачу / прием PDO, соответствующие наборы параметров для этого PDO должны быть предоставлены в объектном словаре этого устройства. Для одного PDO требуется набор параметров связи (запись параметра связи PDO) и набор параметров отображения (запись отображения PDO).
Среди прочего, параметры связи указывают идентификатор CAN, который используется этим PDO, и инициирующее событие, которое требует передачи соответствующего PDO.Параметры отображения указывают, какая информация из локального словаря объектов должна быть передана и где полученная информация должна быть сохранена.
Параметры связи для принимаемых PDO располагаются в диапазоне индексов 1400 h – 15FF h , а для передаваемых PDO – в диапазоне 1800 h – 19FF h . Связанные записи сопоставления управляются в диапазонах индексов 1600 h -17FF h и 1A00 h – 1BFF h .
События запуска PDO
Определены следующие триггерные события для PDO:
Управляется событием или таймером: Внутреннее событие устройства запускает передачу PDO (например, когда значение температуры превышает определенный предел; истекает время таймера события и т. Д.).
Запрошено дистанционно: Поскольку PDO состоят из одного кадра данных CAN, их можно запросить через запрос удаленной передачи (RTR).
Синхронная передача (циклическая): Передача PDO может быть связана с приемом сообщения SYNC.
Синхронная передача (ациклическая): Эти PDO запускаются определенным событием, зависящим от устройства, но передаются с приемом следующего сообщения Sync.
Отображение PDO
ОтображениеPDO определяет, какие объекты приложения передаются в PDO. Он описывает последовательность и длину отображаемых объектов приложения. Сопоставление объектов приложения описано в соответствующих записях словаря объектов CANopen для каждого PDO.CANopen различает три типа отображения PDO:
Статическое отображение PDO: В случае, если статическое отображение поддерживается для PDO, содержимое PDO строго предопределено производителем устройства и не может быть изменено через интерфейс CANopen.
Отображение переменных PDO: Отображение переменных PDO описывает, что записи отображения PDO могут быть изменены во время предоперационного состояния NMT.
Динамическое сопоставление PDO: Устройство поддерживает динамическое сопоставление, если записи сопоставления PDO в объектном словаре CANopen также могут быть изменены во время рабочего состояния NMT.
Процедуры сопоставления PDO
В отличие от строго заранее определенного отображения, разработчики устройств могут предложить изменить отображение PDO. В CANopen такая гибко настраиваемая возможность отображения PDO называется переменным или динамическим отображением PDO. Если поддерживается переменное или динамическое отображение, записи отображения PDO могут быть изменены только с помощью определенной процедуры отображения:
- Установить недопустимый PDO путем переключения бита 31 в соответствующей записи COB-ID.
- Установите недопустимое сопоставление PDO, записав 00 h в субиндекс 00 h связанных записей сопоставления.
- Настройте желаемое сопоставление PDO.
- Установить субиндекс 00 h соответствующего индекса отображения на количество отображаемых объектов.
- Коммутатор PDO действителен с помощью бита 31 в соответствующей записи COB-ID.
CANopen FD – Искусство встраиваемых сетей
CANopen FD является усовершенствованием CANopen, системы связи, основанной на CAN FD.Он включает протоколы более высокого уровня и спецификации профиля. CANopen FD был разработан с особым вниманием к использованию более высокой пропускной способности CAN FD за счет сохранения ключевых атрибутов CANopen. CANopen FD предлагает высокую пропускную способность, что является преимуществом для облачных приложений, требующих обработки данных. Встроенные системы, которые могут быть изменены конечным пользователем во время работы системы, получают выгоду от нового USDO, которое позволяет динамически и просто устанавливать кросс-коммуникацию в одноадресной и широковещательной рассылке.
Как и следовало ожидать, широкий спектр микроконтроллеров со встроенными контроллерами CAN FD, CANopen FD доступен как улучшенная, гибкая, прочная и надежная среда связи для областей применения, где CANopen используется сегодня.
CANopen FD освобождает разработчика от работы с деталями, специфичными для оборудования CAN, такими как битовая синхронизация и фильтрация приема. Он предоставляет стандартизированные объекты связи (COB) для критичных по времени процессов, конфигурации, а также данных управления сетью.
CANopen FD и IIoT
Основными задачами будущих встроенных сетей являются интеграция встроенных сетей в облачные приложения, предоставление большого количества «полезных данных» для «приложений больших данных», удовлетворение растущих требований безопасности и т. Д.CANopen FD был разработан с учетом требований будущих встроенных сетей. Высокая гибкость связи благодаря мощному USDO позволяет, например, шлюз CANopen FD / IIoT простой доступ к любому элементу данных, обеспечиваемый встроенной сетевой архитектурой CANopen FD. Помимо передачи любого размера данных в локальной сети, встроенная возможность маршрутизации CANopen FD позволяет также получать доступ к устройствам CANopen FD, подключенным к удаленной сети.
CANopen FD сохраняет словарь объектов CANopen практически неизменным.Поэтому CANopen FD может легко использовать согласованные данные приложения, указанные на более чем 10 000 страницах существующих и широко распространенных профилей устройств и приложений CANopen. Таким образом, устройства CANopen FD могут поддерживать высокую степень возможности Plug and Play, а облачные приложения могут сохранять вычислительную мощность, поскольку форматирование данных упрощается.
Повышенная полезная нагрузка, обеспечиваемая протоколами CANopen FD, ориентированными на транспортировку данных, позволяет удовлетворить передовые концепции безопасности, а также функциональной безопасности.
Коротко о CANopen FD
CANopen FD предоставляет несколько объектов связи, которые позволяют разработчикам устройств реализовать желаемое сетевое поведение в устройстве. Коммуникационные объекты PDO, USDO, SYNC, TIME, EMCY, NMT и Error Control позволяют устройствам CANopen FD передавать конфигурацию и обрабатывать данные в широковещательном и одноадресном режиме, отображать внутренние ошибки устройства или влиять на поведение сети и управлять им. Функции CANopen FD позволяют легко управлять динамически изменяющимися сетевыми настройками.Внутренняя структура устройства CANopen FD идентична структуре, определенной в CANopen. Таким образом, пользователи CANopen могут повторно использовать большую часть своих знаний о CANopen, если они используют CANopen FD.
CANopen FD нижние уровни
CANopen FD требует реализации физического уровня в соответствии с ISO 11898-2: 2016, способного поддерживать скорость передачи до 5 Мбит / с. Реализации согласно ISO 11898-2: 2016 могут поддерживать режим пониженного энергопотребления, а также возможность выборочного пробуждения. Поэтому CANopen FD уже поддерживает сложные концепции энергосбережения.Что касается кабельной разводки и топологии, CANopen FD относится к серии спецификаций CiA 6xx. В дополнение к рекомендациям по настройке сети на основе CAN-FD, ответственный IG CAN FD в настоящее время определяет параметры кабеля, которые должны поддерживаться кабелями, используемыми для сетей на основе CAN-FD.
Битовая синхронизация для CANopen FD представлена в CiA 1301. Для тактовых импульсов CAN с частотой 80 МГц CANopen FD определяет битовые скорости для арбитража и фазы данных. Эти заданные битовые скорости можно легко комбинировать, потому что все заданные битовые скорости основаны на одном и том же временном интервале.Для обеспечения перспективности CANopen FD поддерживает скорость передачи данных до 10 Мбит / с на этапе передачи данных, однако современные реализации CAN разработаны для поддержки скорости передачи данных до 2 или 5 Мбит / с.
Канальный уровень CANopen FD основан на ISO 11898-1: 2015 и использует для всех протоколов связи формат кадра CAN FD. CANopen FD не различает, передаются ли данные в кадрах CAN FD с переключением скорости передачи данных или без него. В отличие от CANopen, CANopen FD не поддерживает удаленные кадры CAN.
Внутренняя архитектура устройства
Устройство CANopen FD состоит из трех логических частей. Стек протокола CANopen FD управляет обменом данными через сеть CAN FD. Прикладное программное обеспечение обеспечивает функции внутреннего контроля, а также интерфейс с аппаратными интерфейсами процесса. Словарь объектов CANopen FD взаимодействует как с протоколом, так и с прикладным программным обеспечением. Он содержит ссылки (индексы) для всех используемых типов данных и хранит все параметры связи и приложения.
Словарь объектов CANopen FD наиболее важен для настройки и диагностики устройства CANopen FD. В качестве внутренней ссылки устройства используется 16-разрядный индекс, который задается как 4-значное шестнадцатеричное значение. Диапазон индексов от 1000 h до 1FFF h предоставляет ссылки на все параметры, которые определяют поведение связи CANopen FD устройства CANopen FD. Диапазон индексов от 2000 h до 9FFF h предоставляет ссылки на все параметры, связанные с приложением.CANopen FD различает собственные параметры (диапазон индекса от 2000h до 5FFFh) и стандартизованные параметры (диапазон индекса от 6000 h до 9FFF h ).
Протоколы CANopen FD
Стек протоколов CANopen FD управляет связью CAN FD устройства CANopen FD. Стек протоколов CANopen FD предоставляет несколько COB CANopen FD для настройки, диагностики и управления. Таким образом, пользователь CANopen FD может передавать управляющую информацию, реагировать на определенные ошибки или влиять на поведение сети и управлять им.CANopen FD очень масштабируем, и стек протоколов CANopen FD может быть адаптирован к требуемой функциональности, с одной стороны, и к доступным ресурсам на микроконтроллере, с другой стороны. Возможности, поддерживаемые устройством CANopen FD, можно оценить, проверив наличие связанных записей словаря объектов, описывающих поведение связи.
Протоколы CANopen FD включают:
CAN в автоматизации (CiA): история CANopen
В ноябре 1994 года CiA опубликовала самую первую версию спецификации CANopen: CiA 301 – один из самых успешных исследовательских проектов Esprit.История успеха CANopen уникальна, потому что ее продвигал не один крупный поставщик, а множество средних и малых компаний, а также машиностроителей.
| 1993 | Предварительная разработка CANopen в рамках проекта Esprit под председательством Bosch |
| 1994 | Публикация предшественника CANopen на основе CAL-коммуникационного профиля версии 1.0 |
| 1995 | Публикация CiA 301, прикладной уровень CANopen и коммуникационный профиль 2.0 |
| 1996 | Публикация CiA 301, прикладного уровня CANopen и коммуникационного профиля 3.0 |
| 1999 | Публикация CiA 301, прикладной уровень CANopen и коммуникационный профиль 4.0 (EN 50325-4) |
| 2007 | Публикация CiA 301, прикладного уровня CANopen и коммуникационного профиля 4.2 (только для членов CiA) |
| 2011 | Публикация CiA 301, прикладной уровень CANopen и коммуникационный профиль 4.2 (общедоступный) |
Вначале спецификация CANopen называлась «коммуникационный профиль на основе CAL для промышленных систем». Он был разработан под эгидой Esprit (Европейская стратегическая программа исследований в области информационных технологий), исследовательской программы Европейского сообщества. Название проекта 7302 было ASPIC, сокращенно от «Системы автоматизации и управления производственными установками, использующие концепцию монтажной шины». Задача заключалась в разработке управляющих архитектур и устройств, обеспечивающих гибкие и модульные комбинации существующих производственных ячеек.Исследователи во главе с доктором Мохаммадом Фарси (Университет Нью-Касл) и Стефаном Рейтмайером (Bosch) решили использовать протокол CAN Application Layer (CAL), разработанный CiA. CAL была чисто прикладным подходом в соответствии с моделью OSI (взаимодействие открытых систем). Тем не менее, это был в некотором отношении академический подход и имел разные отцы: его основной вклад был внесен Томом Сутерсом (Philips Medical Systems), а также профессором доктором Конрадом Эчбергером и профессором доктором Вольфхардом Лоуренцем, которые работали в немецких университетах на Прикладная наука.Конечно, идеи внесли и другие члены CiA.
Целью проекта ASPIC была разработка простого в реализации прикладного уровня, предназначенного для управления встроенными машинами. Под руководством Bosch несколько компаний (Moog, ADL Automation и J.L. Automation) и институтов (Университет Ньюкасла и Университет прикладных наук Ройтлингена) разработали первую версию того, что сегодня известно как CANopen. Основными участниками были д-р Мохамад Фарси и проф. Д-р Герхард Грюлер.В первой версии уже определены PDO (объекты данных процесса) и SDO (объекты данных службы). Была введена синхронная передача PDO, а также сообщений управления сетью (NMT) и аварийных сообщений.
В первые дни CANopen, CAN Remote Frames все еще пользовались популярностью, поэтому на их основе была основана Node Guarding. Позже Node Guarding был заменен механизмом Heartbeat. Первые сети CANopen также использовали удаленно запрашиваемые PDO. В настоящее время CiA рекомендует вообще не использовать удаленные фреймы.
Спецификация CANopen, опубликованная как CiA 301, была одним из самых успешных исследовательских проектов Esprit. Одна из причин заключалась в том, что спецификация была передана CiA для дальнейшей разработки и обслуживания. С самого начала несколько компаний реализовали протокол более высокого уровня в реальных приложениях. Конечно, прежде чем CANopen стала стабильной спецификацией, потребовалось несколько обзоров и обновлений. Версия 3.0 была первым выпуском, который использовался в продуктах и системах. Эта версия действовала с 1996 по 1999 год.Некоторые приложения до сих пор используют эту версию.
CANopen можно рассматривать как прикладной уровень малых и средних поставщиков. Это единственная независимая промышленная система связи, не продвигаемая ни одной лидирующей компанией на рынке. Его также можно рассматривать как решение системных проектировщиков, потому что некоторые машиностроители выбрали этот подход, чтобы быть независимыми от поставщиков. Среди этих машиностроителей – Heidelberger и Siemens Healthcare. В 1995 году CiA представила на своем стенде в Ганновере самый первый мультивендорный демонстратор CANopen, оснащенный продуктами от Moog, Selectron и других.
.