Примеры передачи сообщений CAN (Страница 4 из 4)

Задача решается с использованием коммутаторов. Пример диаграммы во вложении.

Это предупреждение о несоответствии используемой версии CannyLab и системного программного обеспечения. Мы рекомендуем всегда использовать самые последние версии среды разработки и системного ПО.
Процесс записи/обновления системного ПО в контроллере описан в wiki.
Файлы актуального системного ПО контроллеров расположены в папке соответствующей версии среды разработки CannyLab в подпапке ccx (..\cannylab_vX_XX\ccx\).

Многое зависит от режима использования контроллера (стандартный, шлюз,...) и, соответственно, его типа (CANNY 7, CANNY 7.2 duo,...).
В стандартном варианте решение базируется на примере №3 данной темы форума. Немного меняется условие формирования и отправки сообщения, для возможности управления импульсными сигналами с одного канала контроллера (например, см.вложение: при появлении положительного потенциала выполняется однократная отправка сообщения).
Обратите внимание, что в примерах выполняется отправка всего сообщения, т.е. значения остальных байт, помеченных 0xXX, должны быть заданы пользователем (в виде констант или как-либо еще).

В общем виде прием сообщений из CAN рассмотрен в соответствующих разделах нашего online-справочника.

Отправлять в CAN по 1 байту не получится. Отправка выполняется целыми сообщениями.
Вариант решения: принимать и сохранять (с помощью Триггеров) сообщения с данным ID; по сигналу от кнопки отправлять сообщение, состоящее из данных последнего принятого сообщения с этим ID, но с заменой нужного байта.
Также следует учитывать периодичность следования этого сообщения в шине, а также то, что сообщения с этим ID уже шлет какой-то узел сети и однократной посылкой исправленного сообщения можно не добиться нужного результата.
Возможно, в данном случае следует использовать CANNY 7.2 duo в режиме CAN-шлюза.

Попробуйте применить подход из диаграммы, приложенной к сообщению на этой же странице выше:
https://forum.canny.ru/viewtopic.php?pid=8054#p8054

Данные всех без исключения входных регистров фиксируются каждый проход диаграммы: https://wiki.canny.ru/index.php?title=C … 0.B8.D1.8F
Время исполнения каждого прохода диаграммы зависит от ее размера и общей нагрузки на контроллер, может варьироваться в процессе работы и может быть получено из соответствующего регистра: https://wiki.canny.ru/index.php?title=C … 0.BC.D1.8B

И может быть с высокой точностью учтено в диаграмме: https://wiki.canny.ru/index.php?title=T … 1%81%D1%8B

Совсем жесткого тайминга в CAN не получить в принципе, так как шина не синхронная и в любой момент времени любой узел может начать передачу сообщения с более высоким приоритетом.

Если речь именно об аппаратных ошибках CAN - Error Frames, то в правильной сети такого быть не должно ни при каких условиях, если все узлы работают согласно стандарту, скорость всех узлов совпадает и шина правильно терминирована. Из каких узлов у вас состоит сеть, есть ли терминирующие резисторы и не применяются ли в ней случайно бесконтактные считыватели?

Диаграммы лучше прикладывать в виде исходников - CFD-фалов, а не картинок.

Благодарю за подсказку. Попробовал, работает, тайминги не плавают, держутся стабильно, но немного в плюс. Проверил пока на столе отправку 12-и сообщений в "пустую" шину и в шину, где есть внешний трафик. Заметной разницы в таймингах не обнаружил. В скриншотах значения могут быть заметно выше, потому что реальные значения изменяются динамически. Думаю, на стенде результат будет примерно такой же.

Константин, добрый день!

Подскажите, пожалуйста, чем обусловлено в примере отправки сообщений CAN №4 https://forum.canny.ru/files/example_se … 4_prev.png
последовательность срабатывания блоков для отправки сообщений:
а именно сначала "рег.старт передачи CAN" переводится в активное положение, а в следующем цикле когда он становится неактивным происходит заполнение буфера отправки сообщений данными.

Это правильная логика отправки сообщений или лучше все таки сначала заполнить буфер отправки сообщений данных CAN IDL, IRL и прочее и лишь потом поставить "рег.старт передачи CAN" в положение "1"? Удобнее всего это сделать в следующем цикле с помощью блока "буфер" судя по всему.

Скриншоты из симулятора прилагаю: