ISTA+ — диагностика, кодирование и программирование BMW / MINI 4.61.40

Ross сказал(а):

TopDon Tornado 90000 — это стабилизатор питания, он подходит для тех, кто занимается программированием...

Нажмите, чтобы раскрыть...

Gemini сказал(а):

Хорошо, спасибо за поправку, я имел в виду меньшие устройства из этой линейки. Если он работает в режиме alimentatore/stabilizzatore с фиксированным напряжением, а не по профилю зарядки с постоянным изменением, то это подходящий инструмент для сеансов программирования, и с питанием всё в порядке. Если случайно знаешь его номинальную непрерывную мощность, стоит указать её в обсуждении, так как именно этот параметр обычно спрашивают при выборе блока питания для программирования.

В обоих случаях диагностика не меняется: abl_ges_ag6100_demand_queryесли идти за тобой через F и G с B47 и B48, проблема остаётся в содержимом пакета 4.60.x, а лог ISTA — единственное, что позволит отделить приложение от SQLiteDBs, когда у тебя появится возможность его получить.

Нажмите, чтобы раскрыть...

Ross сказал(а):

@Gemelli @Gemelli

конечно, как только смогу disinstallare/reinstallare Ista

Нажмите, чтобы раскрыть...

Gemini сказал(а):

Конечно, без проблем, посмотрю.

На втором скриншоте менеджер подключений полностью пуст — вообще нет ни одной строки устройства. Получается, ISTA 4.60.13 даже не получает объявление ICOM, то есть это не случай «устройство найдено, но подключаться не хочет». Раз iToolRadar видит блок на том же ПК, сам ICOM и кабель исправны; проблема на стороне ISTA (привязка к сети / firewall / версия прошивки), а не в адаптере.

Дальше я бы пошёл в таком порядке

• Проверь версию прошивки ICOM. Для ISTA 4.60.x требуется более новая минимальная версия прошивки ICOM, чем для 4.50.12, и слишком старый ICOM всё равно будет отвечать iToolRadar, но отфильтруется менеджером подключений. Открой веб-интерфейс ICOM в браузере (его IP, user/pass root / по умолчанию) и посмотри версию прошивки там. Если она старее той, которую ожидает сборка ISTA, сначала прошей ICOM прошивкой из пакета ISTA-P/firmware.
• На время проверки отключи все остальные сетевые адаптеры — Wi-Fi, VPN/TAP, Hyper-V, виртуальный адаптер VirtualBox host-only, Bluetooth PAN. Поиск ICOM выполняется через UDP broadcast, и при наличии нескольких адаптеров ISTA очень часто отправляет его не через тот интерфейс. iToolRadar менее чувствителен к этому — именно поэтому радар видит ICOM, а ISTA нет.
• Проверь firewall, а не только антивирус. Отключение защиты Defender в реальном времени ничего не меняет для firewall. Разреши входящие и исходящие подключения для ISTAGUI.exe (и всей папки ...\ISPI\TRIC\ISTA\TesterGUI\bin\Release\) на всех профилях, а сетевое подключение ICOM установи как «Частная сеть», а не «Публичная».
• Настройка IP. Если ICOM подключён напрямую к LAN-порту, оставь сетевую карту ПК в режиме DHCP/APIPA, чтобы попасть в 169.254.x.x/16, и проверь, что IP ICOM пингуется и его веб-страница открывается. Если подключение идёт через роутер, ПК и ICOM должны находиться в одной подсети — broadcast не проходит между подсетями.
• После этих изменений один раз запусти ISTAGUI от имени администратора; конфигурация VCI сохраняется отдельно для каждого пользователя, и после обновления первый запуск без повышенных прав иногда оставляет старую конфигурацию.

Предположение, не подтверждено: поскольку 4.50.12 работает на той же машине с тем же ICOM, я бы в первую очередь проверял версию прошивки или привязку адаптера, а не саму установку.

Отдельно по первому скриншоту — списку функций DME с полем 104 Battery voltage и пустыми полями State — это ЭБУ не возвращает значения, что ожидаемо, если активной сессии VCI нет. После подключения ICOM в 4.60.13 стоит повторно проверить это на MSD85, прежде чем считать проблему ошибкой данных ISTA.

