Search in topic

Линейные энкодеры

Тривиальность сразу пропадает, когда нужно определить абсолютные координаты.
Каким образом

1. кодировать абслютное расстояние на линейке (грубо говоря, числа),
2. нанести разметку с требуемой точностью,
3. распознать считанную информацию?

При начале работы станка по датчикам устанавливаемся в 0, потом танцуем от этого. Вот вам и абсолютные координаты.

Скорость работы сенсора ADNS-2620 (который обычно стоит в мышах) 12 in/sec (примерно 0,3 м/с).

Это приемлемая скорость поступления информации в микроконтроллер, если только считывать информацию о смещении. Если обрабатывать кадр для распознавания меток расстояния, скорость считывания кадров сильно упадет., поскольку нужно будет считать всю матрицу пикселов (18*18),
а потом еще и распознать. Опыт распознавания изображений есть?

P.S. Описание ADNS-2620 от Agillent называется 5988-9773EN.pdf

Я знаком с мышиными датчиками.
Зачем читать матрицу и обрабатывать кадры? Использовать абсолютный выход.
Еще - при использовании размеченной поверхности можно добиться точных результатов по перемещениям.

Также можно добавить абсолютный код через например каждый сантиметр. Никто не запрещает периодически юстироваться не спеша.

Вообще мне эта тема интересна, готов поучаствовать более конкретно.

Когда-то давно прикоснулся к теме измерения малых абсолютных перемещений. Две кварцевых полированных стекляшки, на которые напылен слой хрома в виде гребенок. А теперь представим две одинаковых расчески, которые наложены друг на друга зубьями навстречу, и одна перемещается по другой. При этом зубья одной периодически перекрывают просветы между зубьями другой. Вот так же и эти стекла. Точность определяется шириной получаемых вакуумным напылением и фотолитографией (тогда это был УФ) зубьев гребенки. Одна гребенка неподвижно закреплена, вторая связана с перемещаемым обьектом. А дальше оптическое преобразование и подсчет импульсов. Очень точно (доли микрона), но механически непрочно. Подобный принцип (с интерполяцией) применен в принтере, как описано выше.

Зачем читать матрицу и обрабатывать кадры? Использовать абсолютный выход.
Еще - при использовании размеченной поверхности можно добиться точных результатов по перемещениям.

Также можно добавить абсолютный код через например каждый сантиметр. Никто не запрещает периодически юстироваться не спеша.

Вообще мне эта тема интересна, готов поучаствовать более конкретно.

Давайте, попробуем, все же, перейти от общих формулировок к конкретике.

По поводу датчика из мыши:

1. Вывели портал в 0, считали координаты.
2. Начали перемещаться, в это время считываем с датчика инкремент по оси. Что будет при пропуске кадра или сбое в вычислении корреляции между кадрами? Ошибка в определении текущих координат.
3. Предположим, что через каждый сантиметр нанесены специальные метки. Как определить номер метки? Как вместе с меткой закодировать число? Предположим, что сделали это какой-то структурой из черных и белых точек, для метровой линейки их будет 100. Считали изображение, нужно сопоставить его с эталонными (их 100), и определить, какому оно соответствует (по корреляции, видимо). Не уверен, что микроконтроллер типа PIC16 или PIC18 в состоянии это быстро сделать. А если учесть колебания освещенности, загрязнения, то задача становится еще сложнее.

По поводу магнитного датчика:
Этот датчик, мне кажется более приспособленным к реальной жизни. Но тоже есть вопросы.

1. Каким образом наносить и кодировать информацию?
2. Как преодолеть зависимость амплитуды (и частоты, если использовать частотное или тональное кодирование) от скорости движения портала? При медленном перемещении можно вообще потерять сигнал.

Есть еще вариант, по такой схеме делают серийные энкодеры - к абсолютному энкодеру вращения прицепляют барабан с тросиком. Тоже есть куча вопросов, но эти делают, и продают серийно. Правда цена…

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

Вот я раскорячился.

По поводу приспособления энкодера вращения я думал, единственный вопрос - растяжение (периодическое) тросика. Хотя тонкий стальной тросик с предварительной натяжной иди зубчатым ремнем вроде должен держать нормально, усилия не большие. Вопрос получается в диаметре приводного валика, тут энкодеров из ШД не отдуешся, т.к. 400 импульсов на оборот это мало.

[quote=ATLab;268686]

P.S. Описание ADNS-2620 от Agillent называется 5988-9773EN.pdf

Не могу найтить, выложи куда-нибудь

Вообще-то уже относительно недорогие (порядка 50 баксов) энкодеры уже дают порядка 4к отсчетов на оборот.

А вообще, если уж так делать - это надо делать полноценный двойной плоттер - 4 канала управления шаговиками, 4 входа энкодеров, USB порт… 😉).

