В целом очень приятные ощущения от работы с вашим продуктом, хорошая концепция GUI, большое спасибо!
Обязательно будем пользовать в дальнейших разработках!

...И все таки, в вашем варианте при совпадении условия по данным( D1:D0=CONST D3:D2=CONST2) и при НЕ СОВПАДЕНИИ по IDL ретрансляции нет.

В исходной постановке задачи значился отбор только по 1 ID. Все остальные сообщения ретранслируются автоматически.
Даже если отборов будет больше и с ними нужно будет производить подобные действия, подход не изменится: пришел нужный ID, заданные байты данных равны установленным константам (через блок "И" с инверсией), отправка сообщения. Просто для нескольких ID эта конструкция будет размножена (скопирована) соответствующее количество раз, только со своими параметрами и потребуется еще несколько небольших изменений. Если на дополнительные отборы не будет установлен запрет ретрансляции, то принудительно отправлять сообщения с их ID не потребуется.

Предложенное решение было предоставлено для описанной изначально задачи. Сформулируйте алгоритм полностью - тогда можно будет найти оптимальный подход.

И все таки, в вашем варианте при совпадении условия по данным( D1:D0=CONST D3:D2=CONST2) и при НЕ СОВПАДЕНИИ по IDL ретрансляции нет.
В данном варианте (когда отбирается только 1 IDL), согласен, будет работать, можно даже совсем убрать блоки 6 и 7, но при расширении отбора будут проблемы.
В моем последнем - нужно убрать блоки НЕ и поставить еще одну инверсию.(ну либо убрать инверсию, о которой я не знал)

Если дорабатывать ПО то может, все-таки, сделать второй(или параллельный) круг отбора по значению? мне кажется это более перспективно, судя по количеству аналогичных задач на форуме. Хотя "сброс" тоже пригодится и, вероятно, сильно проще доработать.

По производительности - оттестирую в понедельник, дам знать.

Я вот подумал, можно наверное еще изящнее - подменить IDL "при разрешении ретрансляции" на шлюзе по умолчанию, и пакет уйдет "в никуда" как думаете?

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

Отсюда 2 вопроса:

• Можно ли сделать при равенстве данных из d1:d0 и d3:d2 заданным константам  дроп, а по умолчанию - передачу. или только ручная передача

• При загрузке шины 500кБод на 50% целевой ID засылает пакет каждые 2-3 мс - ручная обработка в диаграмме облом?

• Это потребует изменения системного ПО контроллера. Посмотрим что можно сделать.

• В контексте вашей задачи, вероятнее всего - да. Но возможны варианты.

Представленный мной вариант диаграммы (test_f_1a.cfd) работает корректно, тем более что в симуляторе как раз все и видно.
У блока №10 "Логическое И" на выходе установлена инверсия. Отправляться будут все сообщения у которых указанные байты (все 4, т.е. оба регистра принятого сообщения) НЕ равны заданным константам. Иначе на выходе блока №10, с учетом инверсии, будет 0 и в регистр начала передачи сообщения не будет записано значение 1.

Что показывает симулятор на диаграмме test_f_2.cfd? У блока №12 "Логическое И" осталась инверсия, которая снова инвертируется блоком "Логическое НЕ". Комбинация блоков №№6,11,8 вообще не позволит отправить ни одного сообщения с ID=0x111.

Все блоки и в симуляторе и в "реале" работают правильно. Ознакомьтесь с описанием языка CFD.

Наверное, более "изящный" вариант не подойдет.

Номера блоков - справочные, присваиваются по мере добавления блоков на поле диаграммы, могут быть изменены пользователем или автоматически при перенумерации и используются для возможности быстрого поиска нужного блока по номеру. Номера, дополнительно добавляемые в режиме симулятора (над блоком в правом углу), показывают порядок выполения элементов функциональной диаграммы. Все это есть в соответствующих разделах wiki.

ХМ....  а почему в дебагере  на логическом И два нуля дают 1 на выходе?  Чет ваще в дебагере запутка с логическим И....
В реале так же?

Допустим, добавим "НЕ"
При соблюдении только 1 равенства (по данным) - логическое "И" должно давать 0 - нет ретрансляции

Из вашего варианта получился такой, если конечно логическое И в реале работает правильно.

Я вот подумал, можно наверное еще изящнее - подменить IDL "при разрешении ретрансляции" на шлюзе по умолчанию, и пакет уйдет "в никуда" как думаете?
Это как раз и будет аналог "все ретранслируем, кроме сообщения прошедшего условия диаграммы"

Подскажите еще - номера имеют какое то значение?

Длительность выполнения данной диаграммы не более 1мс. ЮИ убирать нет необходимости и смысла, т.к. он дает хоть какую-то диагностику, что всегда полезно.

Что скажете, с точки зрения логичности и оптимизации?
Отмена ЮИ  (моргания светодиодиками) имеет смысл для ускорения?

В примере 3, из описания драйвера шлюза CAN, показан подход который можно использовать для данной задачи: получить в диаграмму сообщение с нужным ID через установленный отбор, запретить его ретрансляцию, обрабатывать данные в диаграмме. Т.е. после получения сообщения, при невыполнении условий "дропа" - перегрузить данные из регистров приема CAN0 в регистры отправки CAN1 и отправить сообщение в CAN1 на этом же цикле выполнения диаграммы; при выполнении условий "дропа" - не отправлять сообщение или отправить с нужными данными.

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

Идеальный вариант - отбор по ID ->отбор по данным из пакета -> обработка в диаграмме.

В случае если НЕ СТОИТ запрет ретрансляции для шлюза, пакет попавший в диаграмму можно сбросить(не передать)? или он передается независимо и можно только использовать данные из него?

...с транссивером просто игрался уже(искал трабл до запайки терминатора).....  Кстати, не нашел документацию по этой фиче...

Описание регистра конфигурации трансивера CAN1 есть в таблице "Регистры конфигурации драйвера CAN" описания драйвера CAN.

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

Дроп - это полный запрет ретрансляции? Если да, то может есть смысл не сбрасывать сообщение полностью, а просто заменять постоянно на нужные значения (статический шлюз)? Если нет, то тогда, наверное только третий вариант: обработка сообщений из диаграммы.

Не факт. При небольшой диаграмме, установке CAN-фильтров... должно справляться.

Базовый дроп пакета тоже сделал....

Теперь следующий вопрос - отбор по данным отсутствует, правильно? (может есть возможность допилить?  много аналогичных вопросов то) только по ID. Если мне нужно дропнуть(или модифицировать) пакет в зависимости от содержимого - нужно использовать ручную обработку в диаграмме, правильно?

Отсюда 2 вопроса:

• Можно ли сделать при равенстве данных из d1:d0 и d3:d2 заданным константам  дроп, а по умолчанию - передачу. или только ручная передача

• При загрузке шины 500кБод на 50% целевой ID засылает пакет каждые 2-3 мс - ручная обработка в диаграмме облом?