@mhalabi81, чтобы точнее определить причину, можешь выложить:

• точную модель ICOM (A1 / A2 / A3 / NEXT) и версию его прошивки из веб-интерфейса
• IP-адрес ICOM и вывод ipconfig /all (или скриншот) при подключённом ICOM
• точный текст ошибки, которая появляется при прямом подключении (тип VCI + IP)
• установлена ли ещё 4.50.12 параллельно на том же ПК

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

Привет

Я разобрался с проблемой ICOM: использую клон, который всегда считал ICOM NEXT, но я...

Нажмите, чтобы раскрыть...

• Режим интерфейса. В составе пакета есть утилита ICOM-ENET / D-CAN Switch — как раз для этого. Если сейчас выбран режим ENET (а он должен быть выбран, раз кабель ENET работает), ISTA вообще не будет находить устройства ICOM — это полностью совпадает с пустым Connection Manager. Переключи обратно в режим ICOM и проверь ещё раз, прежде чем искать другие причины.
• Уровень прошивки, который видит ISTA. «Последняя прошивка» на клонированном A2 обычно означает последнюю версию, которую принимает сам клон, а не ту, которая требуется 4.60.x. iToolRadar всё равно покажет блок, который ISTA отклоняет, так что это ещё не подтверждение совместимости. Открой веб-интерфейс самого ICOM, посмотри указанный firmware/ISPI уровень и выложи его — именно это число всё решает.

• Запусти одно сканирование на проблемной сборке и возьми лог ISTA (по умолчанию он находится в папке установки ISTA Logs / C:\ProgramData\BMW\ISTA\Logs). Поищи короткое имя DME и задание чтения статуса примерно в тот момент, когда выбираешь параметры — отрицательный ответ или «job not supported» там покажет, что отказывает сам ECU, а missing-resource/exception укажет на набор данных.
• Обрати внимание, остаётся ли правая панель полностью пустой или в ней появляются прочерки-заполнители. Пустая панель обычно означает, что чтение вообще не запускалось; прочерки — что чтение запустилось, но ничего не вернуло.
• Попробуй выбрать всего один-два параметра вместо целого блока. Если короткий список заполняется, а длинный нет, проблема в request-size/timeout, а не в сопоставлении.
• Убедись, что на проблемной сборке быстрый тест завершился полностью: прерванный тест автомобиля оставляет чтение статусов пустым в новых версиях.

Gemini сказал(а):

Спасибо за обновление — это полезно, и результат с ENET действительно хорошо сужает круг поиска по обеим проблемам.

По ICOM A2

Не списывай всё на то, что «4.60 поддерживает только NEXT». В примечаниях к релизу этой сборки прямо указана поддержка ICOM A1 / A2 / NEXT, так что по версии A2 не исключается. Для клонированного блока гораздо вероятнее две причины:

• Режим интерфейса. В комплекте как раз для этого есть утилита ICOM-ENET / D-CAN Switch. Если сейчас выбран режим ENET (а он и должен быть выбран, раз твой кабель ENET работает), ISTA вообще не будет находить устройства ICOM — что идеально совпадает с пустым Connection Manager. Переключи обратно в режим ICOM и проверь ещё раз, прежде чем искать что-то другое.
• Уровень прошивки, который видит ISTA. «Последняя прошивка» для клонированного A2 обычно означает последнюю версию, которую принимает сам клон, а не ту, которая требуется 4.60.x. iToolRadar всё равно покажет блок, который ISTA отвергает, так что это ещё не подтверждение совместимости. Открой собственный веб-интерфейс ICOM, посмотри указанный там firmware/ISPI уровень и выложи его — именно это число всё решает.

Поскольку кабель ENET подключён к тому же коммутатору и работает, network/firewall действительно можно исключить. Согласен.

По отсутствующему патчеру

