Инкрементальный энкодер с декодером.

Всем привет. Сделал энкодер сразу с декодером. Как результат, раньше обработка дребезга, декодирование и подсчет импульсов с двух энкодеров, занимали 1500 байт и были нигко говоря не тривиальны. Сейчас ВСЁ в обработчике прерывания Несколько If и оно просто считает, занимая 200 байт. Использовал LS7084.

[attachment=0]IMG_20160618_100339.jpg[/attachment


http://**************************/download/file.php?id=28184&sid=7a108ce9eb37c2f626 2e0760b641a1c5

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

0

Сообщение от ShodS Сообщение от инкер Вот простейший код от ЛИ http://rodyokot.ru/forum/viewtopys.php? ... 2#p1352349 http://soxopa.ru/207402.html

Спасибо за наводку.

0

Сообщение от Tosh Это неверно. Врет и путает. Я уже жалею, что спрятал пояснения под спойлер.

Я читал под спойлером. От дрожания вала из комбинации 0-1-3-2-0... будут попарно возникать какие-то наугад выбранные из последовательности пары, например 1-3-1-3. Но они правильные в том смысле, что цифры соседние и любая корректная программа будет делать +\- 1 в счетчике, накопление ошибки не возникнет.
Сейчас глянул программу, она построена на обработке прерываний по любому фронту и тупом анализе состояния ножек и ветвлениям с выходом на суммирование/вычитание трехбайтного счетчика в ОЗУ. Да, с объемом немного ошибся, ассемблер в словах дает 46, значит 92 байта, но учитывая загрузки-выгрузки, возможно дублирующие анализы, то можно существенно сократить.

0

Сообщение от инкер Если переход запрещенный (типа 0 - 3, 2 - 1), то пробовал две тактики - игнорировать вообще или не считать, но обновить запомненное состояние на текущее. Не работает хорошо ни так, ни так.

Наверно, я знаю причину. При "игнорировании" надо "не возвращать" состояние (игнорировать), но само значение учитывать в следующем тике. Возможная ошибка - игнорировать не только return_value, но и само значение. Ну, как вариант. ))
Бороться с дребезгом можно, но не шибко эффективно - избыточной информации крайне мало, как восстанавливать не известно.
Опираться можно только на инерционность механического устройства, данные могут поступать только с =периодичностью=, человек не может резко поменять скорость вращения и знак. И здесь попрет мощная математика... Никакого "пропуска" или "игнорирования", только вероятностный анализ. Грубо говоря, предыдущиЕ отсчеты поступали ранее с интервалом Т, новый следует ожидать через тот-же интервал Т, при этом достоверность получения данных принимается за 100% при совпадении по времени с отметкой Т и эта достоверность падает при приходе события ранее или позже отсчета Т. Если отсчета небыло вовсе, то следует ожидать "еще следующего" отсчета (i+2) в отсчет 2Т +/-delta. Т.е. на поступающие данные накладывается шаблон и смотрится на меру совпадения. При высоком совпадении данные попадают на выход (при необходимости довставляются пропущенные сотояния), при низком - используются только для синхронизации съема отсчетов Т.
IMHO ))

0

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

0

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

Я проработал все варианты(прошу поверить), но в итоге скатал код из статьи "AVR. Учебный Курс. Инкрементальный энкодер".
Это как раз и есть вероятностный анализ. Поставил таймер на вход данных чтобы понимать что все что чаще мусор. Перед изменением главного счетчика я жду два одинаковых прихода подряд только на 3й меняю счетчик(мне не нужна высокая точность).
Опять вернусь к началу, теперь ВСЯ обработка дребезга и предсказаний это резистор задержки и вот этот код:
Боюсь предложений мелкого улучшайзинга, но короче некуда.
При этом вся обработка поместилась между ножек энкодера. Но! себестоимость 4$, Но! паять только на 3 детали больше.

