rusefi.com

Вынужден создать новую тему, в старой грязно. Предлагаю здесь выработать алгоритм работы универсального алгоритма обработки положения валов, без привязки к коду.
Надо обрабатывать как конфигурации "беззубых" колес 60-2, 35-1 и так далее, просто одно событие за оборот, так и всякие извраты вроде dodge neon. Причем совсем не хочется под каждый конкретный случай городить свой огород, писать свою ветку кода.
Мои мысли на тему.
Допустим мы храним в массиве последовательность значений описывающую положение фронта от зуба относительно ВМТ или от предыдущего зуба. Допустим какой-то датчик

Восемь значений с углами для восьми этих самых сдвигов.
При отрабатывании зуба мы берем из массива значение следующего, запускаем таймер, который отсчитывает время (угол), по прерыванию берем время из текущего rpm считаем угол и сравниваем с углом из массива. Если расхождение не более какого-то количества процентов, то это наш зуб. Если расхождение больше, можно попробовать посчитать до следующего зуба (защита от пропуска зуба), тут уже по желанию. В этот момент можно пересчитать rpm, можно делать это несколько иначе, скользящим окном. Запускаем таймер опять и поехали по новой. Соответственно храним значение который зуб у нас "отчетный", от которого будем считать сдвиг до ВМТ. Для этого нам надо работать в синхронном режиме, чтобы текущий элемент массива совпадал с текущим положением зуба. Но при запуске или сбое нам в этот синхронный режим надо как-то войти.
Синхронизацию можно сделать как-то так: получая прерывания и меряя время мы пытаемся словить совпадение последних нескольких углов с началом последовательности в массиве. Нечто вроде скользящего окна - сохраняем в массив/стек последние пять (например. Для каждого набора может быть свои) углов, при каждом прерывании сопоставляем их с началом последовательности, если они совпадают - это оно. Иначе при следующем прерывании выбрасываем старое значение, добавляем новое - сравниваем. Тут вопрос как правильно посчитать длину, ведь мы не знаем rpm, ну и последовательность должна быть достаточно характерна. Для пропущенных зубов это должна быть та самая окрестность пропущенного зуба, для случая выше длинный и три коротких. Тут надо подумать, но думаю можно опираться на относительные длины импульсов, а на конкретную длину в углах. Может и хранить надо так?

Дальше всякие штуки вроде защиты от ложных срабатываний - если мы знаем, что следующий импульс должен быть через время t, то все импульсы до времени t-% мы игнорируем.
Таким образом для 60-2 в лоб нужно будет записать все 60 значений, но можно уже строить уловки, все остальные схемы ложатся независимо от формы сигнала. Новый датчик- новый массив+несколько переменных. Еще вариант - учет обеих фронтов, но это уже детали. Потенциально возможно вообще конфиг любого вала задавать через TS. Например в одной строке через запятую углы, пара полей для номера зуба и числа импульсов в последовательности для синхронизации. Так вообще можно будет любой датчик используя, не правя код.

Также следует одновременно обрабатывать ДПРВ, но там, насколько я понимаю, нас интересует только сигнал какая группа цилиндров срабатывает, так что там, по идее, должна быть проверка вроде "если уровень ДПРВ высокий, то работает первый, если низкий - третий". В части случаев именно по ДПРВ нужно будет ловить ВМТ, так что конфиг сенсоров должен хранить еще и по событию которого вала у нас, собственно, ВМТ - ДПКВ или ДПРВ.

Вот какие-то такие сумбурные мысли на тему. Предлагаю обсудить в этой теме алгоритм работы и выработать подходы.
По традиции флуд и оффтоп будет вырезаться.

Я ещё в предыдущей теме писал, что если мы хотим сделать универсальный обработчик, то сначала нужно посмотреть какие триггеры вообще существуют.

сначала нужно посмотреть какие триггеры вообще существуют.

Так а какая разница то? У нас на входе некая последовательность импульсов, которая регулярна. Нам надо определять в каком месте этой последовательности мы находимся. А последовательность может быть чуть ли не любая и хорошо бы конкретно к последовательности не привязываться, на то она и универсальность.

Я выделяю только два типа - датчик на коленвале которые показывает положение коленвале и когда ВМТ по распредвалу определяется. В остальном это просто периодическая последовательность импульсов.

Естественно нет желания писать 30 имплементаций. Естесвенно самая большая проблема в имплементации.

Из хорошего - мне кажется у меня есть план универсального обработчика на четыре известных мне триггера.

Мой план такой: первый сигнал dodge neon становится частным случаем беззубого колеса, плюс второй сигнал просто считаем. После этого ford aspire становится тоже частным случаем беззубого колеса - с одним зубом

Я согласен с Сергеем - конечно же очень важно знать конкретные варианты. Я знаю четыре конкретных варианта и кажется у меня есть план сделать единый настраиваемый обработчик под эти 4 варианта (aspire, neon, 36/2, 60/2)