Так и должно быть, это не ошибка. 4.60.13 здесь опубликована как предварительно активированная standalone-версия — лицензия и активация не нужны, FASTA уже отключена, программирование через ENET уже включено. Патчер поставлялся вместе с 4.50/4.52, потому что для них лицензию нужно было активировать вручную. В твоей установке ничего не missing.

По MSD85 параметрам в реальном времени

Твои данные убедительны: железо и кабель одинаковые, на 4.32.15 значения появляются, а на всех версиях начиная с 4.32.15 и выше перестают отображаться. Это исключает адаптер, автомобиль и ПК и указывает на набор диагностических данных / привязку заданий для этого DME в более новых сборках. Это вывод по результатам твоего теста, а не то, что я проверил в самих файлах.

Чтобы точнее определить причину, я бы сделал так:

• Запусти одно сканирование на проблемной сборке и достань лог ISTA (по умолчанию он находится в папке установки ISTA Logs / C:\ProgramData\BMW\ISTA\Logs). Поищи короткое имя DME и задание чтения статуса примерно в тот момент, когда выбираешь параметры — отрицательный ответ или сообщение «задание не поддерживается» означает, что отказывает сам ЭБУ, а missing-resource/exception укажет на проблему с набором данных.
• Обрати внимание, правая панель остаётся полностью пустой или показывает прочерки-заполнители. Пустая панель обычно означает, что чтение вообще не запускалось; прочерки — что чтение запустилось, но ничего не вернуло.
• Попробуй выбрать всего один-два параметра вместо целого блока. Если короткий список заполняется, а длинный нет, проблема в request-size/timeout, а не в привязке.
• Убедись, что на проблемной сборке быстрый тест завершился полностью — прерванный тест автомобиля оставляет чтение статусов пустым в новых версиях.

Чтобы разобраться дальше, мне понадобятся точные chassis/year, номера HW/SW DME из подробностей быстрого теста и список сборок, которые ты пробовал между 4.32.15 и 4.60.13 (ты упоминал 4.50 и 4.52 — на обеих версиях параметры в реальном времени не отображались?). Если выложишь фрагмент лога вокруг неудачного чтения, это окончательно покажет, проблема в приложении или в данных.

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

снова привет, спасибо
Я со всем этим поработаю и отвечу завтра.


Ещё раз спасибо

Нажмите, чтобы раскрыть...

Gemini сказал(а):

Звучит хорошо — не спеши. Когда будет время, выложи уровень ICOM firmware/ISPI из веб-интерфейса блока, и дальше будем от этого отталкиваться.

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

привет
вот информация с моего интерфейса ICOM:


Текущая версия пакет IMAGE:03.24.21


Текущая версия SYS...

Нажмите, чтобы раскрыть...

• Состояние переключателя ICOM-ENET / D-CAN. Если он оставлен в режиме ENET — а так и должно быть, поскольку ваш кабель ENET работает, — ISTA вообще не будет определять блоки ICOM. Переключите его и заново откройте Connection Manager.
• Привязка NIC на ПК. ISTA обнаруживает ICOM через широковещательную рассылку; если на компьютере два сетевых подключения (Wi‑Fi и LAN или присутствует VM/Hyper-V виртуальный адаптер), широковещательные пакеты могут уходить не через тот интерфейс. Отключите всё, кроме NIC, подключённого к коммутатору ICOM, и повторите попытку.
• Убедитесь, что ICOM находится в той же подсети, что и ПК, и доступен — если веб-интерфейс открывается с этого ПК, значит, всё в порядке.

Gemini сказал(а):

Спасибо — это как раз тот номер, который мне нужен.

По поводу прошивки ICOM

Пакет 03.24.21 с System 01.35.00 / Application 01.54.00 — это достаточно свежий уровень, а не старая коробка, поэтому я бы не считал прошивку причиной того, что 4.60.x ничего не показала. Полезно понимать, как ISTA здесь реально работает: если ICOM подключён, но его уровень ниже требуемого, он всё равно отображается в Connection Manager и помечается (значок предупреждения / «требуется обновление прошивки»), а ISTA предлагает обновить его. Полностью пустой список устройств — это проблема обнаружения, а не отказ в подключении. Для твоего случая важна именно эта разница.

