Получение и отправка пакета в CAN шину (Страница 1 из 2)

Можно, например, так (клик для увеличения):

Файл диаграммы: http://forum.canny.ru/files/evk.cfd

Несколько вопросов по диаграме:
Что дают регистры CAN IDH и CAN ERL если идентификация пакета идет все равно по регистру CAN IDL?
Как можно в режиме симуляции симулировать появление нужного пакета, чтобы увидеть реакцию контроллера?
Набросал диаграмму, попытка чтения пакета 05С3 3906 и отправка в шину пакета 05С1 0406 0000 0600
Правильно ли прописан пакет "05С3 3906"? На кан мониторе он выглядит именно так, дальше прочерки

По порядку.
Регистр IDH содержит старшую часть идентификатора CAN-сообщения и применяется при использовании в CAN-сети расширенных идентификаторов, например в автомобилях Honda (0x12F84010).
Регистр ERL содержит информацию о количестве байт данных в принятом (регистр принятого сообщения CAN ERL) или отправляемом (регистр сообщения передачи CAN ERL) сообщении. Во втором случае он сообщает драйверу CAN сколько байт нужно передать в следующем сообщени и обязателен к указанию при отправке. Кроме того, в этом регистре могут также содержаться специальные данные. Подробнее о драйвер CAN и его регистрах читайте в соответствующей главе руководства пользователя по интегрированной среде разработки CannyLab, доступном из программы при нажатии клавиши F1 или в каталоге  CannyLab (..\cannylab_v1_1\canny7manual.pdf).
В симуляторе эмулировать работу регистров пока нельзя. Внутрисхемный отладчик пока тоже не реализован. Для возможности изучения работы диаграммы в симуляторе можно временно замениить регистры контроллера на фиктивные линии-связи (сети), не подключаемые ни к чему кроме выводов блоков, где указывались регистры контроллера. В режиме симуляции этим линиям можно задавать значения используя пункт контекстного (клик на линию правой кнопкой мыши) меню "Установка занчения".
Приложенная диаграмма требует несколько небольших дополнений, которые были указаны в примере из первого ответа этой ветки.
Пакет "05С3 3906" в диаграмме указан верно.
Доработанный вариант диаграммы: http://forum.canny.ru/files/evk3.cfd
Диаграмма (кликабельно):

Добавленный блок №5 дополнительно идентифицирует сообшение проверяя что пинято именно 2 байта данных. Наличие в цепочке блока №7 позволяет обеспечить работу только с актуальными (принятыми в данный момент - свежими) полученными данными. Блок №16 устанавливает количество отправляемых байт данных - без него данные рагистров D0...D5 отправлены не будут.
Подробнее о работе с драйвером CAN читайте в соответствующей главе canny7manual.pdf (страница 116).

Блоки №№1, 16,18,19, 20 предназначены для заполнения регистров сообщения передачи CAN. Они выполняются на каждом цикле работы диаграммы без какого либо дополнительного условия и позволяют быть уверенным, что, в случае выполнения условия отправки данных в шину CAN, содержимое этих регистров будет именно таким. В общем случае, при необходимости отправки нескольких CAN-сообщений с разными данными (в зависимости от тех или иных условий) можно использовать для формирования посылок коммутаторы. Заполенные регистры сообщения отправки сами по себе ни на что не влияют и не отправляются в шину до установки значения "1" в регистр старта передачи CAN. Подробнее читайте в соответствующей главе canny7manual.pdf.
Настоятельно рекомендую при обработке принятых данных CAN использовать регистр наличия принятых данных CAN (блок 7 в примере evk3.cfd), иначе есть риск использовать неактуальные данные. Актуальность данных гарантироется только на одном цикле выполнения диаграммы, при наличии значения "1" в регистре наличия принятых данных CAN.
Да, для отправки 5 байт данных регистр сообщения отправки CAN ERL должен быть равен 5.
Использование Триггера D в данном случае почти ничем не отличается от использования блока "Копирование": только до первого выполнения условия установки значений в регистры отправки в этих регистрах будут значения "0", в последствии триггер их в любом случае там сохранит (смотрите описание работы триггеров в соответствующей главе canny7manual.pdf). Как написано выше, лучше использовать коммутаторы, но в данной диаграмме это бессмысленно. Блок "Копирование" - здесь самый экономичный вариант.
Использование индикации приема данных CAN с помощью светодиода контроллера - хорошее решение.
Для отправки данных в шину необходимо использовать регистр старта передачи данных CAN с детектором фронта (для единичногой отправки сообщения CAN при выполнении условия отправки), как это показано в примере evk3.cfd (блок №15).

а можно на данном примере показать, как сделать отправку 2 сообщений.
причем 1 - разово а 2- циклично? (положим что ID одинаковые)

Входные данные те же - один пакет

крогда на выходе блока 7 появится единица, единоразово  отправить один пакет в шину , и  зацикленно посылать второй пакет.
до тех пор пока в блоке 7 опять не появится единица

вопрос не в методике послыки данных а в общей логике.

я так понимаю целевая схема приближена к примеру 4

пишет что моя версия программы не совместима.

По рисунку посмотрел.
Правильно ли я понимаю логику, что в вашей схеме пока нет входящий сообщений,  с заданой в ШИМ периодчинотью будет слаться команда с выходов 0?

Спасибо, схема понятна, но я немного другое хотел.
Как обычно проблема с объяснением

Суть в том что при появлении устойчивого 1 на входе (например аналоговом)
Надо:
1 раз послать пакет  5с1  03 00
1 через секунду послать пакет  5с1  00 20
продолжать посылать пакет 5с1  00 20 с интервалом в 1 секунду пока на входе не появится 0

Как перебирать пакеты я понял, а вот как исключить из переборки один из вариантов - не могу придумать.

Работает!
Спасибо!

В целом подход верный. Вот вариант решения данной задачи.

В исходной диаграмме на выходе блока 7 была установлена инверсия - в прилагаемом файле исправлено.

Исправлено условие отправки данных в CAN.

Да, можно расширить и более чем на 15 - связывать коммутаторы между собой, как например показано здесь: http://forum.canny.ru/viewtopic.php?id=75.

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