CANOPEN драйвер
Re: CANOPEN драйвер
В двух словах ситуация следующая - у нашего блока запрашивают регистры статуса, токи, напряжения и скорость по sdo. Помимо этого мы используем встроенную в can драйвер функцию - такую как вызов функции на определённую посылку, мы её используем,
чтоб диагностировать потерю связи - делаем счётчик пятисекундный и ждём команды Пуск по sdo. Верхний уровень нам посылает непрерывно посылку Пуска по sdo , по этой посылке мы сбрасываем пятисекундный счётчик , если посылка не пришла в течении 5 секунд, то мы формируем аварию - нет связи. И по логам - иногда мы уходим в аварию , хотя время между посылками Пуск было в районе 3сек(это время пишет верхний уровень в логи), поэтому интересует возможность ситуации, когда посылка в сети Пуск была, но контроллер её не прочитал, либо прочитал, но не ушёл в функцию обработки. Такое проскакивает редко, несколько раз в день
чтоб диагностировать потерю связи - делаем счётчик пятисекундный и ждём команды Пуск по sdo. Верхний уровень нам посылает непрерывно посылку Пуска по sdo , по этой посылке мы сбрасываем пятисекундный счётчик , если посылка не пришла в течении 5 секунд, то мы формируем аварию - нет связи. И по логам - иногда мы уходим в аварию , хотя время между посылками Пуск было в районе 3сек(это время пишет верхний уровень в логи), поэтому интересует возможность ситуации, когда посылка в сети Пуск была, но контроллер её не прочитал, либо прочитал, но не ушёл в функцию обработки. Такое проскакивает редко, несколько раз в день
Re: CANOPEN драйвер
В вашей ситуации, скорее всего контроллер посылку не получил. Для диагностики потери связи рекомендуется делать таймаут в 2.5 раза больше периода отправки. То есть если вы шлете старт с периодом в 3 секунды, то таймаут нужно ставить примерно 8 секунд. Либо старт слать чаще. Тогда пропажа одной посылки не будет критична, а вот если пропадет две посылки подряд, тогда уже делается вывод о потере связи.Rine писал(а): ↑31 май 2023, 16:50В двух словах ситуация следующая - у нашего блока запрашивают регистры статуса, токи, напряжения и скорость по sdo. Помимо этого мы используем встроенную в can драйвер функцию - такую как вызов функции на определённую посылку, мы её используем,
чтоб диагностировать потерю связи - делаем счётчик пятисекундный и ждём команды Пуск по sdo. Верхний уровень нам посылает непрерывно посылку Пуска по sdo , по этой посылке мы сбрасываем пятисекундный счётчик , если посылка не пришла в течении 5 секунд, то мы формируем аварию - нет связи. И по логам - иногда мы уходим в аварию , хотя время между посылками Пуск было в районе 3сек(это время пишет верхний уровень в логи), поэтому интересует возможность ситуации, когда посылка в сети Пуск была, но контроллер её не прочитал, либо прочитал, но не ушёл в функцию обработки. Такое проскакивает редко, несколько раз в день
Причина почему контроллер не получил сообщение может быть разной:
1. Наличие помех на линии и контроллер не принял сообщение Пуск.
2. Линия перегружена и верхний уровень не отправил свое сообщение Пуск (хотя думает, что отправил).
3. ПО в контроллере блокирует прерывания CAN на время большее, чем время между сообщениями SDO в линии CAN (в этом случае контроллер обработает только последнее принятое сообщение).
С уважением,
Дмитрий Шпак
Telegram: +79773608997
shpak@motorcontrol.ru
Инженер-программист ООО "НПФ Вектор", Москва.
Дмитрий Шпак
Telegram: +79773608997
shpak@motorcontrol.ru
Инженер-программист ООО "НПФ Вектор", Москва.
Re: CANOPEN драйвер
А скажите, пожалуйста, сколько из 32 буферов настроены на приём и сколько на передачу. И такой ещё вопрос - если идёт обращение к другому узлу по sdo(по другому id) , то эти запросы фильтруются, либо мы их принимаем и просто не реагируем на них. Я имею ввиду настроены ли фильтры на прием посылок в драйвере по Id блока
Re: CANOPEN драйвер
16 мэйлбоксов на прием и 16 на передачу.Rine писал(а): ↑31 май 2023, 18:34А скажите, пожалуйста, сколько из 32 буферов настроены на приём и сколько на передачу. И такой ещё вопрос - если идёт обращение к другому узлу по sdo(по другому id) , то эти запросы фильтруются, либо мы их принимаем и просто не реагируем на них. Я имею ввиду настроены ли фильтры на прием посылок в драйвере по Id блока
SDO, направленные другому узлу фильтруются на аппаратном уровне CAN (настроены фильтры на прием посылок, чтобы не загружать контроллер обработкой ненужных сообщений).
С уважением,
Дмитрий Шпак
Telegram: +79773608997
shpak@motorcontrol.ru
Инженер-программист ООО "НПФ Вектор", Москва.
Дмитрий Шпак
Telegram: +79773608997
shpak@motorcontrol.ru
Инженер-программист ООО "НПФ Вектор", Москва.
Re: CANOPEN драйвер
Вы пишите, что -
3. ПО в контроллере блокирует прерывания CAN на время большее, чем время между сообщениями SDO в линии CAN (в этом случае контроллер обработает только последнее принятое сообщение).
Но если 16 буферов на приём используется почему контроллер обрабатывает последнее сообщение, ведь в буффере хранятся ранние сообщения
3. ПО в контроллере блокирует прерывания CAN на время большее, чем время между сообщениями SDO в линии CAN (в этом случае контроллер обработает только последнее принятое сообщение).
Но если 16 буферов на приём используется почему контроллер обрабатывает последнее сообщение, ведь в буффере хранятся ранние сообщения
- Лашкевич Максим
- Сообщения: 342
- Зарегистрирован: 30 дек 2015, 10:38
Re: CANOPEN драйвер
Rine писал(а): ↑02 июн 2023, 09:02Вы пишите, что -
3. ПО в контроллере блокирует прерывания CAN на время большее, чем время между сообщениями SDO в линии CAN (в этом случае контроллер обработает только последнее принятое сообщение).
Но если 16 буферов на приём используется почему контроллер обрабатывает последнее сообщение, ведь в буффере хранятся ранние сообщения
Все буферы (мейлбоксы) настраиваются каждый на свой тип сообщений (на маску по CAN ID). Это не fifo. Поэтому, процитированное сообщение с пунктом 3 относится к случаю, если у вас пропадают однотипные сообщения (с одинаковым ID). Они должны сваливаться все один мейлбокс (в одну ячейку буфера), и если софт не успевает их оттуда доставать, то вот может воспроизвестись проблема. Но так часто сообщения идти в сети не должны.
С уважением,
Лашкевич Максим.
skype: maxlashk
Инженер-программист ООО "НПФ Вектор", Москва.
Лашкевич Максим.
skype: maxlashk
Инженер-программист ООО "НПФ Вектор", Москва.
- Лашкевич Максим
- Сообщения: 342
- Зарегистрирован: 30 дек 2015, 10:38
Re: CANOPEN драйвер
В общем случае, повторю совет моих коллег - такая большая загрузка линии неправильная. Если есть критически важные посылки, такие как работа/останов, то слать их нужно минимум в три раза чаще, чем период таймаута на "отказ связи". Если у вас таймаут 5 секунд, то надо раз в секунду (а не раз в три) слать эту команду. Бывает что из-за помех в сети CAN теряются сообщения при работе ШИМ. С этим мы часто сталкивались.
Копать внутрь драйвера CANOpen здесь не стоит. Отнеситесь к некоторой вероятности потери пакетов как к данности - и постройте коммуникацию, толерантную к потерям связи. Для отправки телеметрии рекомендуется запаковать данные в 8 бит на каждую переменную, сложить их в две 32х разрядных переменных (получится 8 объектов телеметрии) и настроить на эти объекты PDO. С точки зрения передачи данных будет в 8 раз компактнее, чем спрашивать по SDO 32х разрядные переменные.
Ниже фото примера форматов запаковки данных для одного из наших объектов в PDO и как эта запаковка делается в коде
Копать внутрь драйвера CANOpen здесь не стоит. Отнеситесь к некоторой вероятности потери пакетов как к данности - и постройте коммуникацию, толерантную к потерям связи. Для отправки телеметрии рекомендуется запаковать данные в 8 бит на каждую переменную, сложить их в две 32х разрядных переменных (получится 8 объектов телеметрии) и настроить на эти объекты PDO. С точки зрения передачи данных будет в 8 раз компактнее, чем спрашивать по SDO 32х разрядные переменные.
Ниже фото примера форматов запаковки данных для одного из наших объектов в PDO и как эта запаковка делается в коде
- Вложения
-
- 2023-06-02_10-27-36.png (28.97 КБ) 8508 просмотров
-
- 2023-06-02_10-30-14.png (43.86 КБ) 8509 просмотров
С уважением,
Лашкевич Максим.
skype: maxlashk
Инженер-программист ООО "НПФ Вектор", Москва.
Лашкевич Максим.
skype: maxlashk
Инженер-программист ООО "НПФ Вектор", Москва.
Re: CANOPEN драйвер
То есть буферы (мейлбоксы) настраиваются каждый на свой CAN ID(правильно я понимаю, что это номер узла?), и если блок имеет номер узла, например 1, то задействован один буфер? Но с другой стороны подо что остальные 15 буферов используются, ведь мы не можем одному контроллеру назначить 16 номеров узлов...Лашкевич Максим писал(а): ↑02 июн 2023, 10:17Rine писал(а): ↑02 июн 2023, 09:02Вы пишите, что -
3. ПО в контроллере блокирует прерывания CAN на время большее, чем время между сообщениями SDO в линии CAN (в этом случае контроллер обработает только последнее принятое сообщение).
Но если 16 буферов на приём используется почему контроллер обрабатывает последнее сообщение, ведь в буффере хранятся ранние сообщения
Все буферы (мейлбоксы) настраиваются каждый на свой тип сообщений (на маску по CAN ID). Это не fifo. Поэтому, процитированное сообщение с пунктом 3 относится к случаю, если у вас пропадают однотипные сообщения (с одинаковым ID). Они должны сваливаться все один мейлбокс (в одну ячейку буфера), и если софт не успевает их оттуда доставать, то вот может воспроизвестись проблема. Но так часто сообщения идти в сети не должны.
- Лашкевич Максим
- Сообщения: 342
- Зарегистрирован: 30 дек 2015, 10:38
Re: CANOPEN драйвер
Мейбоксы в CAN модулях микроконтроллеров обычно имеют настраиваемые фильтры для CAN ID принимаемого сообщения - маска (какие биты CAN ID имеют значения, какие могут быть любыми) и значение (для незамаскированных бит, чему должны быть равны биты). Конкретно для нашего драйвера CAN Open мейлбоксы на приём заняты под следующие сервисы:
В вашем случае, т.е. конкретно для сервиса Expedited SDO используется один мейлбокс (один буфер), принимающий все SDO-запросы в сети для данного номера узла, и драйверу нужно успевать из этого одного буфера забирать данные по прерыванию принятого SDO и давать ответ. Остальные принимающие мейлбоксы для этой задачи не задействованы.
- NMT
- SYNC
- EMERGENCY
- RPDO1
- ...
- RPDO8
- SDO ответы
- SDO запросы (не используется обычно)
- Heartbeat
- Блочная передача
В вашем случае, т.е. конкретно для сервиса Expedited SDO используется один мейлбокс (один буфер), принимающий все SDO-запросы в сети для данного номера узла, и драйверу нужно успевать из этого одного буфера забирать данные по прерыванию принятого SDO и давать ответ. Остальные принимающие мейлбоксы для этой задачи не задействованы.
С уважением,
Лашкевич Максим.
skype: maxlashk
Инженер-программист ООО "НПФ Вектор", Москва.
Лашкевич Максим.
skype: maxlashk
Инженер-программист ООО "НПФ Вектор", Москва.
Re: CANOPEN драйвер
Добрый день.
Ситуация следующая. Блок, использующий ваш драйвер CANOpen, длительное время работал. Но после очередной подачи питания появилась ошибка "Ошибка восстановления параметров CANopen из EEPROM" и никаким образом не сбрасывается. Подскажите пожалуйста о чем говорит эта ошибка, при каких условиях генерируется, можно ли ее замаскировать и как ее сбросить?
Благодарю.
Ситуация следующая. Блок, использующий ваш драйвер CANOpen, длительное время работал. Но после очередной подачи питания появилась ошибка "Ошибка восстановления параметров CANopen из EEPROM" и никаким образом не сбрасывается. Подскажите пожалуйста о чем говорит эта ошибка, при каких условиях генерируется, можно ли ее замаскировать и как ее сбросить?
Благодарю.