Смелое заявление :smile: Только если смотреть “логи” работ большинства из обсуждаемых здесь адаптеров, то сбой как правило происходит в библиотеках PassThru. T.E. адаптер продолжает слать данные, а библиотека по какой-то причине не может их обработать, а это уже уровень компа. Кроме того, время ожидания ответа, устанавливаемое Techstream такое что за это время, приходит, по крайней мере у меня, от 3 до 8 блоков в зависимости от адаптера поэтому если библиотека написана “правильно”, то потеря одного блока ни как не влияет на работу Techstream в целом.

Цитата:

Сообщение от alflash (Сообщение 629963) За несколько лет пользования OP2.0 (XP, 32) не было ни одного прокола (конечно, если правильно выбраны Area и Option): [Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]

Цитата:

Сообщение от alexno12345 (Сообщение 630031) Не соглашусь. ОП2 не держит дату на некоторых авто, идет потеря пакетов и выскакивает 0xa1050308, затем Techstream переключается на медленный режим опроса данных. Если 5-ти секундный интервал обновления даты устраивает, то вопросов нет. Но по нормальному (если бы не было потери пакетов) должно быть 300-600мс. Из имеющихся адаптеров нормально без потери пакетов работают только мангуст, carddaq-2 и сканматик. Для umxo: дело ТОЛЬКО в адаптере, ни ОС ни выбор рынка отношения к переодическому вылету 0xa1050308 не имеют - это потеря пакетов от ЭБУ при уже установленной связи.

"Не лукавьте, не лукавьте!
Ваша песня не нова.
Ах, оставьте, ах, оставьте!
Все слова, слова, слова..."

А. Дюбюк

Ну-ну :biggrin1:

[Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]

Оторопь берёт попросить фанов различных самодельных диагностических сканеров сравнить "покрытие" моделей и возможностей их идолов с возможностями Toyota Techstream V.12.20.O24:
[Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]

И не исключаю, что и диагностическая поделка может типа "терять пакеты", но только умалчивает об этом...
А бездоказательно подозревать виноватым в них OP2.0 это некомильфо.

Вы как то странно разделили адаптер и библиотеку PassThru для него. Их что разные конторы делают??? Давайте рассматривать их как одно целое.

А чтобы понять где происходит сбой во время просмотра даты TechStream нужно не только логи функций пасстру смотреть, но и ральный обмен на CAN шине. И сравнивать одни адаптер и другой, только тогда можно будет понять что в реальности происходит. Там очень важна ОЧЕРЕДНОСТЬ сообщений.

Если в кратце, не углубляясь во все подробности протокола обмена на примере ОП2 с блоком на шине CAN: во время потока данных от ЭБУ (он шлёт их сам, без запроса, т.н. быстрый режим) TechStream даёт ОП2 комманду отправить сообщение какое нибудь блоку и даёт на это таймаут скажем 100мс, и тут возникает проблема - ОП2 занят приёмом CAN сообщений от ЭБУ, и по этой причине не может отослать сообщине в заданное время - это приводит к вылету с ошибкой 00xa1050308. А объяснение всему этому - херово написанный диспетчер сообщений ISO15765, в каком месте я не знаю. Либо на стороне прошивке ОП2 либо их библиотеки PassThru. Быстродействие компа сюда приплетать не надо, для обработки подобных вещей хватит и 386-го компа.

Влияет, TechStream делает несколько (N) запросов, чтобы получить полный пакет данных, если он его не получает за N запросов - вылет с ошибкой 00xa1050308

И Сканматик-2 не "святой" - вылетает из проги и частенько.
Мангуст MFC Pro2 тоже страдает этим же , иногда.
За мои компы говорить нет смысла - Только Панасоники CF,вплоть до такого имеется

То что было под рукой - блок от AXIO [JP], к-лайновый, записал работу через ОП2 (офф. и дрова последние) и СМ2 (раз Вы его выделили, на видео с 2:22). Это тот случай, о котором писал umxo. На видео наглядно видно где лажает ОП2 - через каждые 11 секунд обрыв связи, и это с к-лайновым блоком, с CANовыми авто всё ёще более удручающе. Так что ваше утрерждение, что с ОП2 не было никогда проблем - очень сомнительно, на что я и хотел обратить внимание, не более.

[Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]

