CANOPEN драйвер

Аватара пользователя
Лашкевич Максим
Сообщения: 342
Зарегистрирован: 30 дек 2015, 10:38

Re: CANOPEN драйвер

Сообщение Лашкевич Максим » 09 дек 2021, 14:15

Добрый день.
Короткий ответ:
Наш драйвер не настолько высокопроизводительный, чтобы поддерживать такой частый обмен (1мс). И вообще сеть CAN идеологически не предназначена для этого. Для такой частоты посылок желательно применять Ethercat и подобные сети.

Длинный ответ:
Функция co_1ms_calc вызывается с периодом 1мс. Процесс отправки PDO по таймеру контролируется в этой функции. При этом за один проход функции допускается упаковка и отправка только одной PDO. Это сделано для того, чтобы не перегрузить прерывание 1кГц на случай если пользователь захочет отправить сразу 8 PDO за раз. Таким образом минимальный период отправки одной PDO - 1мс. Если на отправку сконфигурировано 2 PDO, то минимальный период отправки каждого составит, соответственно, 2мс, так как в одном 1мс прерывании будет запаковываться и отправляться одно PDO, а очередь до второго PDO дойдет только в следующем 1мс прерывании.

Собственно, в наших типовых задачах управления ни разу не возникало необходимости отправлять PDO так часто. И объясняется это довольно просто. Загрузка CAN линии не должна быть 100%, так как в этом случае низкоприоритетные сообщения не смогут пробиться на линию (аппаратный арбитраж доступа к линии, основанный на идентификаторе сообщения) - то есть будут отказывать не только низкоприоритетные сервисы CANopen, такие как: heartbeat, SDO, но и доставка PDO сообщений будет не гарантированной.

Пример: пусть в сети есть 3 узла с номерами 1, 2 и 3 и каждый шлет первое PDO c периодом 1мс (идентификаторы PDO соответственно 0x181, 0x182, 0x183). Для простоты примера допустим, что пропускная способность шины - 2 сообщения за 1мс. В этом случае в сеть будут отправляться только PDO от 1 и 2 узлов, так как их идентификаторы приоритетнее (чем меньше идентификатор тем он приоритетнее в CAN линии). PDO сообщение от 3 узла не сможет пробиться на CAN линию, так как всегда будет проигрывать арбитраж 1 и 2 узлам.

Таким образом, при проектировании обмена по сети необходимо всегда оставлять запас в трафике, причем не только для PDO но и для работы других низкоприоритетных сервисов CANopen. Нормальной считается загрузка линии на уровне 50-70%. Если загрузка больше, то рекомендуется перейти на большую скорость CAN линии. В наших проектах, где на линии одновременно работает порядка 30 узлов период отправки PDO устанавливается в диапазоне 50-200мс...

Резюме:
1. Реализация драйвера не позволяет отправлять PDO чаще 1мс, но в обычной сети CANopen и не нужно быстрее.
2. Тем не менее вы можете обмануть систему и, например, вызывать co_1ms_calc чаще, например, на частоте 2кГц. При этом надо понимать, что все тайминги драйвера будут рассчитываться в 2 раза неправильно (соответственно потребуется скорректировать периоды отправки PDO, heartbeat...) ну и загрузка процессора возрастет.
С уважением,
Лашкевич Максим.
skype: maxlashk
Инженер-программист ООО "НПФ Вектор", Москва.

Илья!
Сообщения: 114
Зарегистрирован: 09 ноя 2018, 16:55

Re: CANOPEN драйвер

Сообщение Илья! » 09 дек 2021, 15:22

дык я и не пытаюсь отправлять PDO чаще, чем 1мс. Согласно установленным настройкам в Юниконе TPDO должны отправляться с периодом 1мс. Но на самом деле я вижу период 2мс. Для отправки сконфигурирован только один TPDO1, загрузку Юникон показывает 34%. Вот я и спрашиваю возможно ли получить в автоматическом режиме (с помощью настройки драйвера в Юниконе, не меняя код) период отправки TPDO в 1мс?
На значения Event Timer1 >= 2, драйвер реагирует адекватно, период меняется согласно уставке. А вот при установке Event Timer1 = 1, период равен 2мс
На 500кб загрузка составляет 17%. но период остается равным 2мс при Event Timer1 = 1

Аватара пользователя
Disona
Сообщения: 92
Зарегистрирован: 28 ноя 2015, 22:03
Откуда: Москва

Re: CANOPEN драйвер

Сообщение Disona » 09 дек 2021, 17:05

Добрый день.

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

Мы пересобрали библиотеки, но пока успеем их полностью проверить только завтра, поэтому на BitBucket пока не выкладываем, но вы можете скачать их вот отсюда.
С уважением,
Дмитрий Шпак
Telegram: +79773608997
shpak@motorcontrol.ru
Инженер-программист ООО "НПФ Вектор", Москва.

Илья!
Сообщения: 114
Зарегистрирован: 09 ноя 2018, 16:55

Re: CANOPEN драйвер

Сообщение Илья! » 09 дек 2021, 17:47

спасибо.
а не могли бы дать описание параметров в самой нижней строке Юникона: "Потеряно в сети" и "Потеряно в DLL" и других?

