[Закрыто] Извлечение данных наддува из OBDII VAG (Страница 1 из 5)

Приплыл

Модераторское: Предупреждение за флуд.

Пожалуйста, максимально развернуто задавайте ваши вопросы.

В общем все правильно. Кое-что лишнее. Кое-чего не хватает.
Фильтры на сообщения CAN устанавливаются только по ID. В данном случае это не расширенный ID и нужно использовать только фильтр по IDL.
2 раза проверять наличие данных CAN в одном выражении нет смысла, а вот проверка того, что это ответ именно на посланный запрос не повредит, т.е. проверить все байты данных (D0,D1,D2,D3) на соответствие ожидаемому ответу. Обратите внимание на перестановку местами байт данных в сообщении: в регистрах указываются D3:D2 и D5:D4. Немного подправленный вариант во вложении.

А если три сообщения Кан принять надо?
Еще и такое, данные состояния кнопки на руле.

Клавиша руля

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

А вот здесь Денис немного не понял.
Получается, чтобы подслушать в Кан-шине нужные мне данные, я должен сначала  туда же сообщение отправить, что бы вызвать эти данные?
В моем случае, запросом для ЗАДАННОГО являться:

     0x7e0  0x03 0x22 0x11 0xF1 0x55 0x55 0x55 0x55 175421    ."..UUUU

Для запросом для ФАКТИЧЕСКОГО являться:

     0x7e0  0x03 0x22 0x11 0xF0 0x55 0x55 0x55 0x55 25827    ."..UUUU

Правильно я понял?

В данном случае да. Это диагностический протокол, строящийся по принципу запрос-ответ.

Да это запросы. И на каждый приходят соответствующие ответы:
0x7e0  0x03 0x22 0x11 0xF1 0x55 0x55 0x55 0x55 - запрос заданного;
0x7e8  0x05 0x62 0x11 0xF1 0xХХ 0xХХ 0x55 0x55 - ответ со значением заданного, где ХХ - значения.
0x7e0  0x03 0x22 0x11 0xF0 0x55 0x55 0x55 0x55 - запрос фактического;
0x7e8  0x05 0x62 0x11 0xF0 0xХХ 0xХХ 0x55 0x55 - ответ со значением фактического, где ХХ - значения.

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

Именно по этому в самом начале мы и не могли рекомендовать шину для подключения при решении исходной задачи. Может оказаться что нужных данных, кроме как в диагностической шине, нет. Это нужно пробовать подключаться и смотреть. Кроме того в общем потоке данных нужная информация наверняка будет представлена в других ID и т.п.
При обычном подключении к CAN и активности шины в CAN(LIN) мониторе сразу будет идти поток данных. В этом случае запросов отправлять не нужно.
По кнопке руля. Все та же ситуация с запросами-ответами. Нужно использовать D-триггер для запоминания состояния кнопки до прихода следующего сообщения, сообщающего ее статус. Актуальность данных в регистрах CAN гарантируется только при наличии 1 в регистре принятых данных CAN. При этом одни и те же регистры используются для передачи в диаграмму данных при получении и других CAN-сообщений. В исходном варианте диаграммы состояние кнопки будет актуально только при получении соответствующего ответа на запрос.

Не установлена длинна отправляемых данных - регистр ERL. Его можно установить равным 8 - все 8 байт будут отправляться в запросе, хотя значащих всего 4. А в остальном подход верный.
По сути это уже 2 различных запроса просто с одинаковым ID. Можно расширить этот подход и до отправки нескольких разных ID (см. пример 4).

1 раз в секунду отправляются 8 сообщений с разными ID, разной длины и разного содержания. Небольшая модификация диаграммы примера 4 позволяет отправлять от 1 до 8 различных сообщений.

Есть регистр чтения ERL и регистр установки ERL (см. драйвер CAN).
Один используется для проверки длины принятого сообщения и некоторой дополнительной информации, а другой для установки длины отправляемого сообщения.