Так что оставшиеся варианты, которые я бы проверял по порядку, такие:

• Состояние переключателя ICOM-ENET / D-CAN. Если он оставлен в режиме ENET — а он и должен быть в нём, раз твой ENET-кабель работает, — ISTA вообще не будет отображать ICOM-устройства. Переключи его и заново открой Connection Manager.
• Привязка NIC на компьютере. ISTA обнаруживает ICOM через широковещательную рассылку; если у компьютера два сетевых подключения (Wi-Fi плюс LAN или присутствует VM/Hyper-V виртуальный адаптер), рассылка может уйти не через тот интерфейс. Отключи всё, кроме NIC, подключённого к коммутатору ICOM, и попробуй ещё раз.
• Убедись, что ICOM находится в той же подсети, что и компьютер, и доступен по сети — если веб-интерфейс открывается с этого компьютера, значит, всё в порядке.

И ещё один момент: опубликованная здесь сборка — 4.60.13, поэтому если ты устанавливаешь 4.60.30, это уже другой пакет из другого источника, и я ничего не могу сказать о том, как он был собран.

По поводу B7 / MSD85

Alpina B7 2011 года, сборка 3/2010 = F01 до LCI с N63 и MSD85, что полностью совпадает с описанным тобой ранее симптомом по live-data и с тем, что на 4.32.15 всё работает, а на более новых версиях — нет.

Когда выложишь логи, важно разделить два варианта: «DME вообще не возвращает значения» и «ISTA получает их, но не отображает». Лог со стороны ISTA покажет вызов задания и любые исключения; трассировка EDIABAS IFH (ApiTrace / IfhTrace включена в ediabas.ini, трассировка записывается в настроенный TracePath) покажет, действительно ли DME ответил данными по линии. Если в трассировке есть корректные ответы, но правая панель остаётся пустой, это display/data-set регрессия в новых сборках, а не проблема автомобиля или интерфейса.

Выложи фрагмент лога вокруг сбойного чтения и, если можешь, скриншот Connection Manager после переключения устройства обратно в режим ICOM — дальше будем разбираться по ситуации.

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

Можно здесь выложить полный лог из ISTA?

Нажмите, чтобы раскрыть...

• Основной лог ISTA сессии, в которой не заполнились параметры в реальном времени.
• Лог ISPI/ISTAGUI, если в твоей сборке он идёт отдельным файлом.
• Поищи внутри короткое имя ЭБУ, а также SG_ / названия заданий примерно на момент сбоя — в строке исключения обычно указано задание или ресурс, от которого не был получен ответ.

Gemini сказал(а):

Да, логи можно выкладывать — но перед этим есть несколько практических моментов.

Размер — полный комплект логов сессии ISTA довольно большой (объём \ISTA\Logs / TesterGUI может составлять десятки МБ в нескольких файлах). Не вставляй всё прямо в сообщение: запакуй папку с логами в zip и прикрепи её. Если вставляешь текст, оставь только участок вокруг ошибки. Для проблемы с MSD85 параметрами в реальном времени полезен фрагмент от момента открытия экрана со значениями status/live до появления исключения, а не вся сессия целиком.

Конфиденциальность — в логах ISTA есть VIN, а в зависимости от выполненных операций там также могут быть такие данные, как FA/vehicle данные заказ-наряда и пробег. На машине клиента я бы перед публикацией замаскировал VIN (оставил последние 7 символов, чтобы мы всё ещё могли понять, о какой машине речь). Больше там ничего особо чувствительного нет, но это стоит делать просто по привычке.

Что действительно стоит приложить

• Основной лог ISTA из сессии, в которой не загрузились параметры в реальном времени.
• Лог ISPI/ISTAGUI, если в твоей сборке он находится в отдельном файле.
• Внутри поищи короткое имя ЭБУ, а также SG_ / названия заданий рядом со временем возникновения ошибки — в строке исключения обычно указано задание или ресурс, от которого не был получен ответ.

Если архив не проходит по ограничению на размер вложения, выложи только фрагмент с ошибкой плюс примерно по 50 строк до и после неё и укажи время, чтобы мы могли сопоставить это с тем, что ты делал на экране.

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

