sys-av

На счет фазы очень даже может быть. Значит пока претензий к проге Atomic-DM никаких нету.

Пока странностей не заметил. В идеале надо сравнивать с результатами откатки по ШДК. Причем откатывать надо в одно и тоже время (условия окружающей среды должны быть одинаковыми) тогда и БЦН тоже должен быть примерно одинаковым. P.S. Остается вопрос к andrey-797-31 была ли ранее откатана эта прошивка на этот двиг (вместе с пауком) ? Чем откатывалась (и есть ли уверенность что поправка верно откатана) ? И если была то что заставило измениться поправку с 1.1 на 1.22, это не маленькое изменение...

Согласен, я про то и говорю, что если значение (как поправки, так соответственно и БЦН) нереальное, это должно насторожить, либо проблемы по топливоподаче, либо косяк в программе, либо условия откатки... вот и andrey-797-31 это насторожило

Так и должно быть, все правильно, вопрос у andrey-797-31 в том почему новое значение поправки выросло и соответственно выросло наполнение в режимной точке, на стоковом моторе. 512 мг. это даже не со всеми валиками в данной точке может быть, поэтому у человека и закрались сомнения. Тем более у человека вроде БЦН был откатан ранее. to andrey-797-31, а откатывал ты с дефолтными параметрами программы (в частности число циклов стационарности) или что-то менял ?

В установившемся режиме вроде так, а в режиме педалирования есть еще динамическая коррекция

Если двиг сток, то 512 это реально многовато.

Динамическая коррекция влияет на угол. Топнул ты на педаль, мозги посчитали ожидаемую прибавку по воздуху, высчитали добавочное топливо и по добавочному топливу скорректировали угол в минус, чтобы не детонировало при педалировании. В прошивке есть коэффициент динамической коррекции УОЗ от его величины зависит насколько будет отброшен угол. Если на пальцах, то вроде как-то так.

На сколько я в курсе, на диагностику значение БЦН выдается уже помноженное на поправку. Возможно в данном случае значение БЦН по диагностике домножается на вычесленный коэффициент, на который потом будет домножена и поправка...

Так и Циткловой расход воздуха растет, а при росту ЦРВ УОЗ в калибрах уменьшается. Короче надо брать конкретные режимные точки и смотреть причем в статике, так как при нажатии на дроссель еще работает динамическая коррекция УОЗ

Чтобы совсем небыло не обязательно. Одиночные и не постоянные для этой режимной точки детанационные удары можно не принимать во внимание. По поводу угла, есть еще корректировки по температуре и они минусуются, там как раз должно быть около 5 градусов если я не ошибаюсь

С таким подходом вам сдесь никто не поможет, даже если и знает, как! Сначала правильно заполните профиль (как минимум откуда вы), потом задайте правильно вопрос и в одной теме (лучше создайте свою), а не засоряйте форум кучей копий ваших сообщений в разных темах, это неуважение к остальным участникам форума.

Так я и говорю, что пробовал small_logger со стандартной прошивкой на моем Я7 работает без ошибок только с интервалом 160 мс. и выше

Можно, но только установку всех компонент запускать в режиме совместимости с XP и от имени Администроатора

ну вот а в апроге Atomic а изначально стояло 100 мс. и прошивка LS спокойно с таким интервалом отдавала данные диагностики, а стоковые с таким интервалом не могут (вот про это и разговор)

Да все понятно, не может стоковая прошивка отдавать дивгностические данные с интервалом 100 мс. ИСД - у него интервал опроса по-моему 300 мс. у MT-2 тоже интервал немаленький, а про OnLine и говорить нечего, там специальный протокол... У меня на 160 мс. минимум без ошибок работал Январь 7 со стоковой прошивкой.

Я бы сказал наоборот, LS оптимизированная, а остальные стандарт

Проверил, с двойным интервалом все работает, что не может не радовать :-)

2 Atomic-DM: получается что интервал сейчас 200 мс. ? 2 andrey-797-31: Я давно про настраиваемый интервал говорю, можно было бы подобрать минимальный интервал при котором не лезут ошибки. Пока видно у автора времени на это нету, надеюсь что когда-нибудь этот параметр появится. Автору и так большое спасибо за ту работу которую он проделывает и за то что разбирается с нашей проблемой.

Ради эксперимента поиграйтесь коэффициентом коррекции на 100% дросселя, например поставьте 1.5 топливо в заданный состав попадать конечно не будет (ехать скорее всего тоже, если не поставить состав например 14,7 ), но зато БЦН возрастет хорошо. Насколько я понимаю БЦН на диагностику выдается уже после умножение на поправку, поэтому у одного и того же конфига двигателя может очень сильно разниться БЦН, а мощность и момент при этом быть равными. Например когда форсунка реально льет чуть меньше чем указано в статике (например слегка забиты или РДТ держит меньшее давлении и другие особенности) то при откатке коэффициенты коррекции будут разными и в итоге БЦН тоже. Все сказанное ИМХО основанное на наблюдениях.

По поводу драйверов все просто, главное определить на каком чипе у тебя адаптер (FTDI, CP, PL) а дальше на сайте производителя. Кстати Драйвера на сайте Мастеркита по-моему были

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

LS у не все адаптированы внутренние циклы и быстродействие, видно она успевает. Замечал что разные блоки держат разный минимальный интервал между опросами на одной и той же прошивке. Винда 7, адаптер точно название не помню, Точно знаю что на FTDI. Весь софт с ним работает отлично и ICD и SmallLoger и DiagnozNK. Допустим в SmallLoger играясь параметром интервала между запросами на этом блоке я ваявил минимальное время равное 180 мс., если меньше проскакивают ошибки. Поэтому я и говорю, что надо сделать настраиваемый параметр. Тогда можно подобрать минимальный интервал для конкретного блока, что очень хорошо, поскольку чем меньше интервал, тем больше опросов в секунду, тем точнее данные, но при этом если начинают сыпаться ошибки, то это портит все результаты.

Latency time уже уменьшал до минимума и буфер тоже уменьшал, все это на результат абсолютно не влияет

Ситуация описывалась ранее, поэтому подумал что подробно не надо. Получается что надо. Блок Я7.2, адаптер на чипе FTDI, прошивка на базе DO или DM не важно. Параметрами виртуального порта игрался (и скоростью и буферами и т.д.) ситуация не меняется. Сама картина выглядит так: программа порт (com1) видит, с блоком коннектится, затем когда начинает опрос несколько циклов (у меня по-моему 2) данные получает верные, затем проскакивают неправильные данные, потом опять нормальные и так по кругу. В интерфейсе это выглядит так: зеленые значения параметров сменяются красными и надпись двигатель то прогрет то не прогрет. По аналогии с другими программами где можно выставить интервал между запросами похоже что блок не успевает отвечать с таким интервалом. То есть первые через определенное количество запросов получается, что запрос начинает происходить когда блок еще отвечает вот и получается битый пакет данные битые соответственно нету 5 попаданий подряд в одну режимную точку, а значит и нет обучения

Потестил, новую весию. К сожалению параметры через раз номальные, а через раз битые. Закладка "настройки" неактивка поэтому изменить скорость либо интервал опроса не удалось. Надеюсь что следующей версии настройки можно будет менять.