-
- В этой "библиотеке" не понятно как влияет на принятие решения
значение encoder[num].err. Возможно оно как-то учитывается в
функции enc_check(), но ее реализации нет в архиве. - mmc(30.03.2022 20:20)
- Никак, просто для сведения. В мои задачах ошибки больше 1 не
случается (иногда на старте, т.к. неизвестно предыдущее состояние).
По сути служит для обнаружения дребезга или косяка по прошивке,
которая не успевает своевременно отрегулировать на фронт... POV(91 знак., 30.03.2022 20:38)
- Я использую свою реализацию того же алгоритма, что в Вашей в
библиотеке. Это лучший алгоритм из того, что я пробовал. У меня
используются китайские энкодеры, они дребезжат очень сильно. С этим
алгоритмом по крайней мере у меня нет ошибок определения
направления вращения. Но он какой-то тормозной: не реагирует на
единственный щелчок энкодера, ему надо несколько щелчков, чтобы
обнаружить вращение. Возможно из-за сильного дребезга, то есть
большого количества ошибок. Не mmc(16 знак., 30.03.2022 20:54)
- Да нет, с чего бы... POV(35 знак., 30.03.2022 21:01, ссылка)
- а какой там средний период импульсов? В микросекундах? - Лaгyнoв(30.03.2022 21:00)
- Это зависит от того с какой скоростью вращать ось энкодера. Вращать
можно очень медленно или быстро. В моем энкодере на полный оборот
оси происходит 16 щелчков контактов. Поэтому, если делать один
оборот в секунду (быстрее уже сложновато), получается период около
63 мс. Некоторые индивидумы могут вращать и быстрее. mmc(623 знак., 30.03.2022 21:33)
- у нас два вида датчиков расхода. Есть еще местами древние на герконах. Но там обычно один импульс на литр и соответственно период не менее 500 мсек. Для датчиков с числом импульсов 100-120 на литр и расходом до 100 л/минуту средний период - до 5 мсек. Хотя именно средний, потому как сильная детонация и промежутки могут меньше 2 мсек при длине импульса до 0,8 мсек. И везде я программно опрашиваю уровень с выхода. Состояние считается верным, если не менее 3 раз подряд. Для Лaгyнoв(83 знак., 31.03.2022 08:42)
- Всё с точностью до наоборот. Опрос энкодера должен происходить РЕЖЕ, чем длительность дребезга. Точно так же, как и опрос кнопок. Опрос с частотой ниже дребезга и является искомой защитой от дребезга. Можно канешна добавить ранее упомянутый тут фильтр - такой же, как в приемниках УАРТов. Но это дело вкуса. Обнаружение вращения (щелчков) делается на очень простой машине состояний (16 значений). Быстрое вращение энкодера будет приводить к пропускам, но это не имеет значения. my504(94 знак., 31.03.2022 08:09)
- Это зависит от того с какой скоростью вращать ось энкодера. Вращать
можно очень медленно или быстро. В моем энкодере на полный оборот
оси происходит 16 щелчков контактов. Поэтому, если делать один
оборот в секунду (быстрее уже сложновато), получается период около
63 мс. Некоторые индивидумы могут вращать и быстрее. mmc(623 знак., 30.03.2022 21:33)
- Я использую свою реализацию того же алгоритма, что в Вашей в
библиотеке. Это лучший алгоритм из того, что я пробовал. У меня
используются китайские энкодеры, они дребезжат очень сильно. С этим
алгоритмом по крайней мере у меня нет ошибок определения
направления вращения. Но он какой-то тормозной: не реагирует на
единственный щелчок энкодера, ему надо несколько щелчков, чтобы
обнаружить вращение. Возможно из-за сильного дребезга, то есть
большого количества ошибок. Не mmc(16 знак., 30.03.2022 20:54)
- Никак, просто для сведения. В мои задачах ошибки больше 1 не
случается (иногда на старте, т.к. неизвестно предыдущее состояние).
По сути служит для обнаружения дребезга или косяка по прошивке,
которая не успевает своевременно отрегулировать на фронт... POV(91 знак., 30.03.2022 20:38)
- Во , шо-то в этом роде на EXTI и хотелось. - PlainUser(30.03.2022 17:20)
- В этой "библиотеке" не понятно как влияет на принятие решения
значение encoder[num].err. Возможно оно как-то учитывается в
функции enc_check(), но ее реализации нет в архиве. - mmc(30.03.2022 20:20)