Думал белая страница глючит и наплодил 5 копий, оказывается на новую перешло :(. Задалбывает

инкер, собственное.

0

Сообщение от инкер Я читал под спойлером. От дрожания вала из комбинации 0-1-3-2-0... будут попарно возникать какие-то наугад выбранные из последовательности пары, например 1-3-1-3. Но они правильные в том смысле, что цифры соседние и любая корректная программа будет делать +\- 1 в счетчике, накопление ошибки не возникнет.

Тут у нас просто возникла путаница с размытыми терминами "правильная", "врет", "путает"... :) Конечно, именно корректная программа будет это "вранье" исправлять. Мне встречались реализации, в которых программа в этом случае будет тупо гнать в одну сторону при стоящем, но вибрирующем вале. Например, даже метод из упомянутого здесь неоднократно "Учебного курса" (!). :)

0

Сообщение от u37 Бороться с дребезгом можно, но не шибко эффективно - избыточной информации крайне мало, как восстанавливать не известно. Опираться можно только на инерционность механического устройства, данные могут поступать только с =периодичностью=, человек не может резко поменять скорость вращения и знак. И здесь попрет мощная математика... Никакого "пропуска" или "игнорирования", только вероятностный анализ.

Тоже приходят подобные мысли (повторюсь, механическими энкодерами я только начинаю заниматься, и то эпизодами). Приходят они прежде всего в связи с тем, что по моим небольшим исследованиям, длительность дребезга существенно зависит от скорости вращения и напрашивается адаптивная задержка при борьбе с дребезгом этим методом. Кстати, кто-то же наверняка снимал осциллограммы конкретных энкодеров? Не поделитесь? Хочется набрать некую базу их разнообразия. Прежде всего интересен такой момент. В идеале у энкодера два меиндра, сдвинутые на 90 градусов. Но в механических, которые мне встречались, сигнал существенно отличается от меиндра - пара сдвинутых импульсов с достаточно большой паузой. Как у вас? ;)

0

Сообщение от Tosh даже метод из упомянутого здесь неоднократно "Учебного курса" (!). :)

Да вроде нет, просто при дрожании вала будет дрожать счетчик в пределах +\- единицы. К сожалению в СИ не ориентируюсь, поэтому не понял, что будет происходить при появлении после нуля "запрещенной" тройки? Счета не будет, а перезапишется ли значение в памяти состояния.
У меня принцип как у Ди Хальта и, (рву волосы) значение перезаписывается всегда, что есть открытая дверь для ошибок. Например, после 0 появляется 3 вместо ожидаемой 1, значение перезаписалось, счетчик не изменился (тройка запрещена), однако при восстановлении контакта появится 1, а она после 3 означает движение в противоположную сторону от реального. Естественно счетчик сдвинется в неправильную сторону. :-((

0

Сообщение от инкер Сообщение от Tosh даже метод из упомянутого здесь неоднократно "Учебного курса" (!). :)

Да вроде нет, просто при дрожании вала будет дрожать счетчик в пределах +\- единицы.
Это у меня так. :) А здесь - давайте посмотрим.

Так что без проблем можно применять прерывания. И тогда все упрощается неимоверно. Настраиваем всего одно прерывание по внешнему сигналу. Например, INT0 настраиваем так, чтобы сработка шла по восходящему фронту. И подаем на INT0 канал А. http://i72.***********/big/2016/0621/a9/8066e71b6ee0e22ca83ea5eea18605a9.gif Пунктиром показано предполагаемое положение в произвольный момент. Красные стрелки это фронты по которым сработают прерывания при движении либо в одну, либо в другую сторону. А в обработчике прерывания INT0 щупаем вторым выводом канал В. И дальше все элементарно! Если там высокий уровень — делаем +1, если низкий -1 нашему счетному регистру. Кода на три строчки, мне даже писать его лень.