Аватара пользователя
Лашкевич Максим
Сообщения: 342
Зарегистрирован: 30 дек 2015, 10:38

Re: CANOPEN драйвер

Сообщение Лашкевич Максим » 09 дек 2021, 18:07

1мс таймер - тактирование драйвера CANOpen юникона, в этом миллисекундном таймере работает его машина состояний. Иногда таймер может лагать при зависании модуля связи или компа, для отслеживания.
RX - счётчик принятых посылок через модуль связи (любых)
RX_SDO - сколько из них SDO
Tx - счётчик переданных посылок юниконом
Потеряно в сети - когда юникон через библиотеку CANOpen (реализована в виде dll) отправил в модуль связи (марафон) запрос на чтение параметра через SDO, но через заданный таймаут ответ SDO от контроллера не вернулся.
Потеряно в DLL - когда юникон хотел запросить параметр через SDO и отправил запрос в библиотеку CANOpen (реализована в виде dll), но DLL по какой-то причине не смогла даже отправить запрос в сеть, например, из-за переполнения внутренних буферов, fifo, недоступности или занятости модуля связи и т.п.
Загрузка - загрузка сети в процентах, считается на основе количества принятых и отправленных устройством связи посылок в секунду по отношению к полному числу посылок, доступной на текущей скорости. Подсчёт реализован приблизительно, сильно его верификацией не занимались.
Успешных SDO - какое количество SDO запрос-ответ удалось юникону реализовать за секунду. Зависит как от загруженности линии связи, так и от количества параметров в открытой в юниконе группы параметров. Обычно если параметров меньше 50, то "Успешных SDO" определяется числом параметров, а если больше, то уже лимитировать будет канал связи.
x,y,z временные отладочные переменные юникона.
С уважением,
Лашкевич Максим.
skype: maxlashk
Инженер-программист ООО "НПФ Вектор", Москва.

Аватара пользователя
Disona
Сообщения: 92
Зарегистрирован: 28 ноя 2015, 22:03
Откуда: Москва

Re: CANOPEN драйвер

Сообщение Disona » 10 дек 2021, 14:16

Добрый день.

Мы проверили библиотеки. Как будто бы всё работает.
Обновили архив библиотек, а также перезалили проект с исправленной библиотекой.
С уважением,
Дмитрий Шпак
Telegram: +79773608997
shpak@motorcontrol.ru
Инженер-программист ООО "НПФ Вектор", Москва.

rasulikv
Сообщения: 6
Зарегистрирован: 24 авг 2017, 15:23

Re: CANOPEN драйвер

Сообщение rasulikv » 01 апр 2022, 11:59

Здраствуйте!
В canopen обычно предопределено 4 rpdo и 4 tpdo объекта, но стандарт не запрещает использование до 512 таких объектов, с учетом того, что в сети будет меньше, чем 127 устройств. В описании драйвера НПФ Вектор указано, что предопределено 8 объектов. Вопрос - будет ли работать драйвер, если в словаре забить порядка 40 объектов rpdo/tpdo и в сети будет не более 5 устройств?
Благодарю за ответ!

Аватара пользователя
Лашкевич Максим
Сообщения: 342
Зарегистрирован: 30 дек 2015, 10:38

Re: CANOPEN драйвер

Сообщение Лашкевич Максим » 01 апр 2022, 12:32

Здравствуйте, нет, не будет. Там эти все PDO привязаны к аппаратному драйверу CAN, а именно к меилбоксам, и это ограничение не обойти в текущей архитектуре. Ну и вообще чисто концептуально неправильно делать 40 PDO для одного узла, если есть столько много разных данных, которые надо передавать онлайн, то нужно подумать над уменьшением разрядности (мы обычно используем 8 бит на переменную) или выкачивать данные по SDO.
С уважением,
Лашкевич Максим.
skype: maxlashk
Инженер-программист ООО "НПФ Вектор", Москва.

Rine
Сообщения: 49
Зарегистрирован: 28 апр 2017, 09:25

Re: CANOPEN драйвер

Сообщение Rine » 14 авг 2022, 20:20

Здравствуйте, после подачи питания приходит посылка Heartbeat сервиса с данными 127. Это режим PREOPERATIONAL. Не могли бы Вы рассказать для чего нужен этот режим, и как долго устройство после подачи питания находится в данном режиме

Аватара пользователя
Лашкевич Максим
Сообщения: 342
Зарегистрирован: 30 дек 2015, 10:38

Re: CANOPEN драйвер

Сообщение Лашкевич Максим » 17 авг 2022, 11:18

Здравствуйте, скорее всего вы как-то модифицировали оригинальное ПО, если PREOPERATIONAL шлется постоянно . По стандарту CANOpen устройства должны сидеть в PREOPERATIONAL, пока внешний мастер или другие устройства не переведут его в operational, и тогда устройство начинает слать и принимать PDO. Второй вариант - устройства сами автоматически переходят в operational после включения, как сделано у нас. У нас устройство переходит в operational судя по коду после отправки первого Heartbeat. У вас остальные Heartbeat идут уже со статусом operational? Если да, то всё верно. Т.е. через секунду переходит.
С уважением,
Лашкевич Максим.
skype: maxlashk
Инженер-программист ООО "НПФ Вектор", Москва.

Ответить