Объясните где ошибка

Если я правильно понимаю, сейчас предпринимается попытка собрать испытательный стенд, т.е. включение контроллера выполняется не в реально существующую CAN-сеть, а в локальную.
Интерфейс CAN0 контроллера действительно не имеет терминатора, т.к. предполагается что он должен подключаться к существующей CAN-сети, в которой обычно уже имеется терминатор. Интерфейс CAN1 предполагается подключать к отрываемому от сети устройству, со стороны которого терминатора может не быть, по этому CAN1 имеет терминирующее сопротивление на плате контроллера.
По диаграмме.
Драйвер шлюза работает асинхронно функциональной диаграмме. Регистры наличия принятых данных CAN обоих интерфейсов будут реагировать на получение сообщений только тех ID, которые попадают в диаграмму, например попадают в активированный отбор. Соответственно в описанном случае может и не включаться совсем - сообщения CAN0 не попадают в отбор, а сообщения CAN1 - вообще не попадают в диаграмму. Если включить режим логирования одного или обоих CAN интерфейсов (записать "1" в соответствующий регистр), то сообщения со всеми ID "логируемого" интерфейса будут попадать в диаграмму и регистры наличия принятых данных CANx будут реагировать на получение сообщенний.
Конфигурацию трансивера интерфейса CAN1 при скорости шины 500кБит следует установить HS.

В общем, проблему должна решить установка терминатора на CAN0.

Дополнительную информацию можно найти здесь.

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

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

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

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

Тем не менее использование фильтра CAN, чтобы в диаграмму попадал только нужный ID, рекомендуется.

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

Ну вот как то так получилось у меня....
Ловим пакеты ID 111   и все пакеты кроме 111 11 22 33 44 передаем на другой интерфейс. 
отбор для 222 - на вторую часть(фильтр в обратном направлении), на него пока не обращаем внимания.

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

ЭЭЭ, мне кажется или ваша диаграмма будет отправлять только то сообщение которое нужно сбросить? а все остальные - сбрасывать ? )))

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

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

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

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

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

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

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

с изящностью - разобрались ))
Инверсия - ясно, увидел и кружок на диаграмме и понял что рвало мой шаблон логического И, понял и как задается,  спасибо!

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

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

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

Ну что ж, коллеги, результат теста производительности - положительный.
блоки по 16 сообщений от целевого ID(попадающие в отбор) с интервалом 1 мс,
перерыв между блоками 2 мс,
2 теста по 8 мин
Общее количество трафика(в обе стороны) примерно 820-850 сообщений в секунду
потерь данных - нет.

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