Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
CANNY forum → Программируемые контроллеры CANNY 7.x (7, 7.2 duo, alfa, gamma, MGX, 7.3 echo) → Переполнение буфера CAN
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Лог после прогона пакетов из логов выше
Повторю вопрос - что значит прогон пакетов? Что их прогоняет? Что их передает? Вы записали какие-то данные в машине, а теперь передаете их в сеть к которому подключен интерфейс CAN0 контроллера на столе? Чем вы их передаете?
Открываю кан хакер, закидываю им в кан0 лог снятый с машины, и на кан1 уже читаю. Но перегруз появляется хаотично, не всегда в одном месте, иногда пол лога проходит и нет перегруза, иногда чаще. На машине когда всё установлено на место, иногда минуту нормально, иногда чаще. Ошибка по связи с блоком проявляется не каждый перегруз, но это скорее всего связано с тем что не всегда теряются "жизненно важные" пакеты для этого блока.
Спасибо за ответ.
Подобный метод испытаний небезупречен, но лог мы изучим. На практике получить переполнение при нормальной работе CAN сети крайне маловероятно.
"жизненно важные" пакеты для этого блока.
Вы определить, прием каких сообщений этот блок не подтверждает? Один из способов сделать это - посылать ему по очереди сообщения с различными ID и контролировать, прием каких сообщений он подтверждает (ACK), а каких нет.
Могу скинуть большой лог, там это более явно проявляется мне кажется. Но видимо на электронку, сюда не прикрепится.
Проверять подтверждение не пробовал, если честно даже не знаю как. С радостью проверил бы. С переполнением уже не первый раз сталкиваюсь, но в прошлые разы удалось заходить с тыла и решать задачку, а в этот раз все пути приводили к аналогичному переполнению.
У меня где то подобное было. Повесил 120 ом между H и L линией.
На плате подпаяны терминаторы, допом попробовал кинуть на шину со стороны одного блока на кан1, ещё 120 Ом. Результата не дало увы. Пробовал в диаграмме просто отключать дальнейшую трансляция 15ти пакетов, результат тот же. Видимо на входе перегрузка.
Приложенная мной ранее диаграмма, при отключенных регистрах запрета повторной передачи сообщений, на нашем стенде работает без пропусков, ошибок и переполнений при максимальной допустимой загрузке CAN 500k (~4000 сообщ/сек). Даже с добавлением в нее диагностического вывода данных (см.вложения)
Похоже, вам следует искать проблему в вашей сети CAN, ее узлах, методике экспериментов, инструментах получения данных, интерпретации данных эксперимента, архитектуре решения.
Полный список рекомендаций (особенно п.6!) см.здесь: https://canny.ru/docs/tips_tricks/solut … ents_tips/
По опыту могу сказать, что если узел для которого вы фильтруете сообщения, чувствителен к пропускам сообщений, то Регистр запрета повторной отправки сообщений CAN интерфейса подключенного к этому узлу должен быть установлен равным нулю. В общем случае, это влечет запрет на трансляцию этому узлу любых сообщений, прием которых он, по какой-либо причине никогда не подтверждает. Что в свою очередь требует однозначного выяснения ID таких сообщений и точной конфигурации шлюза.
Проверять подтверждение не пробовал, если честно даже не знаю как.
В каком смысле не знаете как?
Очевидный способ - используя осциллограф контролировать наличие или отсутствие доминантного уровня в соответствующем тайм-слоте сообщения CAN.
Но если знать, что по умолчанию, передающий узел автоматически повторяет передачу сообщения при каждой ошибке передачи. А отсутствие подтверждения приема хотя бы одним принимающим узлом приравнивается к ошибке передачи. (Что указано в спецификации CAN 2.0, которая настоятельно рекомендуется к прочтению каждому, чья деятельность, а тем более профессиональная деятельность, связана с CAN.)
То можно попытаться экспериментально установить наличие или отсутствие ACK и без использования осциллографа, в полном соответствии с п.7 рекомендаций, ссылку на которые я дал выше:
Соберите сеть из исследуемого устройства, контроллера, который передает по очереди с некоторой задержкой сообщения с разными ID и кан-монитора включенном строго в режиме Listen-only и кроме них не подключайте к этой шине ни одного узла. Правильно терминируйте сеть. И смотрите, будет ли автоматически многократно повторяться передача сообщений при однократной отправке.
GATEWAY.cfd 4.71 кб, скачивался 18 раз, последний раз 2024-09-06
RX.cfd 1.98 кб, скачивался 18 раз, последний раз 2024-09-06
TX.cfd 3.81 кб, скачивался 17 раз, последний раз 2024-09-06
stand.png 76.66 кб, скачивался 13 раз, последний раз 2024-09-06
Чтобы отправить ответ, вы должны войти или зарегистрироваться
CANNY forum → Программируемые контроллеры CANNY 7.x (7, 7.2 duo, alfa, gamma, MGX, 7.3 echo) → Переполнение буфера CAN