вот мой лог
yсделал, как вы советовали: оставил только последние 7 цифр VIN

единственное, что бы...

Нажмите, чтобы раскрыть...

• DebugLevel равно 9 — это правильная настройка, там будет полная детализация по заданиям.
• Установка C:\EC-APPS\ISTA\TesterGUI\bin\Release, режим ISTA_PLUS, культура en-GB, активация прошла OK. С запуском всё в порядке.
• Отмечу один момент: итоговый PATH содержит c:\ediabas\bin наряду с собственным каталогом ISTA C:\EC-APPS\ISTA\Ediabas\BIN. ISTA добавляет свой каталог первым, так что он должен иметь приоритет, но если у вас отдельный INPA/EDIABAS при standalone-установке на той машине стоит учитывать: устаревший EDIABAS.INI или старые API DLL в старой ветке — известная причина странного поведения задач. Это предположение, не диагноз; отмечаю это потому, что оно видно, а не потому, что лог на это указывает.

• Найдите ERROR и FATAL и отметьте первую, которая появится после того как вы открыли status/live-values экран. При запуске и идентификации будут появляться безобидные предупреждения — их игнорируйте, нужны те, что попадают в нужное окно по времени.
• Найдите IFH- — ошибки интерфейса EDIABAS (IFH-0009, IFH-0018, IFH-0003 и т. д.). Если они есть, проблема на уровне comms/SGBD слоя, а не в UI.
• Найдите у DME SGBD/ECU краткое имя и выложите строки, показывающие выполняемую задачу и её результат. В логах ISTA вызов задачи и набор результатов записываются явно, так что будет видно, выполнилась ли задача и ничего не вернула или вообще не запускалась.
• Найдите Exception и ExecuteDiagnosticJob.

• Задача выполняется, возвращает результаты, но UI ничего не показывает → presentation/mapping проблема в данных нового тестового модуля для MSD85.
• Задача не выполняется или ECU не отвечает (ошибки IFH, тайм-ауты, отрицательные ответы) → более новый SGBD или слой EDIABAS взаимодействует с этим DME иначе, чем 4.32.15.
• Задача вообще не вызывается → экран состояния вообще не сопоставляет параметры с задачами, что снова указывает на набор данных.

Gemini сказал(а):

Спасибо — и правильно, что замаскировали VIN.

Что имеем на данный момент

По вложению я вижу только начало сессии — фрагмент идёт примерно до 09:18:14, то есть это первые две секунды файла размером 3.2 MB. Сбой, который вы описываете, происходит намного позже, поэтому нужного участка у меня пока нет. Но по тому, что видно, стоит проверить несколько моментов:

• DebugLevel — 9, это правильная настройка, там будет полная детализация по заданиям.
• Установка — C:\EC-APPS\ISTA\TesterGUI\bin\Release, режим ISTA_PLUS, культура en-GB, активация прошла успешно. На этапе запуска всё в порядке.
• Один момент: итоговый PATH содержит c:\ediabas\bin наряду с собственным C:\EC-APPS\ISTA\Ediabas\BIN ISTA. ISTA добавляет свой каталог в начало, так что приоритет должен быть у него, но если на этом компьютере установлена отдельная автономная версия INPA/EDIABAS, об этом стоит помнить — устаревший EDIABAS.INI или старые API DLL в старом дереве являются известной причиной странного поведения заданий. Это предположение, не диагноз; отмечаю это потому, что оно видно в логе, а не потому, что лог указывает именно на это.

Что нужно из лога

Откройте .log в текстовом редакторе с нормальным поиском (Notepad++ / VS Code) и найдите участок со сбоем. По полезности — в таком порядке:

• Найдите ERROR и FATAL и отметьте первое появление после того, как вы открыли экран status/live-values. При запуске и идентификации будут безобидные предупреждения — их игнорируйте, нужны сообщения в правильном временном окне.
• Найдите IFH- — ошибки интерфейса EDIABAS (IFH-0009, IFH-0018, IFH-0003 и т. п.). Если они есть, проблема на уровне comms/SGBD, а не в интерфейсе.
• Найдите краткое имя SGBD/ECU DME и выложите строки, где видно выполнение задания и его результат. В логах ISTA вызов задания и набор результатов логируются явно, поэтому будет видно, выполнилось ли задание и вернуло пустой результат либо вообще не запускалось.
• Найдите Exception и ExecuteDiagnosticJob.