Друзья, мне нужна помощь Я как могу всё это программирую - но я один. Не все программисты одинаково полезны - мне нужна помощь не только очень молодых программистов.

Кокретнее - сейчас мне нужна помощь доконфигуроровать синтетический сигнал neon
см. http://rusefi.com/forum/viewtopic.php?f=3&t=360
Я начал его конфигурировать в dodge_neon.c примерно глядя на картинку, а потом чувак уже дописал более точные углы. Но там одного начального угла не хватает - но там есть какой-то аттач, может в нём есть. Или вот наш буйный добавил сорцы в http://rusefi.com/forum/viewtopic.php?f=9&t=198&start=70#p3817 - может там есть инфа? Я не успеваю это доделать

frig wrote:Так а какая разница то? У нас на входе некая последовательность импульсов, которая регулярна. Нам надо определять в каком месте этой последовательности мы находимся. А последовательность может быть чуть ли не любая и хорошо бы конкретно к последовательности не привязываться, на то она и универсальность.

Я выделяю только два типа - датчик на коленвале которые показывает положение коленвале и когда ВМТ по распредвалу определяется. В остальном это просто периодическая последовательность импульсов.

Ну вот как в твою концепцию обработки вписывается, например, датчик без пропущенных зубьев? Где идут 180 зубьев на 1 оборот КВ.

Одинаковые конфиги для валов. Массив с набором положений зубов, одна переменная определяющая какой зуб считать за основной и по какому дергать события. Соответственно в конфиге какого вала эта переменная есть - по тому и ориентируемся.
Вот так вроде универсально получается.

универсального обработчика на четыре известных мне триггера

http://www.msextra.com/doc/index.html
Раздел
Ignition Setup Options
Там всякие 36-2+2 и другие.
Датчики ведь просто шлют импульсы, в этом они одинаковы. Есть некий признак, определяемый взаимным расположением этих самых импульсов, означающий, что мы, собственно, в точке X. Все это одной моделью можно обработать.

Sergey89 wrote: Ну вот как в твою концепцию обработки вписывается, например, датчик без пропущенных зубьев? Где идут 180 зубьев на 1 оборот КВ.

Никак не вписывается. А как такой датчик синхронизируется?

как в твою концепцию обработки вписывается, например, датчик без пропущенных зубьев

Вот выше в посте описал чуть.
Есть же признак, по которому мы ориентируемся где у нас условное срабатывание? Не по ДПКВ, так по ДПРВ.
Взаимная синхронизация нужна?

Да. Синхронизируется он по второму сигналу. Если не ошибаюсь, то такой вариант называется ДНО+ДУИ: датчик начала отсчета и датчик угловых импульсов.

Sergey89 wrote:Да. Синхронизируется он по второму сигналу. Если не ошибаюсь, то такой вариант называется ДНО+ДУИ: датчик начала отсчета и датчик угловых импульсов.

Тут такое дело... Я почему-то хотел бы эти сигналы переставить местами Как только ДНО становится первым сигналом - всё, это ford aspire.

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

Не так важно. В предложенную модель ложится? ложится. Какие еще есть сложные случаи?

Sergey89 wrote:У тебя несколько проще, потому что число импульсов совпадает с числом цилиндров и ты можешь даже без второго сигнала работать.

Нет, не проще - полностью одинаково. Если сигнала синхронизации нет - я откажусь заводиться. И по-другому обрабатывать отсутсвие сигнала пока не планирую.

frig wrote:Не так важно. В предложенную модель ложится? ложится. Какие еще есть сложные случаи?

Зависит от скорости выполнения обработчика. На 9000 об/мин между зубьями будет 466 циклов для выполнения кода, если у обработчика прерывания самый высокий приоритет. Я этот датчик обрабатывал в режиме счётчика, а не в режиме захвата.

Sergey89 wrote:Зависит от скорости выполнения обработчика. На 9000 об/мин между зубьями будет 466 циклов для выполнения кода, если у обработчика прерывания самый высокий приоритет. Я этот датчик обрабатывал в режиме счётчика, а не в режиме захвата.

Как хорошо, что 9000 нам не светит Но да, проблема есть - будем значит как-то где-то на каком-то уровне зарезать сигналы, а потом обрабатывать в едином стиле.

Сергей, я бы упрощение и всевозможные оптимизации отложил бы на потом. Сейчас я пытаюсь поговорить про алгоритм. Если окажется, что алгоритм рабочий, то тогда уже можно будет смотреть как его облегчить и где это нужно. И нужно ли.

По поводу счетчика и оптимизаций. Можно попробовать практически в автоматическом режиме это делать. При инициализации сенсора проходить массив и объединять группами тики, если они одинакового размера. Группу считаем счетчиком, потом меряем общее время и дальше по тексту. Таким образом с одной стороны можно будет обрабатывать все эти 180-360 зубов на оборот, но с плюшками гибкого подхода. По три-пять если даже объединять, уже будет профит

Я ошибся в расчёте.

Вот так правильно:

168000000/(9000/60*180)-12=6210 циклов

