Драйвер/ счетчик инкрементального энкодера

[Igor_Naum]

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

Задача: Организация обратной связи для станка ЧПУ на шаговых двигателях (3 шт.) с энкодерами на валу...

Собственно управление шаговыми двигателями выглядит так: МК(PIC18f6520) - шина SPI - драйвер L6470 (SPI) - ШД. В принципе ничто не мешает выход с энкодера подавать прямо на свободные ноги МК.
Но в этом случае микроконтроллер будет все время занят во время работы ШД (а он должен еще периодически опрашивать состояния драйверов L6470 и выводить инфу на графический ЖК).
Использовать модуль встроенного счетчика не получается, т.к. процессор все равно должен отвлекаться на то чтобы определить направление "тика" и инкреминтировать или декрементировать абсолютное положение вала...

Вот есть LS7366 http://www.alldatasheet.com/datasheet-p ... S7366.html
Но его не достать... Есть ли похожие аналоги, может кто сталкивался?

Спасибо...

[uk8amk]

PIC18F4431
Motion Feedback Module w/ Quadrature Encoder Interface
http://www.microchip.com/wwwproducts/en/PIC18F4431

Если pic не столь принципиален, то к многие stm32 поддерживают 3-4 инкрементальных энкодера на аппаратном уровне.

[Igor_Naum]

Это действительно интересно и еще одна галочка в пользу STM.
Пока с ними не сталкивался лоб в лоб...

А с PIC похоже возможно подключение только одного энкодера.

[wws63]

Может вот это пригодится.
Как вариант обработки сигналов энкодера.
Схемка с просторов инета

[BOB51]

Или соорудить собственный вариант LS7366 на каком-нибудь малолапом МК (ПИК/АВР)

[Igor_Naum]

Спасибо за советы.
Было над чем подумать...

Думаю наиболее оптимальный вариант все-таки такой, "аппаратную" часть счетчика энкодера совместить на одной плате с драйвером ШД.
Счетчик энкодера организовать на МК и возможно (пока не знаю как) обеспечить отслеживание положение вала и обратную связь внутри одного модуля ШД, не привлекая к работе МК основного контроллера...
Получается вполне логично - все транзакции между контроллером и модулями ШД происходят по SPI, а уж сами модули следят за выполнением инструкции и в крайнем случае передают ТРЕВОГУ головному МК

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

Станок кстати намоточный, поэтому инструкций по SPI будут в процессе работы меняться не так быстро.

[Igor_Naum]

Вот общий вид, если кому интересно, отладочного комплекта - контроллер + 1 модуль ШД
http://img.radiokot.ru/files/84082/medium/zlbjp9fk0.jpg

[Jurkin]

..чёт Вы тут перегибаете Задача похоже никакая, а сгородить хотите космический корабль. Вот не увидел пока сколько же импульсов на оборот даёт энкодер и с какой максимальной скоростью он будет крутится - ну в принципе нужно знать хотяб максимальную частоту идущих с энкодера импульсов которые нужно обсасывать. Одно дело сотни килогерц к примеру от датчика где 2048 имп/об и 3000 об/мин , другое, 100 имп/об при 500 об/мин. Отсюда надо и плясать - успеет один МК всё сделать или не успеет, а так Вы ведёте разговор ни о чём.

[Igor_Naum]

Хорошо. что спросили...
Я то по наивности даже не прикидывал максимальную частоту импульсов - думал все равно МК быстрее, особенно если освободить его от других задач.

Серия шаговиков от LeadShine со встроенным энкодером.
http://www.purelogic.ru/files/downloads ... d_V1.3.pdf
Максимальная частота энкодера указана 100Кгц.
1000 импульсов на оборот энкодер вроде выдает.

Максимальная скорость шпинделя будет 1500об/мин. (хотя это под вопросом, важнее точность позиционирования каретки - а там скорости другие совсем). Но все-таки прикинем по максимуму 1500 об/мин = 25 об/сек * 1000 импульсов = 25 Кгц. Максимальная частота между 2 мя каналами 50 Кгц получается.
20мкс на обнаружение импульса, определение его направления, инкремент или декремент счетного регистра.