Ну, например, болтаемся возле левой красной стрелки (напоминаю - прерывание по положительному фронту!).
1. Едем влево. Положительный фронт, прерывание, B=1, +1
2. Едем вправо. Отрицательный фронт, прерывания нет, счетчик не меняется.
3. Goto 1.
Как видим, будет постоянный инкремент счетчика. Со второй стрелкой то же самое, только будет постоянный декремент. Представляете, что он насчитает, если будет так сыпать с частотой вибрации?

0

Сообщение от инкер что будет происходить при появлении после нуля "запрещенной" тройки? Счета не будет, а перезапишется ли значение в памяти состояния. У меня принцип как у Ди Хальта и, (рву волосы) значение перезаписывается всегда, что есть открытая дверь для ошибок. Например, после 0 появляется 3 вместо ожидаемой 1, значение перезаписалось, счетчик не изменился (тройка запрещена), однако при восстановлении контакта появится 1, а она после 3 означает движение в противоположную сторону от реального. Естественно счетчик сдвинется в неправильную сторону. :-((

Ну да, у DY HOTT тоже так - состояние перезаписывается в любом случае.

0

Да, пропускать изменения состояния входов нельзя.
Можно представить другую ситуацию- короткий отрыв контакта, положительный фронт обработается +, а падающий нет. Лишний импульс в счетчике даже без изменения направления.

0

Придется в Протеусе одним контроллером сымитировать энкодер с дребезгом, а на втором откатывать программу декодера.

0

Все-таки я достаточно пессимистично отношусь к анализу состояний "в лоб" на фоне дребезга. Мне кажется, нужно искать нестандартные идеи, базирующиеся на анализе особенностей сигнала. Я уже вижу, как минимум, 3 зацепки. Но, повторюсь, все это в совершенно сыром виде, не проверено, поэтому и говорить пока рано. Может, попозже проработаю это основательно и тогда выложу. Если это будет интересно.

0

Да объясните уже хоть кто-нибудь: у вас действительно дребезг продолжается дольше, чем поворот энкодера в следующую позицию?

Если нет - что вообще обсуждается?

Если да - как вы в таких условиях хотите вообще хоть что-то получить? Нет, ну можно, конечно, сигналы A и B тупо сгладить (и получать из них фазу или скорость вращения), но это ненормально. Да и не вижу, чтобы кто-то предлагал их сглаживать.

0

Сообщение от oomomstir Да объясните уже хоть кто-нибудь: у вас действительно дребезг продолжается дольше, чем поворот энкодера в следующую позицию?

Что показало чтение всего про механические энкодеры
- да, дребезжат, особенно дешевые или по мере износа
- дребезг может быть по времени до 50 мс (есть утверждения про 100)
- при больших скоростях поворота это может заполнить существенную часть периода
- при малых скоростях начинает сказываться медленное схождение-расхождение контактов, что приводит опять к затяжному дребезгу
- физический фильтр в паре с программной поддержкой улучшает ситуацию, если дребезг занимает небольшуую часть периода, но накладывает ограничения на диапазон скоростей поворота
- обсуждений настолько много, что считать проблему надуманной нет оснований, универсального рецепта не нашлось

Чего не попалось (естественно я не все, что есть в сети, прочел) - особенность дребезга, которая может использоваться для построения эффективного фильтра - в ряду последовательности чисел на выходе идеального энкодера ( 01320... или 02310...) дребезг проявляется как увеличение " правильного" числа на одну, две или три единицы, но никогда не уменьшение. Это для схемы с общим выводом на земле. Самое плохое число ноль, он может размножиться на группу любых других чисел, тройка, если она настоящая, а не продукт дребега, всегда тройка.

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

0

Ну, если тупо подавить дребезг (до обработки квадратурного сигнала) - так и получится.

0

Как идея разобрать переменный резистор, сломать ограничитель поворота, программно обработать перескок значения с максимума на минимум и наоборот и получить энкодер с настраиваемым количеством шагов на оборот, простой фильтрацией "шороха" конденсатором?

0