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...) ну и загрузка процессора возрастет.
Короткий ответ:
Наш драйвер не настолько высокопроизводительный, чтобы поддерживать такой частый обмен (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...) ну и загрузка процессора возрастет.