Ну вот, а я уже придумал как это оптимизировать
Народ, так как алгоритм? Давайте ругайте его.

вставлю свои 5 копеек которые вы уже потеряли))

acab wrote:вставлю свои 5 копеек которые вы уже потеряли))

eTPU к нам не имеет никакого отношения - это жёсткий оффтопик.

ничего страшного что там описан подробно алгорит расчёта угла на основе зубчатого шкива с пропуском зубов?

acab wrote:ничего страшного что там описан подробно алгорит расчёта угла на основе зубчатого шкива с пропуском зубов?

Артём Я не знаю как тебе объяснить, если до тебя еще не доходит
Вот ты дал ссыдку на документ, в нём 32 страницы. Ты как думал, мы сейчас пойдём, прочитаем 32 страницы - "Артём загадал нам загадку, интересно - что же он имел ввиду? Пойду прочитаю 32 страницы, потрачу 20 минут - наверняка время будет потрачено не зря".

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

Я не буду разжовывать 100500 раз общеизвестные факты.
В данном документе очень сильно разжовано(с примерами) по поводу:
1. синхронизации
2. работы с ошибками
3. расчёта угла
4. акселерации\децелерации

есть примеры обработки всего, правда для 36-1 шкива. но проблем с этим нет особо. главное знать количество зубов на шкиве и сколько пропущенных.
начиная с 21 страницы есть примеры инициализации колена, первого зуба, синхронизации и прочего

Вот сейчас уже сильно лучше Можешь же, если тебя пнуть.

Пойдми просто - ценно не указать на огромный документ, еще очень важно написать - почему в него вообще нужно смотреть и куда именно. Вот сейчас ты это хорошо обосновал

russian wrote:Вот сейчас уже сильно лучше Можешь же, если тебя пнуть.

Пойдми просто - ценно не указать на огромный документ, еще очень важно написать - почему в него вообще нужно смотреть и куда именно. Вот сейчас ты это хорошо обосновал

ты все мои предложения воспринимаешь в штыки. всего говнишь. однако потом соглашаешься и гоовришь что нужная вещь. привыкни к тому, что я фигни не посоветую

acab wrote: ты все мои предложения воспринимаешь в штыки. всего говнишь. однако потом соглашаешься и гоовришь что нужная вещь. привыкни к тому, что я фигни не посоветую

Ага, был шаг вперёд - сейчас два шага назад. Повторяю еще раз: в штуки воспронимаются не твои предложения, а твой способ подачи информации. Сейчас ты очень любишь отвечать загадками, обратни внимание - обычно тебя нужно два раза переспросить, чтоб добиться от тебя полезной информации. А первая версия - всегда мутная загадка. Привыкни к тому, что ты пока не умеешь мысли излагать - и попробуй говорить меньше, но лучше.

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

frig wrote:Для пропущенных зубов это должна быть та самая окрестность пропущенного зуба, для случая выше длинный и три коротких.

Для случая выше очень просто провести синхронизацию, если опираться на сигнал с распредвала (ДПРВ).

1) Если сигнал ДПРВ перешёл с высокого уровня на низкий и при этом сигнал с ДПКВ имеет высокий уровень, то мы находимся между ВМТ 2 и 1 цилиндра и следующий задний фронт сигнала ДПКВ укажет на конкретный угол.
2) Если сигнал ДПРВ перешёл с высокого уровня на низкий и при этом сигнал с ДПКВ имеет низкий уровень, то мы находимся между ВМТ 3 и 4 цилиндра и следующий передний фронт сигнала ДПКВ укажет на конкретный угол.

В моём случае синхронизацию нужно производить по длине окна в градусах с датчика распредвала.

В случае пропущенных зубьев синхронизация выполняется по длительность между зубьями относительно предыдущей длительности.

Можно ли всё это уложить в 1 универсальный алгоритм?

Тут надо подумать, но думаю можно опираться на относительные длины импульсов, а на конкретную длину в углах.

А откуда углы возьмутся, если мы оперируем временем?

Sergey89 wrote: Для случая выше очень просто провести синхронизацию, если опираться на сигнал с распредвала (ДПРВ).

1) Если сигнал ДПРВ перешёл с высокого уровня на низкий и при этом сигнал с ДПКВ имеет высокий уровень, то мы находимся между ВМТ 2 и 1 цилиндра и следующий задний фронт сигнала ДПКВ укажет на конкретный угол.
2) Если сигнал ДПРВ перешёл с высокого уровня на низкий и при этом сигнал с ДПКВ имеет низкий уровень, то мы находимся между ВМТ 3 и 4 цилиндра и следующий передний фронт сигнала ДПКВ укажет на конкретный угол.

а если цепь подуставшая и растянутая?

Sergey89 wrote:

Тут надо подумать, но думаю можно опираться на относительные длины импульсов, а на конкретную длину в углах.

А откуда углы возьмутся, если мы оперируем временем?

у нас есть угловая скорость (размерность 1/время) и метки фиксированных углов по зубьям