Давайте, попробуем, все же, перейти от общих формулировок к конкретике.

По поводу датчика из мыши:

1. Вывели портал в 0, считали координаты.
2. Начали перемещаться, в это время считываем с датчика инкремент по оси. Что будет при пропуске кадра или сбое в вычислении корреляции между кадрами? Ошибка в определении текущих координат.
3. Предположим, что через каждый сантиметр нанесены специальные метки. Как определить номер метки? Как вместе с меткой закодировать число? Предположим, что сделали это какой-то структурой из черных и белых точек, для метровой линейки их будет 100. Считали изображение, нужно сопоставить его с эталонными (их 100), и определить, какому оно соответствует (по корреляции, видимо). Не уверен, что микроконтроллер типа PIC16 или PIC18 в состоянии это быстро сделать. А если учесть колебания освещенности, загрязнения, то задача становится еще сложнее.

1. Проблем вроде нет. Но при наличии абсолютных меток выходить в 0 не нужно.
2. Никаких сбоев. Их просто нет. В серво-приводе енкодер по умолчанию не ошибается. Не ошибется и у нас.
3. Абсолютные метки. Подойдет любой код - двоичный, полосками-отверстиями, валет-дама-туз… Мы читаем его НЕ СПЕША (в случае например чтения матрицы с датчика мыщи) или на лету, в случае двоичного кода. Ничего распознавать никоми образом не нужно, не усложняйте.

По поводу магнитного датчика:
Этот датчик, мне кажется более приспособленным к реальной жизни. Но тоже есть вопросы.

1. Каким образом наносить и кодировать информацию?
2. Как преодолеть зависимость амплитуды (и частоты, если использовать частотное или тональное кодирование) от скорости движения портала? При медленном перемещении можно вообще потерять сигнал.

Магнитный датчик использовать тяжеловато… Это все-таки более механическое дело в отличие от оптики.

Есть еще вариант, по такой схеме делают серийные энкодеры - к абсолютному энкодеру вращения прицепляют барабан с тросиком. Тоже есть куча вопросов, но эти делают, и продают серийно. Правда цена…

Это без меня.

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

Давайте определим для начала цели и задачи. И от этого оттолкнемся.

Есть еще вот такой принцип линейной шкалы (на фотке).

Давайте определим для начала цели и задачи. И от этого оттолкнемся.

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

Sergey_Murzinov
Описание ADNS-2620 от Agillent называется 5988-9773EN.pdf
Не могу найтить, выложи куда-нибудь

Выложил: webfile.ru/894231, пароль ADNS2620, доступен до 12 апреля 2006 г.

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

Упаси тебя Будда использовать это для управления сервомоторами без резервного определения перемещения по валу мотора. Иначе- порталы ЛЕТАЮТ!
Ты наворачиваешь станок цепью из десятка деталей, которые могут сломаться, порваться, заклинить, замараться… Вместо одного энкодера , который ближе всего в приводу.
Ты увеличиваешь в десятки раз вероятность отказа…
А если тебе ставить резервку- так смысл всего этого дубляжа?
Если шпиндель точен ( а он точнее и стабильнее линейного энкодера) - то ты просто наворачиваешь станок лишней и дорогой системой.
ИМХО- либо промышленные дорогущие стеклянные шкалы, либо дешевый энкодер на вал.
Третьего- не дано…

Ппредлагаю простой линейный энкодер… 😁
На столе… полотно от рулетки, а на движущейся части… WEB - камера с нестандартной оптикой… и фонариком, вероятно… Дело за небольшим - грамотным ПО!
(Шутка с долей истинны!)

Ппредлагаю простой линейный энкодер… 😁
На столе… полотно от рулетки, а на движущейся части… WEB - камера с нестандартной оптикой… и фонариком, вероятно… Дело за небольшим - грамотным ПО!
(Шутка с долей истинны!)

Не, web-камера точно не подойдет, вот она стоит у меня перед глазами 6408480 USB2- все движения получаются смазанными. Прикидываю, как от нее изображение забрать в свою программу, выходит, что без Windows никак. А про то, что в Windows плохо управлять двигателями станка уже много написано. Да и обрабатывать изображение нехилое быстродействие нужно - фотография в BMP занимает 921 кбайт, уж лучше мышиный датчик. Не всегда много пикселей хорошо.

Народ на сайте www.usdigital.com/products/lin/ есть описание линеных энкодеров. Вот только не могу всосать как получают сигналы двух каналов выходов

Прикольно. Линейку на коленке делать. Это фокус. Всё таки как вы собираетесь риски например, с шагом 0,02 и с высокой точностью на линейку наносить?

Допустим, не на стекло, а на лавсановую плёнку. Всё равно, как?

