1.Скорость
2.Обороты ДВС
3.Тохл жидкости
4.Тимп форсунки
5.Напряжение бортсети/нагрузка на двигатель
6.Температура на впуске/Т жидкости АКПП
7.Бит отсечка топлива
8.Бит Check Engine
9.Ошибки ECU
10. Если есть отдельный параметр Расход топлива мгновенный, то его.

Судя по значениям vag-com , у меня протокол kw1281 c двигателем, с abs токой же, остальные не стал смотреть! Есть шансы или нет!??

Сделай лог работы с ваг-ком с помощью программы free-serial-port-monitor.exe аналогично ссылке выше, тогда точно ясно будет.

Упс... Почистил!
После трехдневного катания по украине - полет отличный!
Единственное - есть предложение сделать настраиваемым параметр AlwaysOnTop. Тогда будет проще его прятать средствами оболочки.

Только отписался, что все гуд - начались глюки )
Программа запускается, некоторое время работает, потом перестает обновлять показания. Т.е. показания застывают. При этом счетчик топлива продолжает расти.
Анализ логов показал, что последний ответ ЭБУ приходит не полностью, а только первые 8 байт. Причина неизвестна, но по идее должен быть перезапрос. Но его нет. Перезапуск программы помогает. Потом опять такая же фигня.
Логи в аттаче.

Придется увеличивать RTO. Похоже ECU захлебывается запросами и не успевает ответить - видать это вводит в ступор функцию расшифровки пакетов. У меня на тоете тож самое, если RTO маленьким сделать (пробовал 40).

Попробуем увеличить. А в случае таймаута не должен происходить повтор посылки?

По таймауту как раз определяется, что очередной пакет полностью пришел и начинается его расшифровка. В любом случае такого, чтобы пакет не полностью пришел от ецу не должно быть - значит ему нужно больше времени на обдумывание ответа.
P.S. Разобрал ситуацию подробно:
Вообщем в очередной раз подался запрос 82 11 F1 21 F0 95. За заданное время RTO ответ не пришел (пришло только эхо запроса TxD(Эхо):82 11 F1 21 F0 95). Программа начинает подавать следующий запрос, но в это время ецу оказывается уже начал отправлять данные. В результате программа передает 84 11 F1 18 00 FF 00 9D (8 байт), а в ответ ждет сначала эхо запроса (8 байт) а ей приходит предыдущий ответ, но программа этого не знает и выкусывает как ей кажется эхо запроса (8 байт ) - TxD(Эхо):8B F1 11 61 F0 00 10 2D - вот почему не до конца ответ :) При этом продолжение пакета может быть битым, так как на него наложился следующий запрос.

Прикольно.
Я у себя все пакеты (в том числе эхо) парсю, потом уже распарсенный пакет сравниваю с отправленным. Если совпадает - это эхо. И ес-сно сначала жду эхо, а потом уже ответ. Таким образом не может быть такого, чтобы от ответа откусили ожидаемое количество байт, а потом начали парсить.
Увеличил RTO вдвое. Полет нормальный.

Нашел и исправил ошибку, при которой сказанная выше ситуация приводит к зависанию панели. В новой версии обмен данными просто продолжится, забраковав неправильный прием. Для примера выложил лог своей панели с заведомо маленьким RTO.

P.S. To Alex_St - Стараюсь лишний проверок не делать, дабы не загружать процессор. Только самое необходимое, чтобы отбраковать неправильный прием.