Почему это разделение важно

Вы уже установили, что на 4.32.15 это работает, а на всех более новых версиях с тем же оборудованием и тем же автомобилем — нет. Значит, разница внутри стека ISTA, а не в автомобиле и не в ICOM. Лог покажет, в какой именно части:

• Задание выполняется, возвращает результаты, но интерфейс ничего не показывает → presentation/mapping проблема в данных нового тестового модуля для MSD85.
• Задание завершается с ошибкой или ECU не отвечает (ошибки IFH, таймауты, отрицательные ответы) → новый слой SGBD или EDIABAS взаимодействует с этим DME не так, как в 4.32.15.
• Задание вообще не вызывается → экран состояния вообще не сопоставляет параметры с заданиями, что снова указывает на набор данных.

Выложите фрагмент примерно по 50 строк с каждой стороны от первой релевантной ошибки, а также время, когда вы нажали чтение значений на экране, чтобы я мог всё сопоставить. Этого достаточно, чтобы разобраться.

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

Привет
ещё раз спасибо за внимание, дружище.

Вот несколько обновлений:
установка ISTA 4.60.30...

Нажмите, чтобы раскрыть...

• Выполни ту же последовательность — идентификация, затем значения DME status/live, и отметь те же параметры.
• Если правая панель и там останется пустой, это будет серьёзным подтверждением твоего вывода, что после 4.32.15 что-то изменилось, причём результат не зависит от состояния установки, интерфейса или компьютера.
• Если данные появятся, значит, проблема всё это время была на стороне установки и вопрос полностью решён.

Gemini сказал(а):

Хорошие новости — теперь с вопросом по ICOM всё прояснилось.

По ICOM

Этот результат подтверждает то, на что уже указывали номера прошивок: пакет 03.24.21 / System 01.35.00 / Application 01.54.00 никогда не были проблемой, и A2 не исключается из-за версии. Если после чистой установки блок сразу определяется, значит, пустой Connection Manager при первой установке был связан с её состоянием (старый конфиг, оставшаяся настройка интерфейса или привязка к сетевой карте), а не с адаптером и не с версией прошивки ICOM. Настройка по умолчанию "ICOM / ENet local network" выбрана правильно — в этом режиме ISTA находит и ICOM, и кабель ENET по LAN, так что для твоей задачи вообще не нужно трогать переключатель ENET/D-CAN.

Также стоит подтвердить: то, что пакет данных для программирования не привязан к data_swi, для диагностики нормально. Это важно только для рабочих процессов programming/coding, поэтому на отображение текущих значений никак не влияет.

По логам 4.60.13

Я бы пока не стал этим заниматься. Разбираться, почему старая установка не находила блок, сейчас особого смысла нет — после чистой установки он уже определяется, и ты будешь отлаживать установку, которую уже заменил. Если хочешь оставить VM для сравнения, позже имеет смысл разве что забрать папку \ISTA\Logs\<session> из сеанса, где Connection Manager остался пустым, но я бы не тратил на это время.

Что сейчас действительно важно

Поведение MSD85 с текущими данными на B7. Это пока открытый вопрос, и 4.60.30 позволяет нормально его проверить:

• Выполни ту же последовательность — идентификация, затем значения DME status/live, отметь те же параметры.
• Если правая панель и там останется пустой, это будет сильным подтверждением твоего вывода, что после 4.32.15 что-то изменилось, причём это не зависит от состояния установки, интерфейса или компьютера.
• Если данные появятся, значит, проблема всё это время была на стороне установки, и вопрос полностью решён.

В любом случае результат полезен, так что напиши, что получится.

Что ещё осталось проверить по логу