Доброго здоровья, джентльмены. Наконец-таки необходимо понять, для чего создан вообще был j2534. Здесь уже очень много об этом говорилось. Но ни до кого это так и не доходит. Очень прошу, назовите хоть одно устройство, поддерживающее j2534-4...
Чтобы об этом официально было заявлено в тех.характеристиках. Где оно? А ведь именно устройство j2534-4 ОФИЦИАЛЬНО (в описании этого стандарта) позиционируется как ДИАГНОСТИЧЕСКОЕ, А НЕ ПРОШИВОЧНО-ПРОСТРОЧЕЧНОЕ. И пофиг, что там заявляют официалы. Лукавят они с заявленными функциями.

Этот стандарт еще даже не вышел, говорить о нём ещё очень рано. И никто не знает о чем он будет. Когда допилят (а на это могут уйти годы) тогда и можно о чём то говорить. А пока даже не стоит забивать этим голову.

[Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]

Судя по названию это "Рекомендации разработчикам ПО (диагностичекого) для правильного использования API J2534-1/2", ну то есть не косячили чтобы. А к приборам этот стандарт не имеет никакого отношения (вроде бы), про приборы - это J2534-1 и J2534-2.

По сугубо моему никчемному мнению, разработка j2534-4 вообще лишена смысла. Ибо для диагностики во всем цивильном мире используется марочное дилерское оборудование. А этот долбаный j2534 ИЗНАЧАЛЬНО разрабатывался как универсальная прошивальщица. И у сытых дядей в мыслях не было создать для нищеты универсальный диагностический комплекс. Оригинальные производители не будут напрягать очко для адаптации своего софта под какой- то мангуст. Они будут усовершенствовать свой дилерский программно-аппаратный комплекс. Яркий пример - Ниссан Consult. Плевать они хотели на всякие сру. И что у вани из пырловки нет бабок на дилера. Поэтому разрабатывается БИЗНЕСОМ сегмент для таких как мы. И до тех пор всякие отстойные мангусты-суррогаты стоимостью в копейки ( для сытых дядей) и прочие девайсы будут лениво пережевывать пакеты пидов, шмидов и т.д.
Ни один официал не использует в работе всякий "дрютекный" отстой. Ни один. По крайней мере, в Японии. Так что, здесь профи и должны все это понимать и мириться с издержками нашего "бытовья". К сожалению.

В windows 8.1. При проведении активного теста, скрин которого Вы выложили я использовал уже СМ2, т.к. с Openport 2.0 были постоянные "отвалы". Причем использовал его (СМ2) с techstream в первый раз и был приятно удивлен, что он работает именно с данной ОС, с данным автомобилем и версией techstream лучше, чем OP2.0. С другими автомобилями (тойота и лексус) таких проблем с OP2.0 не наблюдалось. Но автомобили были в основном для американского рынка и меньше для европейского. Японцев у нас мало осталось уже.

Ой, а как вы объясните это
16:31:59.587 PassThruReadMsgs( NumMsgs 50, TimeOut = 200ms, ChannelID = 210635576 )
16:31:59.788 <47 RxD[1]/5 : 00 00 07 E8 E2 06 02 00 00 7F FC 66 E6 00 66 23 62 2E 01 00 00 30 68 28 28 78 28 00 0F 1D 23 11 0D 00 40 00 64 00 01 04 00 02 00 00 0A 7B 10
<60 RxD[2]/5 : 00 00 07 E8 E2 01 41 77 86 83 0A 85 00 98 42 00 BE 28 00 83 00 00 7E 5F 68 C7 00 AD 08 E7 66 35 F0 7F 20 00 78 28 51 28 00 00 16 4C 0A BB 07 A0 20 00 00 00 50 00 01 00 00 B2 00 77
<47 RxD[3]/5 : 00 00 07 E8 E2 06 02 00 00 7F FD 69 A6 00 66 23 40 2E 01 00 00 30 68 28 28 78 28 00 10 1D 23 11 0D 00 40 00 64 00 01 04 00 02 00 00 0A 7B 10
<60 RxD[4]/5 : 00 00 07 E8 E2 01 41 77 86 83 0A 8F 00 99 42 00 BE 28 00 83 00 00 7E 6A 68 B3 00 AD 08 E7 66 36 04 7F 20 00 78 28 51 28 00 00 16 4C 0A BB 07 A0 20 00 00 00 50 00 01 00 00 B2 00 77
<47 RxD[5]/5 : 00 00 07 E8 E2 06 02 00 00 7F FD 66 E6 00 66 22 A9 2E 01 00 00 30 68 28 28 78 28 00 12 1D 23 11 0D 00 40 00 64 00 01 04 00 02 00 00 0A 81 10
Result = ERR_TIMEOUT
где один запрос на чтение и 5 пакетов?