ATLab,

линейка с абсолютными координатами, это ещё сложноватистей. Принцип то простой, контроллер с памятью и интерфейсным портом на головку ставится. Для снижения обрабатываемого объёма данных, сброс счётчиков на каждой индеферентной метке, например, через каждые 20 мм. Для скорости выставки, каждая метка кодируется.

Но сделать это (естественно точно) не так уж просто. Поэтому хорошая линейка дорого стОит, примерно 1$ - 1мм.

ATLab,

линейка с абсолютными координатами, это ещё сложноватистей. Принцип то простой, контроллер с памятью и интерфейсным портом на головку ставится. Для снижения обрабатываемого объёма данных, сброс счётчиков на каждой индеферентной метке, например, через каждые 20 мм. Для скорости выставки, каждая метка кодируется.

Но сделать это (естественно точно) не так уж просто. Поэтому хорошая линейка дорого стОит, примерно 1$ - 1мм.

А я не спорю, конечно, получить абсолюгные координаты сложнее. Только я не вижу смысла делать линейный энкодер без этого, а для относительных вполне достаточно энкодера на валу.
Как обработать сигнал с камеры я представляю - бОльшую часть трудовой биографии занимаюсь цифровой схемотехникой, микропроцессорами и микроконтроллерами, в том числе и программирую - может поэтому и не предвижу легкости в обработке (распознавании) изображения. Цифровой обработкой изображений интересовался еще в студенческие времена - элементная база за это время изменилась, а принципы обработки и формулы - нет.
Убежден, что простым микроконтроллером типа PIC16, PIC18 в реальном времени слежения за линейкой и распознавания абсолютных меток не сделать, не нужно иллюзий по этому поводу.

Не, web-камера точно не подойдет…