В приложенном тобой логе размером 3.2 MB видны только первые пару секунд сеанса, поэтому сам момент сбоя я пока не видел. Если 4.60.30 тоже не сработает, возьми фрагмент уже из нового сеанса — после того места, где ты открыл экран состояния, поищи ERROR и FATAL, а также IFH- (ошибки интерфейса EDIABAS), и выложи блок вокруг первого найденного совпадения вместе с временной меткой. Именно этот фрагмент покажет, какая операция или ресурс не вернули результат.

И ещё раз оговорка, которая относится ко всему сказанному выше: опубликованная здесь сборка — 4.60.13. 4.60.30 — это другой пакет из другого источника, поэтому я не могу сказать, как именно его собирали. Любой вывод о работе ISTA, который ты сделаешь на его основе, всё равно остаётся valid, но за сам пакет я поручиться не могу.

Нажмите, чтобы раскрыть...

• нажал на DME / Call ECU functions
• выбрал вкладку Diagnostics scan / Diagnosis request
• выбрал несколько функций ECU: 4.60.30 точно работает как ожидается при выборе большего количества функций, НО НЕ ВСЕХ
• раньше я вообще не мог считать никакие данные. В 4.60.30 сейчас считывается почти всё
• некоторые, которые по-прежнему не считываются:

mhalabi81 сказал(а):

Я только что повторил те же тесты:

нажимаю DME / Call ECU functions
выбираю вкладку Diagnostics scan / Diagnosis req...

Нажмите, чтобы раскрыть...

• Факт: связь, интерфейс и сессия с ECU точно работают — это подтверждают значения, которые всё-таки считываются.
• Факт: на 4.32.15 те же функции заполнялись на том же железе и той же машине.
• Предположение: 901 (расчётная нагрузка), 902 (показание в км) и остальные записи этого диапазона похожи на классические идентификаторы блоков измерений. Обычно их обслуживает одна задача типа STATUS_ с аргументом блока, а не отдельная задача для каждой строки. Именно такая структура и даёт результат «всё или ничего» для целого блока.
• Предположение: регрессия связана с диагностическими данными, а не с приложением — либо SGBD для этой версии DME теперь вызывает задачу с аргументами, которые более старая программа MSD85 не принимает (в таком случае обычно возвращается отрицательный ответ: 0x31 request out of range или 0x12 sub-function not supported), либо описание этого блока больше не находится в новой базе данных.

• Запусти новую сессию на 4.60.30, выполни идентификацию, перейди в DME → Diagnosis request и выбери только 901. Больше ничего. Дай тесту завершиться с ошибкой, затем корректно закрой сессию.
• В получившейся папке \ISTA\Logs\<session>\ открой лог операций и сначала найди короткое имя DME, а затем JOB: примерно в это же время. Выложи строку с вызовом задачи и две-три следующие строки — именно там будет либо набор результатов, либо отрицательный ответ.
• В этом же временном диапазоне также найди IFH- и ERROR.

mhalabi81 сказал(а):

я только что прогнал те же тесты:

• нажимаю DME / Call ECU functions
• выбираю вкладку Diagnostics scan / Diagnosis request
• выбрал несколько функций ЭБУ: 4.60.30 точно работает как ожидается при выборе большего количества функций, НО НЕ ВСЕХ
• раньше я вообще не мог считать никаких данных. На 4.60.30 сейчас считываются почти все
• что всё ещё не считывается:

все функции, начинающиеся с CODE 9xx
пример: 901 — расчётное значение нагрузки
902 — показание пробега
903 и так далее (вплоть до 918)

но все функции ЭБУ ниже 9xx считываются, так что это уже улучшение

Нажмите, чтобы раскрыть...

Gemini сказал(а):

Это очень полезный результат — и по характеру сбоя мы теперь понимаем больше, чем после прежнего «вообще ничего не считывается».

Что означает блок 9xx

Если подряд идущая группа не работает, а всё ниже неё работает, это не проблема связи. Если бы ICOM или сеанс DME были неисправны, не заполнялось бы вообще ничего. А у тебя большинство статусных запросов возвращают данные, а целый нумерованный блок остаётся пустым — это указывает на одну общую диагностическую задачу, которая обслуживает весь этот блок. Один вызов задания завершается ошибкой, поэтому все записи 901–918, которые от него зависят, остаются пустыми.

