Выбор энкодера для координатника

[goga77]

Godzilla82
Спор наш теoретический , в реале такой счетчик будет врать , к тому-же считать нужно каждый фронт и спад сигналов и sin & cos , т.е. прерывания обязательно , при этом ,возможно ,нельзя будет отвлекаться на RS232.
Описанная мной ситуация возникает на датчиках , когда сигнал стоит на грани переключения ......и включается шпиндель станка.

[Godzilla82]

Godzilla82
Спор наш теoретический , в реале такой счетчик будет врать , к тому-же считать нужно каждый фронт и спад сигналов и sin & cos , т.е. прерывания обязательно , при этом ,возможно ,нельзя будет отвлекаться на RS232.
Описанная мной ситуация возникает на датчиках , когда сигнал стоит на грани переключения ......и включается шпиндель станка.

Ну вы сгущаете краски. Счётчик на МК, естесственно, считает каждый фронт и спад. Частота опроса одного датчика - до 200 кГц. Это с учётом отвлеканий на RS232. 200 кГц для колебаний в механике - уж слишком много. Большинство ограничивается 2-5 кГц.

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

[goga77]

Godzilla82

Дело не в частоте, а в том, что происходит смена направления туда-сюда,
все рассмотренные мной алгоритмы тут дают сбой, считать нужно аппаратно (2 сч-таймера на канал) +- потом вычислять разницу.
У меня есть датчики, есть счетчик ЛИР ,есть счетчик Хайденхайн с индикацией .Если есть желание проверить свою идею, и собрать счетчик с индикацией (к rs232 еще надо придумать программу опроса ) на МК готов помочь провести испытания (запаралелим датчик на 3 счетчика покрутим и посмотрим).
Я определяю исправность датчика по кол-ву импульсов между нулевыми метками.

С наилучшими пожеланиями Игорь.(Пора спать, жена ругается).

[Godzilla82]

Godzilla82
Дело не в частоте, а в том, что происходит смена направления туда-сюда,
все рассмотренные мной алгоритмы тут дают сбой, считать нужно и спад импульсов.

Если смена направлений будет происходить медленнее 200 кГц, то всё будет обсчитываться корректно. Ещё раз повторяюь. Учитывается и фронт и спад каждой фазы (А и В).

В реале смена направлений происходит с частотой 2-5 кГц.

[jump]

итак, мнения разделились, есть несколько решений:
- полностью покупные узлы (УЦИ и датчики);
- слабенький МК;
- мощный МК;
- МК с модулем квадратурного декодера;
- МК+ПЛИС/МК+дискретная логика;
- HCTL-2032+МК с обвязкой.
анализировать не буду, выше все сказано боле-мене полно.

Godzilla82,
я подтверждаю слова goga77, тем более обратите внимание на слова ТС об условиях работы устройства.
именно желание избавиться от ошибок универсальных МК и габаритов дискретной логики привело к встраиванию квадратурного декодера в МК.
все ж советую проверить на практике ваше решение в реальных условиях, на станке.

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

yura72,
расстояние от датчиков до места размещения УЦИ?
по CAN-интерфейсу в сети информации довольно много, даже на русском, даже на казусе.
как вариант - приблизить МК к датчикам (по одному на на канал) и передавать обработанные данные по скоростной магистрали, например, эзернет.
боюсь, что люфты не дадут получить заданную точность

[Alex9797]

Godzilla82,
я подтверждаю слова goga77, тем более обратите внимание на слова ТС об условиях работы устройства.

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

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

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

Учитывая вышесказанное, полностью согласен с нижесказанным:

как вариант - приблизить МК к датчикам (по одному на на канал) и передавать обработанные данные по скоростной магистрали, например, эзернет.

Для энкодеров с таким разрешением я вижу только такой вариант - на каждый энкодер по отдельному МК ("слабенькому"). Это здорово облегчит написание и отладку программы, по сравнению с вариантом "мощный МК".
И здорово разгрузит основной МК.

Связь МК энкодеров с основным МК я бы предпочел по интерфейсу попроще эзернета (и подешевле). Ведь насколько видно из условий работы - большая скорость передачи данных не требуется. Объект сравнительно медленно меняет положение в потоке воздуха, при этом считываются данные с других закрепленных на нем датчиков (не энкодеров). Поэтому нужен интерфейс не очень быстрый, надежный, и минимально отвлекающий МК от важной задачи - достоверного определения угла поворота энкодера, с учетом возможности высокочастотного дребезга.
Больше всего мне в данном применении нравится SPI. Могу обосновать этот выбор, если возникнет интерес. Да, у него многовато линий связи. Но при таком малом расстоянии до энкодеров - это не проблема.

боюсь, что люфты не дадут получить заданную точность

+100%! Но зато неточности будут на порядок или два лучше видны!

[Godzilla82]

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

Компаратор с гистерезисом уже входят в состав нормального энкодера. И это не парализует его работу. Кроме того, энкодер при этом отвечает заявленным скоростным параметрам. На выходе энкодера присутствуют чёткие логические ноль или единица независимо от положения (каким бы промежуточным оно не было).

Энкодер с 100 да и 500 импульсов на оборот - это мало. Так что не надо быть настолько пессиместичным. Всё будет работать. Вот люфты - это уже другая песня.

[imm9]

Речь шла о 3-х энкодерах. Набросал схемку, а также развёл платку

на мой взгляд всё же лучше использовать прерывания, как уже сказал goga77.
от каждого энкодера один из сигналов завести на вход внешнего прерывания (в данном случае например int0, int1, ain0), второй сигнал заводить на любой другой вход.
в обработчике проверять состояние этого второго сигнала, если 1 - то увеличение счета, если 0 - то уменьшение.

Int0_Handle:
in Buf,PinD
sbrc Buf,second_Pin
rjmp inc_label

;здесь уменьшение счета
...
inc_label:
;здесь увеличение счета
...

если перемещения по 3м осям не одновременно, то опрос состояний при обработчике в ~10 команд до 1-2 МГц, если одновременно - то в 3 раза ниже

передачу информации по каналу обмена можно выполнять в фоновом режиме, на быстродействие не влияет

наличие люфтов - проблема механики, и применение мощных контроллеров, плис, дискретной логики, dsp врядли целесообразно

[Alex9797]

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

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

На выходе энкодера присутствуют чёткие логические ноль или единица независимо от положения (каким бы промежуточным оно не было).

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

Энкодер с 100 да и 500 импульсов на оборот - это мало. Так что не надо быть настолько пессиместичным. Всё будет работать. Вот люфты - это уже другая песня.

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

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

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

[Godzilla82]

на мой взгляд всё же лучше использовать прерывания, как уже сказал goga77.
от каждого энкодера один из сигналов завести на вход внешнего прерывания (в данном случае например int0, int1, ain0), второй сигнал заводить на любой другой вход.
в обработчике проверять состояние этого второго сигнала, если 1 - то увеличение счета, если 0 - то уменьшение.

если перемещения по 3м осям не одновременно, то опрос состояний при обработчике в ~10 команд до 1-2 МГц, если одновременно - то в 3 раза ниже

Нужно тогда вешать прерывания на каждый вход. И в каждом прерывании сравнивать не с 1 или 0, а со значением второго входа. Если равны, то в зависимости от входа - увеличивать или уменьшать. Итого на 4 датчика понадобиться 8 прерываний. Многовато, однако... К тому же вход в прерывание и выход - ещё порядка 15-20 команд.

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

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

Десятки килогерц спокойно обрабатываются. И это вполне реалистично.