Canopen узел застревает в состоянии preop - PullRequest
0 голосов
/ 24 января 2019

У меня есть 2 узла (x и y) на шине can с использованием canopen.Используя временный узел "z", я отправляю сообщение nmt, чтобы перевести все узлы в состояние preop, а затем команду, чтобы перевести y в рабочее состояние.Затем я отправляю кучу сообщений с расширенным идентификатором на шину, предназначенную для узла y, узел x не знает об этом в своем словаре.Во время отправки на y, мониторинг узла на узле x говорит, что он находится в состоянии preop.Все вроде нормально.По завершении отправки данных на узел y я посылаю команду перевести все узлы в рабочее состояние.Узел x застрял в состоянии preop в соответствии с его кодом состояния nmt.Отладка Я обнаружил, что rx fifo в canopen x переполнен.Следует ли игнорировать все эти расширенные сообщения в режиме preop?Я даже пытался в режиме остановки с теми же результатами застрял х.Что здесь происходит?

1 Ответ

0 голосов
/ 24 января 2019

Для любого узла шины CAN вы должны постоянно читать все входящие сообщения и игнорировать те, которые не представляют интереса. Настройки фильтра в контроллере CAN могут немного помочь, но для создания надежных приложений вы всегда должны быть готовы к тому, что любое сообщение CAN с любым идентификатором может появиться в любое время. Лучший способ убедиться в этом - постоянно читать буфер rx fifo и каждый раз продолжать чтение до тех пор, пока он не станет пустым.

Узел CANopen остается в предоперационном состоянии, пока есть ошибки. Необязательно, он может отправить сообщение EMCY, сообщающее природу ошибки, а затем еще одно со всеми битами, установленными в ноль, когда ошибка очищена. В этом случае мастер NMT должен подождать, пока сообщение EMCY не очистится, перед отправкой запустить удаленный узел.

...