Если продумать код то и 8 Мгц должно хватить

[Svitoglad]

Если продумать код то и 8 Мгц должно хватить

Вот вам еще немного информации.
Сообщение #160 http://www.cnczone.ru/forums/index.php? ... 334&st=150

[Jurkin]

Максимальная скорость шпинделя будет 1500об/мин. (хотя это под вопросом, важнее точность позиционирования каретки - а там скорости другие совсем). Но все-таки прикинем по максимуму 1500 об/мин = 25 об/сек * 1000 импульсов = 25 Кгц. Максимальная частота между 2 мя каналами 50 Кгц получается.
20мкс на обнаружение импульса, определение его направления, инкремент или декремент счетного регистра.

Если продумать код то и 8 Мгц должно хватить

...вот не понимаю, нафик намоточному станку 1000 имп/об , ну фигня, всё равно даж с такими временными характеристиками можно легко успеть всё обработать одним МК без особого напряга.
Вот прилагаю осцилограмку своей одной аналогичной разработки - задача стояла другая маленько но суть таже. Чтоб не потерять (или добавить) ни одного лишнего импульса во время реверса, обработку нужно делать два раза за период. Вот на моей осцилограмке как видно частота 122 kHz это с энкодера 2048 имп/об т.е. скорость получается чуть более 3500 об/мин.
И нет тут ни каких 20мкс. МК авр на 10 MHz. Импульсы на красненькой D3 как раз здесь показывают время работы кода в прерывании. Всё успевается с лихвой, и ещё один такой энкодер запросто успеет обсосать и ещё кучу всего делать.

[Igor_Naum]

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

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

Честно - не понял осциллограмму. И что делается в обработчике прерываний, и почему мы туда попадаем не сразу после импульса.
Для меня логичней было бы в обработчике //1/ регистрировать шаг // 2/ определять направление в зависимости от предыдущего состояния // 3/ ++ или -- счетной переменной // 4/ перезапись старого состояния новым // и возврат к основному циклу.
Громоздко, но по-другому не пропустить импульса я не знаю как...

[Albert_V]

Очень желательно отрабатывать сигнал с фотодатчика по INT и по фронту и по спаду.
Дело в том, что получить "дребезг" с датчика в реальном изделии достаточно легко.
Если отрабатывать только по фронту (или спаду) - "дребезг" будет воспринят как "лишние шаги" или вращение при остановленном вале.
/я это "проходил" с оптическими валкодерами/

[Igor_Naum]

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

Разобрался, кажется, по осциллограмме.
Там реализовано прерывание от таймера через равные промежутки времени.
Какое преимущество это дает по сравнению с прерыванием от изменения состояния на выводе?

[Albert_V]

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

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

[Jurkin]

Честно - не понял осциллограмму. И что делается в обработчике прерываний, и почему мы туда попадаем не сразу после импульса.
Для меня логичней было бы в обработчике //1/ регистрировать шаг // 2/ определять направление в зависимости от предыдущего состояния // 3/ ++ или -- счетной переменной // 4/ перезапись старого состояния новым // и возврат к основному циклу.
Громоздко, но по-другому не пропустить импульса я не знаю как...

...поясняю. D7 и D6 выход энкодера, D3 - пин МК переводится в 1 когда начинается обработка прерывания активируемая сменой состояния D7. И переводится в 0 когда закончена обработка прерывания. На осцилограмме отклик на событие происходит через 1 мкс. Позже я чуток оптимизировал код и это время сократил гдет до 0,5мкс. В АВР отклик на прерывание 4 машинных цикла, + переключение порта.(При 10 MHz 1 машинный цикл = 0,1 мкс)
На моей осцилограмме в первом полупериоде код выполнянтся дольше потому как там ещё выполнянтся сравнение полученного номера импульса с константой. Эт я делал виртуальный ноль датчику - нужен был для моей задачи.

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