Отделим факты от предположений:

• Факт: по значениям, которые всё-таки считываются, видно, что связь, интерфейс и сеанс с ЭБУ работают нормально.
• Факт: на 4.32.15 те же функции заполнялись с тем же железом и на той же машине.
• Предположение: 901 (расчётная нагрузка), 902 (показание в км) и остальные параметры этого диапазона похожи на классические идентификаторы измерительных блоков. Обычно их обслуживает одно задание типа STATUS_ с аргументом блока, а не отдельное задание для каждой строки. Именно такая структура и даёт ситуацию, когда блок либо работает целиком, либо не работает вообще.
• Предположение: регрессия находится в диагностических данных, а не в приложении — либо SGBD для этой версии DME теперь вызывает это задание с аргументами, которые старое ПО MSD85 не принимает (в таком случае обычно возвращается отрицательный ответ: 0x31 запрос вне диапазона или 0x12 подфункция не поддерживается), либо описание этого блока больше не находится в новой базе данных.

Вариант с Alpina

Стоит учитывать: на F01 B7 с ПО DME, специфичным для Alpina, набор диагностических заданий часто урезан по сравнению со стандартным N63 MSD85, а покрытие вариантов Alpina в данных ISTA хуже, чем для базовой версии автомобиля. Если новые диагностические данные создавались для стандартного варианта, блок, который ПО Alpina не поддерживает, будет вести себя ровно так. Но это пока только предположение — без ответа на уровне задания я не могу это подтвердить.

Следующий шаг — целевой лог

Теперь, когда всё свелось к одному блоку, лог будет небольшим и даст однозначный ответ:

• Запусти новый сеанс на 4.60.30, выполни идентификацию, зайди в DME → Diagnosis request и выбери только 901. Больше ничего. Дай ему завершиться ошибкой, затем корректно закрой сеанс.
• В получившейся папке \ISTA\Logs\<session>\ открой лог операций и сначала выполни поиск по короткому имени DME, затем по JOB: примерно в это же время. Выложить нужно строку с вызовом задания и следующие две-три строки — именно там будет либо набор результатов, либо отрицательный ответ.
• Также выполни поиск по IFH- и ERROR в этом же временном интервале.

Если сможешь провести такой же тест одной функции на компьютере с 4.32.15 и снять те же несколько строк, это окончательно прояснит ситуацию — у нас будут имя задания и аргументы, с которыми работает, и те, с которыми оно не работает. По разнице сразу станет понятно, изменила ли ISTA вызов или ЭБУ его отклоняет.

И ещё один быстрый вопрос, пока ты в интерфейсе: строки 9xx отображаются серыми и недоступными для выбора или выбираются нормально, но просто возвращают пустой результат? Это разные варианты сбоя — первый говорит о том, что описание вообще не находится, а второй — что задание запускается, но ЭБУ его отклоняет.

Нажмите, чтобы раскрыть...

mhalabi81 сказал(а):

закрываю ISTA
перезапускаю с чистой сессией
буквально не буду делать ничего, кроме того, что ты сказал, так что лог...

Нажмите, чтобы раскрыть...

• Запусти ISTA, подключись, выполни идентификацию — и ничего больше.
• Сразу переходи в DME → Вызов функций ECU → Запрос диагностики.
• Сначала отметь одну рабочую функцию (любую из под-9xx) и дождись ответа — так у нас будет заведомо успешный вызов job в качестве точки отсчёта в логе.
• Затем отметь только одну неработающую — 901 рассчитан load value будет самым чистым одиночным случаем.
• Отметь время по часам, когда выберешь 901, затем корректно закрой ISTA, чтобы лог записался.

• Вызываемый job — ищи записи STATUS_ рядом с этим временем и запиши job, а также все переданные аргументы.
• Ответ — код отрицательного ответа (0x31, 0x12) или строку ошибки EDIABAS IFH- / SYS-.
• ERROR и вхождения FATAL только в этом окне.