Алгоритм универсального обработчика положения валов
Алгоритм универсального обработчика положения валов
Вынужден создать новую тему, в старой грязно. Предлагаю здесь выработать алгоритм работы универсального алгоритма обработки положения валов, без привязки к коду.
Надо обрабатывать как конфигурации "беззубых" колес 60-2, 35-1 и так далее, просто одно событие за оборот, так и всякие извраты вроде dodge neon. Причем совсем не хочется под каждый конкретный случай городить свой огород, писать свою ветку кода.
Мои мысли на тему.
Допустим мы храним в массиве последовательность значений описывающую положение фронта от зуба относительно ВМТ или от предыдущего зуба. Допустим какой-то датчик
Восемь значений с углами для восьми этих самых сдвигов.
При отрабатывании зуба мы берем из массива значение следующего, запускаем таймер, который отсчитывает время (угол), по прерыванию берем время из текущего rpm считаем угол и сравниваем с углом из массива. Если расхождение не более какого-то количества процентов, то это наш зуб. Если расхождение больше, можно попробовать посчитать до следующего зуба (защита от пропуска зуба), тут уже по желанию. В этот момент можно пересчитать rpm, можно делать это несколько иначе, скользящим окном. Запускаем таймер опять и поехали по новой. Соответственно храним значение который зуб у нас "отчетный", от которого будем считать сдвиг до ВМТ. Для этого нам надо работать в синхронном режиме, чтобы текущий элемент массива совпадал с текущим положением зуба. Но при запуске или сбое нам в этот синхронный режим надо как-то войти.
Синхронизацию можно сделать как-то так: получая прерывания и меряя время мы пытаемся словить совпадение последних нескольких углов с началом последовательности в массиве. Нечто вроде скользящего окна - сохраняем в массив/стек последние пять (например. Для каждого набора может быть свои) углов, при каждом прерывании сопоставляем их с началом последовательности, если они совпадают - это оно. Иначе при следующем прерывании выбрасываем старое значение, добавляем новое - сравниваем. Тут вопрос как правильно посчитать длину, ведь мы не знаем rpm, ну и последовательность должна быть достаточно характерна. Для пропущенных зубов это должна быть та самая окрестность пропущенного зуба, для случая выше длинный и три коротких. Тут надо подумать, но думаю можно опираться на относительные длины импульсов, а на конкретную длину в углах. Может и хранить надо так?
Дальше всякие штуки вроде защиты от ложных срабатываний - если мы знаем, что следующий импульс должен быть через время t, то все импульсы до времени t-% мы игнорируем.
Таким образом для 60-2 в лоб нужно будет записать все 60 значений, но можно уже строить уловки, все остальные схемы ложатся независимо от формы сигнала. Новый датчик- новый массив+несколько переменных. Еще вариант - учет обеих фронтов, но это уже детали. Потенциально возможно вообще конфиг любого вала задавать через TS. Например в одной строке через запятую углы, пара полей для номера зуба и числа импульсов в последовательности для синхронизации. Так вообще можно будет любой датчик используя, не правя код.
Также следует одновременно обрабатывать ДПРВ, но там, насколько я понимаю, нас интересует только сигнал какая группа цилиндров срабатывает, так что там, по идее, должна быть проверка вроде "если уровень ДПРВ высокий, то работает первый, если низкий - третий". В части случаев именно по ДПРВ нужно будет ловить ВМТ, так что конфиг сенсоров должен хранить еще и по событию которого вала у нас, собственно, ВМТ - ДПКВ или ДПРВ.
Вот какие-то такие сумбурные мысли на тему. Предлагаю обсудить в этой теме алгоритм работы и выработать подходы.
По традиции флуд и оффтоп будет вырезаться.
Надо обрабатывать как конфигурации "беззубых" колес 60-2, 35-1 и так далее, просто одно событие за оборот, так и всякие извраты вроде dodge neon. Причем совсем не хочется под каждый конкретный случай городить свой огород, писать свою ветку кода.
Мои мысли на тему.
Допустим мы храним в массиве последовательность значений описывающую положение фронта от зуба относительно ВМТ или от предыдущего зуба. Допустим какой-то датчик
Восемь значений с углами для восьми этих самых сдвигов.
При отрабатывании зуба мы берем из массива значение следующего, запускаем таймер, который отсчитывает время (угол), по прерыванию берем время из текущего rpm считаем угол и сравниваем с углом из массива. Если расхождение не более какого-то количества процентов, то это наш зуб. Если расхождение больше, можно попробовать посчитать до следующего зуба (защита от пропуска зуба), тут уже по желанию. В этот момент можно пересчитать rpm, можно делать это несколько иначе, скользящим окном. Запускаем таймер опять и поехали по новой. Соответственно храним значение который зуб у нас "отчетный", от которого будем считать сдвиг до ВМТ. Для этого нам надо работать в синхронном режиме, чтобы текущий элемент массива совпадал с текущим положением зуба. Но при запуске или сбое нам в этот синхронный режим надо как-то войти.
Синхронизацию можно сделать как-то так: получая прерывания и меряя время мы пытаемся словить совпадение последних нескольких углов с началом последовательности в массиве. Нечто вроде скользящего окна - сохраняем в массив/стек последние пять (например. Для каждого набора может быть свои) углов, при каждом прерывании сопоставляем их с началом последовательности, если они совпадают - это оно. Иначе при следующем прерывании выбрасываем старое значение, добавляем новое - сравниваем. Тут вопрос как правильно посчитать длину, ведь мы не знаем rpm, ну и последовательность должна быть достаточно характерна. Для пропущенных зубов это должна быть та самая окрестность пропущенного зуба, для случая выше длинный и три коротких. Тут надо подумать, но думаю можно опираться на относительные длины импульсов, а на конкретную длину в углах. Может и хранить надо так?
Дальше всякие штуки вроде защиты от ложных срабатываний - если мы знаем, что следующий импульс должен быть через время t, то все импульсы до времени t-% мы игнорируем.
Таким образом для 60-2 в лоб нужно будет записать все 60 значений, но можно уже строить уловки, все остальные схемы ложатся независимо от формы сигнала. Новый датчик- новый массив+несколько переменных. Еще вариант - учет обеих фронтов, но это уже детали. Потенциально возможно вообще конфиг любого вала задавать через TS. Например в одной строке через запятую углы, пара полей для номера зуба и числа импульсов в последовательности для синхронизации. Так вообще можно будет любой датчик используя, не правя код.
Также следует одновременно обрабатывать ДПРВ, но там, насколько я понимаю, нас интересует только сигнал какая группа цилиндров срабатывает, так что там, по идее, должна быть проверка вроде "если уровень ДПРВ высокий, то работает первый, если низкий - третий". В части случаев именно по ДПРВ нужно будет ловить ВМТ, так что конфиг сенсоров должен хранить еще и по событию которого вала у нас, собственно, ВМТ - ДПКВ или ДПРВ.
Вот какие-то такие сумбурные мысли на тему. Предлагаю обсудить в этой теме алгоритм работы и выработать подходы.
По традиции флуд и оффтоп будет вырезаться.
skype: frig_frig
Re: Алгоритм универсального обработчика положения валов
Я ещё в предыдущей теме писал, что если мы хотим сделать универсальный обработчик, то сначала нужно посмотреть какие триггеры вообще существуют.
Re: Алгоритм универсального обработчика положения валов
Так а какая разница то? У нас на входе некая последовательность импульсов, которая регулярна. Нам надо определять в каком месте этой последовательности мы находимся. А последовательность может быть чуть ли не любая и хорошо бы конкретно к последовательности не привязываться, на то она и универсальность.сначала нужно посмотреть какие триггеры вообще существуют.
Я выделяю только два типа - датчик на коленвале которые показывает положение коленвале и когда ВМТ по распредвалу определяется. В остальном это просто периодическая последовательность импульсов.
skype: frig_frig
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Алгоритм универсального обработчика положения валов
Естественно нет желания писать 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 - может там есть инфа? Я не успеваю это доделать
Из хорошего - мне кажется у меня есть план универсального обработчика на четыре известных мне триггера.
Мой план такой: первый сигнал 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 - может там есть инфа? Я не успеваю это доделать
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Алгоритм универсального обработчика положения валов
Ну вот как в твою концепцию обработки вписывается, например, датчик без пропущенных зубьев? Где идут 180 зубьев на 1 оборот КВ.frig wrote:Так а какая разница то? У нас на входе некая последовательность импульсов, которая регулярна. Нам надо определять в каком месте этой последовательности мы находимся. А последовательность может быть чуть ли не любая и хорошо бы конкретно к последовательности не привязываться, на то она и универсальность.
Я выделяю только два типа - датчик на коленвале которые показывает положение коленвале и когда ВМТ по распредвалу определяется. В остальном это просто периодическая последовательность импульсов.
Last edited by Sergey89 on Sun Dec 22, 2013 7:10 pm, edited 1 time in total.
Re: Алгоритм универсального обработчика положения валов
Одинаковые конфиги для валов. Массив с набором положений зубов, одна переменная определяющая какой зуб считать за основной и по какому дергать события. Соответственно в конфиге какого вала эта переменная есть - по тому и ориентируемся.
Вот так вроде универсально получается.
Раздел
Ignition Setup Options
Там всякие 36-2+2 и другие.
Датчики ведь просто шлют импульсы, в этом они одинаковы. Есть некий признак, определяемый взаимным расположением этих самых импульсов, означающий, что мы, собственно, в точке X. Все это одной моделью можно обработать.
Вот так вроде универсально получается.
http://www.msextra.com/doc/index.htmlуниверсального обработчика на четыре известных мне триггера
Раздел
Ignition Setup Options
Там всякие 36-2+2 и другие.
Датчики ведь просто шлют импульсы, в этом они одинаковы. Есть некий признак, определяемый взаимным расположением этих самых импульсов, означающий, что мы, собственно, в точке X. Все это одной моделью можно обработать.
skype: frig_frig
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Алгоритм универсального обработчика положения валов
Никак не вписывается. А как такой датчик синхронизируется?Sergey89 wrote: Ну вот как в твою концепцию обработки вписывается, например, датчик без пропущенных зубьев? Где идут 180 зубьев на 1 оборот КВ.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Алгоритм универсального обработчика положения валов
Вот выше в посте описал чуть.как в твою концепцию обработки вписывается, например, датчик без пропущенных зубьев
Есть же признак, по которому мы ориентируемся где у нас условное срабатывание? Не по ДПКВ, так по ДПРВ.
Взаимная синхронизация нужна?
skype: frig_frig
Re: Алгоритм универсального обработчика положения валов
Да. Синхронизируется он по второму сигналу. Если не ошибаюсь, то такой вариант называется ДНО+ДУИ: датчик начала отсчета и датчик угловых импульсов.
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Алгоритм универсального обработчика положения валов
Тут такое дело... Я почему-то хотел бы эти сигналы переставить местами Как только ДНО становится первым сигналом - всё, это ford aspire.Sergey89 wrote:Да. Синхронизируется он по второму сигналу. Если не ошибаюсь, то такой вариант называется ДНО+ДУИ: датчик начала отсчета и датчик угловых импульсов.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Алгоритм универсального обработчика положения валов
У тебя несколько проще, потому что число импульсов совпадает с числом цилиндров и ты можешь даже без второго сигнала работать.
Re: Алгоритм универсального обработчика положения валов
Не так важно. В предложенную модель ложится? ложится. Какие еще есть сложные случаи?
skype: frig_frig
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Алгоритм универсального обработчика положения валов
Нет, не проще - полностью одинаково. Если сигнала синхронизации нет - я откажусь заводиться. И по-другому обрабатывать отсутсвие сигнала пока не планирую.Sergey89 wrote:У тебя несколько проще, потому что число импульсов совпадает с числом цилиндров и ты можешь даже без второго сигнала работать.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Алгоритм универсального обработчика положения валов
Зависит от скорости выполнения обработчика. На 9000 об/мин между зубьями будет 466 циклов для выполнения кода, если у обработчика прерывания самый высокий приоритет. Я этот датчик обрабатывал в режиме счётчика, а не в режиме захвата.frig wrote:Не так важно. В предложенную модель ложится? ложится. Какие еще есть сложные случаи?
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Алгоритм универсального обработчика положения валов
Как хорошо, что 9000 нам не светит Но да, проблема есть - будем значит как-то где-то на каком-то уровне зарезать сигналы, а потом обрабатывать в едином стиле.Sergey89 wrote:Зависит от скорости выполнения обработчика. На 9000 об/мин между зубьями будет 466 циклов для выполнения кода, если у обработчика прерывания самый высокий приоритет. Я этот датчик обрабатывал в режиме счётчика, а не в режиме захвата.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Алгоритм универсального обработчика положения валов
Сергей, я бы упрощение и всевозможные оптимизации отложил бы на потом. Сейчас я пытаюсь поговорить про алгоритм. Если окажется, что алгоритм рабочий, то тогда уже можно будет смотреть как его облегчить и где это нужно. И нужно ли.
skype: frig_frig
Re: Алгоритм универсального обработчика положения валов
По поводу счетчика и оптимизаций. Можно попробовать практически в автоматическом режиме это делать. При инициализации сенсора проходить массив и объединять группами тики, если они одинакового размера. Группу считаем счетчиком, потом меряем общее время и дальше по тексту. Таким образом с одной стороны можно будет обрабатывать все эти 180-360 зубов на оборот, но с плюшками гибкого подхода. По три-пять если даже объединять, уже будет профит
skype: frig_frig
Re: Алгоритм универсального обработчика положения валов
Я ошибся в расчёте.
Вот так правильно:
168000000/(9000/60*180)-12=6210 циклов
Вот так правильно:
168000000/(9000/60*180)-12=6210 циклов
Re: Алгоритм универсального обработчика положения валов
Ну вот, а я уже придумал как это оптимизировать
Народ, так как алгоритм? Давайте ругайте его.
Народ, так как алгоритм? Давайте ругайте его.
skype: frig_frig
Re: Алгоритм универсального обработчика положения валов
вставлю свои 5 копеек которые вы уже потеряли))
- Attachments
-
- AN2897.pdf
- (586.19 KiB) Downloaded 668 times
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Алгоритм универсального обработчика положения валов
eTPU к нам не имеет никакого отношения - это жёсткий оффтопик.acab wrote:вставлю свои 5 копеек которые вы уже потеряли))
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Алгоритм универсального обработчика положения валов
ничего страшного что там описан подробно алгорит расчёта угла на основе зубчатого шкива с пропуском зубов?
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Алгоритм универсального обработчика положения валов
Артём Я не знаю как тебе объяснить, если до тебя еще не доходитacab wrote:ничего страшного что там описан подробно алгорит расчёта угла на основе зубчатого шкива с пропуском зубов?
Вот ты дал ссыдку на документ, в нём 32 страницы. Ты как думал, мы сейчас пойдём, прочитаем 32 страницы - "Артём загадал нам загадку, интересно - что же он имел ввиду? Пойду прочитаю 32 страницы, потрачу 20 минут - наверняка время будет потрачено не зря".
Я уже говорил это и скажу еще раз - я вижу, что ты хочешь помочь. Но пока ты помогаешь не очень На конкретные просьбы о простой помощи ты не очень реагируешь, тебе интересно только гениальные идеи генерировать Подумай пожалуйста об этом.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Алгоритм универсального обработчика положения валов
Я не буду разжовывать 100500 раз общеизвестные факты.
В данном документе очень сильно разжовано(с примерами) по поводу:
1. синхронизации
2. работы с ошибками
3. расчёта угла
4. акселерации\децелерации
есть примеры обработки всего, правда для 36-1 шкива. но проблем с этим нет особо. главное знать количество зубов на шкиве и сколько пропущенных.
начиная с 21 страницы есть примеры инициализации колена, первого зуба, синхронизации и прочего
В данном документе очень сильно разжовано(с примерами) по поводу:
1. синхронизации
2. работы с ошибками
3. расчёта угла
4. акселерации\децелерации
есть примеры обработки всего, правда для 36-1 шкива. но проблем с этим нет особо. главное знать количество зубов на шкиве и сколько пропущенных.
начиная с 21 страницы есть примеры инициализации колена, первого зуба, синхронизации и прочего
- Attachments
-
- crankshaft_algo_advance.jpg (44.11 KiB) Viewed 21135 times
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Алгоритм универсального обработчика положения валов
Вот сейчас уже сильно лучше Можешь же, если тебя пнуть.
Пойдми просто - ценно не указать на огромный документ, еще очень важно написать - почему в него вообще нужно смотреть и куда именно. Вот сейчас ты это хорошо обосновал
Пойдми просто - ценно не указать на огромный документ, еще очень важно написать - почему в него вообще нужно смотреть и куда именно. Вот сейчас ты это хорошо обосновал
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Алгоритм универсального обработчика положения валов
ты все мои предложения воспринимаешь в штыки. всего говнишь. однако потом соглашаешься и гоовришь что нужная вещь. привыкни к тому, что я фигни не посоветуюrussian wrote:Вот сейчас уже сильно лучше Можешь же, если тебя пнуть.
Пойдми просто - ценно не указать на огромный документ, еще очень важно написать - почему в него вообще нужно смотреть и куда именно. Вот сейчас ты это хорошо обосновал
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: Алгоритм универсального обработчика положения валов
Ага, был шаг вперёд - сейчас два шага назад. Повторяю еще раз: в штуки воспронимаются не твои предложения, а твой способ подачи информации. Сейчас ты очень любишь отвечать загадками, обратни внимание - обычно тебя нужно два раза переспросить, чтоб добиться от тебя полезной информации. А первая версия - всегда мутная загадка. Привыкни к тому, что ты пока не умеешь мысли излагать - и попробуй говорить меньше, но лучше.acab wrote: ты все мои предложения воспринимаешь в штыки. всего говнишь. однако потом соглашаешься и гоовришь что нужная вещь. привыкни к тому, что я фигни не посоветую
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: Алгоритм универсального обработчика положения валов
acab, совсем здорово будет, если ты опишешь тот алгоритм человеческим языком. Чем отличается от предложенного здесь?
skype: frig_frig
Re: Алгоритм универсального обработчика положения валов
Для случая выше очень просто провести синхронизацию, если опираться на сигнал с распредвала (ДПРВ).frig wrote:Для пропущенных зубов это должна быть та самая окрестность пропущенного зуба, для случая выше длинный и три коротких.
1) Если сигнал ДПРВ перешёл с высокого уровня на низкий и при этом сигнал с ДПКВ имеет высокий уровень, то мы находимся между ВМТ 2 и 1 цилиндра и следующий задний фронт сигнала ДПКВ укажет на конкретный угол.
2) Если сигнал ДПРВ перешёл с высокого уровня на низкий и при этом сигнал с ДПКВ имеет низкий уровень, то мы находимся между ВМТ 3 и 4 цилиндра и следующий передний фронт сигнала ДПКВ укажет на конкретный угол.
В моём случае синхронизацию нужно производить по длине окна в градусах с датчика распредвала.
В случае пропущенных зубьев синхронизация выполняется по длительность между зубьями относительно предыдущей длительности.
Можно ли всё это уложить в 1 универсальный алгоритм?
А откуда углы возьмутся, если мы оперируем временем?Тут надо подумать, но думаю можно опираться на относительные длины импульсов, а на конкретную длину в углах.
Re: Алгоритм универсального обработчика положения валов
а если цепь подуставшая и растянутая?Sergey89 wrote: Для случая выше очень просто провести синхронизацию, если опираться на сигнал с распредвала (ДПРВ).
1) Если сигнал ДПРВ перешёл с высокого уровня на низкий и при этом сигнал с ДПКВ имеет высокий уровень, то мы находимся между ВМТ 2 и 1 цилиндра и следующий задний фронт сигнала ДПКВ укажет на конкретный угол.
2) Если сигнал ДПРВ перешёл с высокого уровня на низкий и при этом сигнал с ДПКВ имеет низкий уровень, то мы находимся между ВМТ 3 и 4 цилиндра и следующий передний фронт сигнала ДПКВ укажет на конкретный угол.
у нас есть угловая скорость (размерность 1/время) и метки фиксированных углов по зубьямSergey89 wrote:А откуда углы возьмутся, если мы оперируем временем?Тут надо подумать, но думаю можно опираться на относительные длины импульсов, а на конкретную длину в углах.
Теория хороша в том и только том случае, если она может достоверно предсказать результаты каждого нового опыта