Далее… А сенсор, аналогичный сенсору сканера? Линией вдоль линейки? Закодировать абсолютные координаты в ширине рисок линейки (допустим, десяток узких - синхронизирующих, за ними широкая - стартовая и следом кодовая комбинация из широких и узких? При этом, если сенсор будет сразу пару комбинаций, допустим, будет обозревать… то абсолютную координату сможет вычислить в любом положении… ?!
Разместить счёт для авторских отчислений? 😅

Допустим, на лазерном принтере риски на шкалу напечатаете. Например, 600 DPI, составит 0,0423 мм/шаг, предположим, машине с такой линейкой надо на 0,2 мм двинуться. 0,2:0,0423=4,728 шага. То есть 5 полных шагов. 5*0,0423=0,2115. При этом погрешность перемещения составит 0,2115-0,2=0,011 На сотне таких перемещений погрешность составит более миллиметра, на тысяче - 11,5 мм.

И дело даже не в дюймах, а в некратности шагу машины.

Само собой, принтер штука не точная, шестерёночки пластиковые, протяг не совершенный, такая шкала точность будет иметь + 0,5 мм на 0,25 м.

Не верите - файлик приложенный распечатайте, например на HP 6L и металлической линейкой по ГОСТ 427-75 измерьте.

Рачпечатали?

Полосочки по фону видите? Муар называется. Это вы как раз вышеописанную погрешность наблюдаете. Не даст он вам точно работать, да и полосатить всегда будет. Шкала конечно хилая, 1000 линий, 0,25мм/шаг, на серъёзной шкале всё будет гораздо хуже.

Кто то скажет - для хобби пойдёт. Ну если хотите вместо кругов овалы резать, фоны полосатить, размеры не выдерживать, и на миллиметры и сантиметры уезжать - тогда пожалуйста…

В общем кому время не жалко терять, балуйтесь 😃

BALAL,

Примерно так и делается, так что авторские отчисления не грозят 😃

ATLab,

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

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

А линейка это ЛИНЕЙКА.

Galant1,

“Иначе- порталы ЛЕТАЮТ!”

Дальше концевика не улетит 😃

_____1.rar

Дальше концевика не улетит 😃

С шаговиками- да…
А вот сервачок даст так даст…
И штука под сотню кг, со всей дури наехавшая на концевик, думаю, в этом месте не остановится…

Допустим, на лазерном принтере риски на шкалу напечатаете. Например, 600 DPI, составит 0,0423 мм/шаг, предположим, машине с такой линейкой надо на 0,2 мм двинуться. 0,2:0,0423=4,728 шага. То есть 5 полных шагов. 5*0,0423=0,2115. При этом погрешность перемещения составит 0,2115-0,2=0,011 На сотне таких перемещений погрешность составит более миллиметра, на тысяче - 11,5 мм.

И дело даже не в дюймах, а в некратности шагу машины.

Само собой, принтер штука не точная, шестерёночки пластиковые, протяг не совершенный, такая шкала точность будет иметь + 0,5 мм на 0,25 м.

Угу. Распечатал. На 5и струйниках и 3х лазерниках. На струйниках печатаем на пленке от Lomond. На лазерниках - на пленке от Basf.

• Первый струйник офисник HP2250 - лучше не смотреть. Полоски неравномерной высоты, многие слились, расстояние между ними гуляет. Разворот на 90градусов ничего не дает. Отстой.

• Второй струйник мыльница HP Psc1300 - уже что-то. Ширина полос равномерна, как и растояние. Но - полосы имеют ширину меньше, чем растояние. Требуется эксперимент.

• Третий струйник - Lexmark Z52. Ширина полос и растояние идеальны. Похоже, черный печатал смесью цветов, но лучший из трех.

• Четвертый струйник - Epson Photo 950. Полосы черные и ровные. Растояние и ширина идеальны. Черный цвет глубокий, полоски практически без облоя. Лучший вариант для струйника.

• Пятый струйник - Epson Photo R240. Все ИДЕАЛЬНО! Я ожидал качества - но такого! Хотя он современен и совсем новый, чего и следовало ожидать.

• Первый лазерник - пресловутый HP 6L. Полоски серо-черные. Встречаются незаполненные (как из двух штрихов). Растояние идеально, ширина плавает. Отстой.

• Второй лазерник - HP LJ 2420. Все ровненько и красиво. Уровень 4-го струйника, но облой еще меньше. Заполнение немного хоже, что странно…

• Третий лазерник - Samsung ML3561. Это корейское “чудо” показало, что печатает лучше всех. Облоя НЕТ, полосы по ширине и растоянию идеальны. Чернота отличная.

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

Выводы.

• чем современней принтер, тем точнее и лучше он печатает. Использовать технику 95 года разработки для точных работ не рекомендуется.

• В Кореле можно рисовать разными методами. Полоса определенной ширины не совсем то же, что заполненый прямоугольник.

• Печать на бумаге и на пленке дает разные результаты.

В аттаче файл, который был сделан как альтернативный вышеприведенному. На нем получены лучшие результаты.

Также. Есть такая штука, как коэффициенты пересчета. Разрядность мантиссы 32 бита.
Так же некоторый софт пересчитывает _каждый_ импульс с енкодера, а не суммирует результаты. Никакого накопления ошибки не происходит.
Так же енкодер делается с _широкими_ опто-датчиками, в каждый момент времени работает не одна, а множество полосок.

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

Давайте все-таки отталкиваться не от теории, а от практики. Сделанный для теста экспериментальный енкодер с 1800имп на оборот (правда, диаметром 95мм) - все-таки показатель. И портал ездит как надо, и после часа езды возвращается в обратную точку с точностью до импульса или 0.05мм.

Потратил кучу и так отсутствующего времени, поэтому злой. Но довольный 😃.

И штука под сотню кг, со всей дури наехавшая на концевик, думаю, в этом месте не остановится…

Без проблем.

Смотря как и на чем едет…
с дохлым ДШ-200 с подачей 1000 мм/мин может и без проблем…
С хорошим серво- концевик может и обеспечит обесточивание движка, но тормозные функции выполнить не успеет и не сможет…
И буде большой “БАХ!”…

maxvovk,

"Так же енкодер делается с _широкими_ опто-датчиками, в каждый момент времени работает не одна, а множество полосок.

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

На меня намекаете? Я лично Вам в приват высылал конструкцию одного из энкодеров со специальной конфигурацией многощелевого окна. Специально для Вас делал микрофотографию под микроскопом, и подробно объяснял особенности конфигурации щелей, преимущества конструкции и способы снижения погрешности. Терял своё время. А Вы мне ещё отвечали, что понимать отказываетесь, или что то в этом роде.

В итоге, вместо спасибо - типа кто то не знал или умалчивал…

Теперь моя очередь отказываться понимать. Или невнимательно читаете?

Что вы называете качественным решением? Оптическую шкалу линейного датчика перемещений станка ЧПУ, напечатанную на принтере? +_ 1 мм, с муаром?

Не смешите.

И программная компенсация, это всё фигня. Информации от этого не добавляется, и погрешность не уходит, а размазывается, и трансформируется в другие ошибки.

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

Мне особо спорить ни с кем не хочется. Если бы всё было так просто, наверное такие фирмы не процветали бы:
www.real-inter.com/rus/lm.htm

Есть у меня такие линейки. Это вещь. Вот когда такие же риски, как на них, на принтере сделаете, тогда и поговорим.

Galant1,

“И буде большой “БАХ!”…”

Какой бах?

У меня серво - 15 м/мин, вес каретки - килограмм 150, в концевик влетает, становится как вкопанный.

Только резюк балластный в цепи тормоза нагревается.