Некоторая паника в связи с изменением статуса SafeNet не только по токенам…
Может можете сказать что ни будь про судьбу линейки HSM плат с SDK FM модуля?
Я имею в виду линейку Eracom (в девичестве) плат PSO->PSG->PSI-E->…
Мало того что последняя смена платформы (другая архитектра проца) напрягает, так и очень беспокоит судьба этой линейки.
После того как Axalta (Schlumberger) проглотила Gemplus с инженерной инновационностью в Gemalto стало так же как в Axalto… Т.е. никак. А вот с бизнес решениями (что бы еще с содрать с клиентов, не делая ничего) все хорошо.
И риск того, что «успешный менеджер» в GemAlto решит закрыть выпуск этой линейки HSM (что бы платили за кастомизацию прошивок в GemAlto, а не делали сами) весьма велик.
Было бы очень интересно, если бы кто провел физический эксперимент. Для сравнения «с» и «без».
Я делал аналогично без контура по току. Переделывать уже существующую конструкцию наверное уже не буду.
Но на будущее очень было бы интересно знать насколько это на практике дает преимущество.
Все же добавление «лишних» деталей — это добавление лишних деталей. Да еще аналоговой части схемы…
Вдруг кто ни будь займется и выложит результаты с сравнением по факту для конкретного двигателя/режима.
В принципе, интересный вариант, но именно для подержания малой скорости в длительный промежуток времени. Для ЧПУ похоже мало применим.
Единственный выход, как мне видится — энкодер более высокого разрешения. Хотя была надежда на «магические» варианты, которые я просто упускаю из виду.
Но что было под рукой (512/оборот) то и поставил. А он дает 0.5 мм линейного перемещения на отсчет и этого очень мало для четкой фиксации скорости на участке скажем в 500ms. Всего 2 отсчета на 1 мм/сек. Никакая регулировка не справится.
Из исходной задачи — перемещение каретки по заданной траектории по G-кодам (только X,Y без Z) требуется контролировать скорость 2-х моторов + координату (да еще с преобразованием из декартовых в полярные).
Собственно, расчет траектории по G-коду один из стандартных и самых простых. Разбиение каждой команды G0/G1 на участки (для данного варианта шаг 400ms) с постоянной скоростью и координатами начала/конца с предпросмотром на следующую команду G кода (нужно ли торможение и пр. исходя из ограничения по максимальному ускорению).
Для шаговых двигателей этим все и заканчивается. На входе модуля управления шаговиками: количество шагов(перемещение)+частота шагов(скорость).
Для конструкции на коллекторном моторе использую контур PID контроля скорости и положения. На входе те же самые данные модуля расчета траектории: перемещение (только в абсолютных координатах) + скорость.
Задача «переместится» в заданное значение энкодера, поддерживая как можно точнее заданную скорость.
Все нормально работает для относительно высоких скоростей (отклонение в пределах 1% от заданной скорости).
И Вы правы. Проблема, что при фактическом (с учетом редуктора) разрешении энкодера 14-16 отчетов на оборот двигателя, явно не возможно обеспечить заданную скорость с требуемой точностью для всех диапазонов перемещений и скоростей. (энкодер не на валу двигателя, а на измерительном ролике).
На практике это выглядит, как волнистая линия (2..5 мм отклонения от требуемой) на стене вместо прямой прочерченная фломастером (фломастер на каретке).
Впрочем, я изначально планировал рисование по растру с фиксацией одного из моторов. Просто захотелось попробовать еще и по G-коду перемещения сделать. Похоже все одно не выйдет для данной конструкции.
Спасибо, что уделили внимание. То что Вы рассказываете в любом случае очень интересно. Чужой опыт то же бесценен.
Энкодер стоит не на валу двигателя, а на измерительном ролике. Для точного измерения длинны троса. На катушку на валу червячного редуктора идет намотка в навал 20м троса (т.е. ставить энкодер на валу двигателя смысла нет).
Разрешение энкодера в 512/оборот для выбранного диаметра измерительного ролика дает около 0.5 мм/на отсчет энкодера для линейное перемещение троса…
в результате 12-16 отсчетов энкодера на оборот вала двигателя. ШИМ аппаратный 20Кгц. частота расчета скорости — раз в 100ms (чаще нет смысла).
Обработка каналов энкодера — аппаратный режим/счетчики STM32F103. Производительности для обслуживания 2-х двигателей (все на прерываниях по таймерам) для таких времен хватает с избытком. Еще и на вывод графики на экран и расчет траектории остается.
Но, наверное, я слишком много хочу и стабильной скорости подачи троса для 1-3 мм/сек в при таких условиях (разрещения энкодера) добиться в принципе нельзя.
Хотя уже 5mm/сек и выше вполне стабильно (по данным координата/скорость в реальном времени от контроллера).
Но раз говорите что для коллекторного двигателя может улучшить результат управление током… попробую добавить.
Жаль в шлейфе запасных линий не предусмотрел.
Кстати, а как грамотно снять бы? Операционником падение напряжение на токовом шунте, а потом ADC усреднить за период PID? (1Мгц частота ADC у STM32F3) А с какой частотой PID по току лучше делать, при ШИМ 20Кгц?
Подскажите пожалуйста, никогда этой темой не занимался.
Большое спасибо за статью и особенно за иллюстрации с графиками! Весьма познавательно.
Не могли бы Вы, опираясь на свой опыт, подсказать мне…
Делая управления коллекторными двигателями (приводы стеклоподъемников) для своеобразной разновидности ЧПУ (polargraph), поленился сделать схему съема тока двигателя.
В результате 3-х контурная схема сократилась на элемент управления током двигателя. Т.е. управляющий выход PID регулятора скорости задает % ШИМ, не ток.
В принципе и такой вариант справляется с теми требованиями, что мне нужны.
Но на малых оборотах (< 2 об/сек) двигателя плавности хода заметно не хватает. Хотя для работы данной железки это не принципиально, но…
Есть ли смысл для коллекторного двигателя (12 обмоток на якоре) вводить PID управления током? Точнее, даст ли это выигрыш в плавности (ускорения) на столь маленьких оборотах в режиме разгона, стопа (т.е. разные моменты на валу) и поддержания скорости?
Кнопку «счастье» я вам не дам…
И я не знаю такого способа.
Лично на своем опыте и на сумме знаний которой обладаю в данной теме могу изложить только следующее:
Снимать и обрабатывать информацию по двум каналам энкодера высокого разрешения нужно всю (по фронтам или спадам) и обрабатывать синхронно. Иначе будет накапливаться ошибка.
Найдете способ и докажете его работу на практике — обязательно поделитесь!
Только pls, не теоретическими рассуждениями, а фактом что это работает в железе.
Критерий я называл… 15-20 минут хаотических перемещений каретки с разной скоростью и короткими остановами — хоть руками(для мазохистов), хоть программно и, что бы по возврату в фактический 0 (метка на столе карандашом) по энкодеру то же был бы 0.
У меня накопленная ошибка при программной реализации колебалась: 0.05-1%. Для меня это было много. При использование аппаратной обработки интерфейсом контроллера — ошибка 0 (ну 0 по и в пределах разрешения энкодера, конечно).
По поводу теорий… попытайтесь их вначале сами хотя бы теоретически проверить. Взять картинки осциллограмм с каналов энкодера и по проигрывать их в голове для очередной программно/аппаратной идеи.
Omron E6B2-CWZ6C крут… меня жаба задавила когда то похожий или такой же на e-bay покупать.
jitte в оптических экодерах возникает при положении вала, когда датчик частично освещен.
Освещенность преобразуется в 1 или 0 по пороговому значениям. И результат может «плясать» между 1 и 0 даже когда вал условно (может и медленно вращаться) неподвижен по причине:
1. питание никогда не бывает стабильным.
2. механические вибрации.
jitter актуален для энкодеров высокого разрешения. Это для крупных полосок/фотодатчиков можно четко задать разнесенные уровни освещенности 0-1.
для мелких рисок все гораздо хуже. И разница между тень/свет не такая выраженная и механические колебания (постучать рядом с энкодером) вполне могут сдвинуть риску на критическу величину.
Отличить по одному каналу jitter от «полезного» сигнала просто невозможно ибо происхождение у них общее и «полезный»(идеальный сферический конь в вакуме) и «вредный»(реальный мир) сигнал это условности.
Т.е. нужно совместно обрабатывать все сигналы (с максимально доступной скоростью) и получать результат по 2-м каналам.
Сложно объяснить на словах… с картинками понятней.
— гляжу в спеку на Omron E6B2-CWZ6C…
— «открытый коллектор» — значит 74hc14 для согласования уровней не нужна.
— задана максимальная длинна фронта/спада на 2м кабеля в 1us. значит сигнал полностью цифровой и захват уровня освещенности датчиков внутрисхемно у энкодера (что не удивительно). 74hc14 не нужна.
omap l138 это для другой области применения чем АРМ контроллеры. Так же как в котроллерах не делают SATA интерфейс, то в таких не делают даже ШИМ генерацию аппаратную. Ибо для разных вещей предназначены.
Если покопаться внимательней, то весь старт Microsoft обеспечен вливаниями IBM.
Ну повезло Билу с мамой… Как минимум на старте.
Ничего не имею против. Жизнь такая.
Идеализировать просто не надо. Ага… нашел он контракт… мальчик с улицы типа.
Типичный вывод капиталов из крупной фирмы (IBM) топами наружу.
Да еще потом за судьбу OS/2 обидно. Убить ее как конкурента Windows было чисто политическое решение IBM. другими словами шкурное решение тогдашних топов публичной компании IBM.
довольно грязные все эти истории если задаться целью узнать что и почему.
хм… а мне показалось, что ответил, говоря о том, что контроллер просто не справится с обработкой по прерыванию всех фронтов.
Мысль о «фильтрации» jitter с помощью тригера шмитта не стал комментировать, что бы не обидеть. Но раз вы настаиваете…
Вы просто не совсем верно понимаете термин jitter ИМЕННО в контексте «энкодер».
Это не какие то «магические» внешние(наводки)/внутренние помехи от которых надо «избавляться» фильрами. Это штатный режим работы отического энкодера.
А по поводу выходного сигнала с модуля энкодера высокого разрешения, то…
Не знаю, какой конкретно у вас энкодер, но, обычно экодеры высокого разрешения типа серий HEDS (например) это не просто фототранзисторы с ножками наружу, а содержат законченную схему со специфицированными выходными характеристиками. Никаких полу 0 полу 1 на ее выходе быть не может. И использование 74hc14 совершенно бессмысленно (именно как ее тригерного входа). Хуже не будет. Просто не смысла.
Ну разве что для сопряжения TTL выхода в каком то экзотичном энкодере с 3.3V входом контроллера. Да и то, обычно выход с таких модулей энкодеров — открытый коллектор.
Опять же… не знаю какой конкретно у вас энкодер, Но про энкодеры такого высокого разрешения, где есть только фототранзистор и всю обвязку нужно делать снаружи — даже не слышал.
А какой АРМ от TI?
Если A8, A9… то это «взрослые» ARM, не для контроллеров.
А если cortex M4, то видимо только начали изучать. Практически все контроллеры M3/M4 имеют встроенную поддержку quadrature encoder.
Сумеете найти ARM (именно контроллер общего назначения, а не DSP или что то еще более специализированное), что не умеет… пусть даже не TI, а другого производителя?
Опять же прошу прощения за некую злобность и сварливость, можно было мне сказать все мягче, но уж стиль такой у меня.
я ради эксперимента на 75МГц STM32F103 попробовал запустить программный алгоритм обработки сигналов с энкодера (1/512) на прерываниях. Контроллер местами оказался занят на 100%… да и не факт что все успевал все обраьлтать. На осциллограмме видел сигналы с расстоянием между фронтами 1us (1Мгц)… Конечно, типично Jitter — это звуковая частота. Но даже 20Кгц каждого фронта — это весьма затратно для обработки на прерываниях.
А STM32… да ничего сложного нет… Хорошая и понятная документация… много библиотек.
Цена? ну платка с STM32F103C8t6 стоит столько же сколько ардуиновская того же размера. А характеристики просто не сопоставимы.
Все же STM сделала мудрый шаг. NXP контроллеры ничуть не хуже, но…
HCTL-2032. Мне проще купить готовый модуль с контроллером, чем искать такую экзотику.
А из Atmel только Tiny и Мегу в мелких корпусах использую, когда что то нужно мелкое. Их еще можно самому впаять.
14.3.16 Encoder interface mode
Figure 93. Example of counter operation in encoder interface mode.
Осциллограммы еще раз возится делать не буду (личного времени жалко). Но ширина и частота импульсов jitter была < 1us. И их количество просто не помещалось в буфер осцилографа (больше 20-30 точно).
Это точно помню.
Можете сами прикинуть возможность обработки каждого импульса по прерыванию и/или опросу и какую "магическую" помеху это вносит в результат.
Интернет просто переполнен (включая англоязычный сегмент) жалобами "ой… я перешел на другой процессор/сменил частоту опроса и у меня вдруг перестал работать энкодер правильно!" или "никак не могу запустить энкодер… показания скачут!".
И советы в ответ: "почисть кАнтакты у тебя навреное экодер испортился… навреное наводка от… НЛО… поставь RC фильтр- мне помогло".
За злобность прощу прощения.
Сочувствую преподам… но у них хоть карательная ручка для зачеток есть.
не люблю показывать незавершенные проекты (жду лета что бы завершить… не дома же краской на обоях рисовать по фото… для отладки размером 2 на 5 метров)
Но вот эта штука в течении часа таскает 2 кг по стене с шагом в 2 мм и возвратом в туже точку 0 с точностью до 1мм.
так что все это я уже проходил…
и энкодер на фото видно и коллекторный двигатель (привод стеклоподъемника)
Потому что это было в данной ветке. Потому что вопрос опять же говорил о том, что по теме особо не читали…
А то что что ответ не понравился и его заминусовали — это ну просто верх корректности.
Желание общаться дальше пропадает.
Скажите, пожалуйста, почему вы начисто игнорируете (я два раза уже про это говорил) наличие третьего канала для борьбы с уплыванием?
Судя по видео, размеру шкива в районе 15..20мм, это дает… ну пусть 50мм линейного перемещения на
оборот. Для балансира отклонение в 50 мм — это уже не балансировка, а ловля падающего "маятника". Безнадежно падающего. Поэтому и игнорировал.
Т.е. рабочий диапазон в пределах одного оборота. Ну зачем здесь компенсация по третьему каналу?
Правильно подключенный энкодер, к "правильному" контроллеру "держит" точную координату в течении пары часов непрерывного перемещения туда сюда с переменной скоростью, включая нулевую местами и вибрациями.
простой тест:
написать простейшую программу, гоняющую туда сюда каретку (конструкция на видео) со случайными остановами и переменной скоростью, как эмуляцию работы балансира.
отметить положение каретки на столе (ну хотя бы карандашом)
погонять минут 20 каретку по столу.
подвести в отмеченный ноль руками (вращая вал)
посмотреть насколько 0 по энкодеру ушел.
Если 0 не ушел, то все в порядке, можно двигаться дальше и писать программу управления двигателями полагаясь на показания энкодера.
А если ушел — то… я бы дальше накладывать неопределенности друг на друга не стал бы.
я же не от балды все это пишу, а потому что все эти этапы уже прошел.
переключите его в режим… ну скажем 1us на деление для начала… (как раз что бы оценить..)
включите его в режим фиксации кадра по фронту/спаду одного из каналов.
щелкните ногтем по энкодеру.
на получившейся картинке (двух каналов) прикиньте количество/временный интервал стробов.
Обработка по прерыванию… ну ну. Это и более "взрослый" контроллер не обработает.
Заодно посмотрите что что ваша программа будет выдавать при таких условиях.
В общем надоело мне на эту тему убеждать почитать… (нормальную серьезную литературу, а не рассуждения чайников на форумах). В основном, правда, все доки на английском..
"Зашумленные данные", "потерянные данные" — какие это знакомые фразы из этих форумов. Ну бред же несут! Особенно про фильтрацию.
Нет никаких "зашумленных" данных! Я поэтому и возмущаюсь, что вы так и не захотели прочитать что означает термин jitter и суть его проявления и повторяете совершенно неграмотные рассуждения.
Ну не принимайте всерьез эти форумы… ну или хотя бы читайте кроме форумов что то! Я даже ключевые слова сказал для поиска.
Джитер — это высокочастотный сигнал с обоих каналов в ситуации, когда "штрих" стоит на грани. Частота джитера такова, что обработка его программными средствами фактически невозможна. Для энкодеров в 1000 штрихов на/оборот это может быть несколько мегагерц.
Считывать состояние каналов по опросу — терять информацию. По прерыванию — просто не успеет.
Аппаратные схемы работы с квадратурным сигналом энкодеров (датчиков холла) в современных контроллерах заключаются в аппаратной обработке сигналов внутренними счетчиками контроллера. А программно читается фактическое значение энкодера. А квадратурная "разность" считается аппаратно. Могу порекомендовать заглянуть в доки на контроллеры, где этот режим поддерживает. Сразу станет понятно в чем суть и как это работает.
Даже зная теорию, и сразу подключив энкодер правильно (STM32) я ради любопытства пробовал и по опросу и по прерыванию (ну раз подключено, что бы не поэкспериментировать).
По прерыванию — сразу увидел, что не успевает. По опросу в бесконечно цикле с выводом результатов через DMA в RS323 (ну что бы вообще все минимизировать) — очень хорошо заметно как ползет случайным образом координата в ± сторону порядка 1-3 отчета в 5 сек.
А если щелкнуть ногтем по конструкции в 10 см от энкодера, то сразу скачек 15-30 отчетов в случайную сторону.
Программный же опрос условно можно считать как НЧ фильтр (хотя если уж игнорировать то схемная RC цепочка была бы лучше)… Задействовав его на медленной ATMega, Вы вполне можете получите иллюзию отсутствия джитера. А на самом деле будете просто терять информацию.
Вам же нужно не скорость мерять для удержания оборотов… (типичная задача регулирования оборотов двигателя для контроллера, реализуемая на ATMega).
Для контроля оборотов (энкодер крутится без остановку) отлично работает и программный опрос ибо эффекта джитера нет (лишь бы опрос был с частотой выше чем частота стробов на каналах).
Вы же собираетесь сделать "балансир"?
А там движения основания в пару мм — норма… Оно конечно будет работать "магически" и так… но именно магически и с дерганьем (полно роликов на youtube с мелко подрагивающими как эпилепсии балансиров). Но Вы же, наверное, хотите добиться какого то более идеального варианта? Если нет, то достаточно было бы энкодера от мышки например…
Просто всегда нужно понимать суть процессов. Тогда никакой "магии" не будет.
С аппаратным квадратурным энкодером, за час работы станка (ЧПУ) я не вижу отклонений от расчетного/фактического (по шагам шагового двигателя) к считанному с энкодера. В режиме с софтверным опросом — разница в метры.
Ставил на ЧПУ станок с шаговиками энкодер исключительно для экспериментов (там он особо не нужен).
Но заодно и проверил теорию.
Совсем не понимаю, почему вы упираете на железную поддержку, железо или софт -принципиальной разницы нету, железо не восстановит магически потерянные данные.
Фраза про "принципиальной разницы нету" и "магически потерянные данные" говорит мне о том, что смотреть что такое quadrature encoder jitter и способы компенсации, Вы просто не стали.
А я разжевывать тему не собираюсь. Хотя еще раз замечу, что задача "балансировки" связана с очень точными и мелкими перемещениями. Не удивляйтесь, потом, автоколебаниям и невозможностью "поймать" баланс.
Фразу про воинствующих невежд, в изначальном комментарии употребил, что бы поиск не ограничился тематическими конференциями по arduino, где очень много совершенно невежественных постов и в основном тусуются школьники и студенты первых курсов.
Типичные алгоритмы и примеры работы с энкодерами на arduino (программный опрос каналов), кочующие по этим форумам применимы для других целей. Да и редко кто там сталкивается с энкодерами высокого разрешения (от $30 за штуку на e-bay).
Особенно умиляют на этих форумах предложения добавить схемный НЧ (R+C) фильтр на каналы, когда народ сталкивается с "магическими ситуациями" при работе с энкодерами и/или использует прерывания по фронту/спаду сигнала с канала.
Но раз не стали смотреть… и абсолютно уверены что Вы ВСЕ знаете, то это Ваше дело и Ваши проблемы.
Ваше и вашего будущего работодателя.
Сколько раз зарекался писать комментарии на статьи вида "а вот что я начал делать!"...
Я использую «бороться» как «уменьшить влияние», а не как «полностью избавиться».
Ну если результирующая ошибка вполне в рамках заданной величины, то почему бы и нет.
Мне нужна была более высокая точность и предсказуемый результат чем дает этот метод. Коллекторный двигатель с типичным количеством щеток/обмоток при малой скорости (мощности/заполнения ШИМ) ведет себя весьма нелинейно. Не уверен, что в заявленной задаче будет достигнут результат. Балансировка — это "мелкое" и точное управление.
А вот тут мне стало очень интересно, так как в моём уже есть борьба с дребезгом, поняли ли вы, как я считываю значение энкодера?
Не важно какой программный способ Вы применяете для фиксировании импульсов с каналов энкодера высокого разрешения на ATMega.
И… джитер энкодера практически НЕ проявляется при его вращении.
Эффект дребезга энкодера с большим разрешением отлично видно на близких к 0 или "практически" 0 скоростях.
Проявляется это так, что вычисленная программными методами координата "плывет" при 0-й скорости.
Теории и практики в Интернете полно (jitter quadrature encoder)… только ищите без слов aduino.
Слова arduino и "воинствующее невежество" для меня, как то ассоциировалось. Не на 100% но с большой вероятностью. Без обид. Я в общем имею в виду… статистически…
Впрочем, не буду Вас ни в чем убеждать и доказывать. Но стоит, наверное, задуматься зачем в контроллерах существует специальная аппаратная поддержка (обычно режим работы счетчиков) работы с энкодерами и сенсорами, где возможен данный эффект дребезга:
Supports incremental (quadrature) encoder and hall-sensor cicuitry for positioning purposes.
Грубо говоря, я хочу написать написать управление для сервомотора: у меня есть текущее положение оси привода и текущая скорость её вращения, я хочу её остановить в заданном положении.
Как мне кажется это задача очень похожа на классическую подзадачу управления сервомоторами для ЧПУ станка.
И она классически решается разбиением на две части:
Расчета траектории с разбиением на дискретные участки (чаще всего..) с постоянной скоростью.
Поддержка постоянной скорости в пределах заданного участка.
Первой задачей занимается ПО управляющее станком (автономные контроллеры или ПО типа: Mach3, Linux CNC, управляющее ПО для 3D принтеров).
В промежуточных расчетах, как результат: скорость на участках траектории. На выходе могут быть как step/dir сигналов для шаговых двигателей, так и управляющие сигналы для контроллеров сервоприводов (управляющее напряжение).
Если используются шаговые двигатели, то обычно выдачей степ сигналов для них все и заканчивается.
Для сервоприводов, контроль за скоростью возлагается на привод (контроллер двигателя).
Сделав, в свое время автономный контроллер ЧПУ на STM32f103, второй частью задачи не заморачивался, поскольку станок собрал на шаговых двигателях.
Но именно сейчас не торопясь занимаюсь похожей задачей только для коллекторных двигателей. Первое что пришло в голову "ну интересно же попробовать сделать не типично, не так как классически все делают".
Решил сделать "попроще"… и начал именно так, как описано в статье (включая съем графиков и пр. анализ)
Таким образом, реальное положение каретки слегка отличается от теоретического, я полагаю, что это из-за неучтённого трения: чем ближе к нулю, тем меньше подаваемое напряжение, и однажды оно уже не может бороться с трением. Борьба с этим феноменом будет темой одной из следующих статей. Stay tuned!
Ну… ну…
Не получится. Я на это потратил довольно много времени. Используя исключительно предложенный в статье метод, добиться точного позиционирования невозможно в принципе.
Но если хотите наступать на те же грабли, то будет повод написать еще несколько статей.
Вернулся к классике (дискретный расчет участков скорости и поддержка скорости на участке разновидностью PID) — и все работает плавно и в пределах заказанных ускорений.
В распоряжении имеется оптический энкодер (1000 пульсов на оборот), электродвигатель (750 rpm при 12В без нагрузки), драйвер L6201 и atmega 328 (arduino nano).
Оптически энкодер 1000/оборот и ATMega не имеющая аппаратной схемы работы с энкодером (как у серий STM32, например) — это тупик. "Дребезг" энкодера программными методами не давится.
Даже с использованием 72-х МГц проца софтверная обработка (на прерываниях) не справляется (проверял ради эксперимента для энкодера 512/оборот), не говоря уж о древней atmega.
Может можете сказать что ни будь про судьбу линейки HSM плат с SDK FM модуля?
Я имею в виду линейку Eracom (в девичестве) плат PSO->PSG->PSI-E->…
Мало того что последняя смена платформы (другая архитектра проца) напрягает, так и очень беспокоит судьба этой линейки.
После того как Axalta (Schlumberger) проглотила Gemplus с инженерной инновационностью в Gemalto стало так же как в Axalto… Т.е. никак. А вот с бизнес решениями (что бы еще с содрать с клиентов, не делая ничего) все хорошо.
И риск того, что «успешный менеджер» в GemAlto решит закрыть выпуск этой линейки HSM (что бы платили за кастомизацию прошивок в GemAlto, а не делали сами) весьма велик.
Я делал аналогично без контура по току. Переделывать уже существующую конструкцию наверное уже не буду.
Но на будущее очень было бы интересно знать насколько это на практике дает преимущество.
Все же добавление «лишних» деталей — это добавление лишних деталей. Да еще аналоговой части схемы…
Вдруг кто ни будь займется и выложит результаты с сравнением по факту для конкретного двигателя/режима.
Единственный выход, как мне видится — энкодер более высокого разрешения. Хотя была надежда на «магические» варианты, которые я просто упускаю из виду.
Но что было под рукой (512/оборот) то и поставил. А он дает 0.5 мм линейного перемещения на отсчет и этого очень мало для четкой фиксации скорости на участке скажем в 500ms. Всего 2 отсчета на 1 мм/сек. Никакая регулировка не справится.
Собственно, расчет траектории по G-коду один из стандартных и самых простых. Разбиение каждой команды G0/G1 на участки (для данного варианта шаг 400ms) с постоянной скоростью и координатами начала/конца с предпросмотром на следующую команду G кода (нужно ли торможение и пр. исходя из ограничения по максимальному ускорению).
Для шаговых двигателей этим все и заканчивается. На входе модуля управления шаговиками: количество шагов(перемещение)+частота шагов(скорость).
Для конструкции на коллекторном моторе использую контур PID контроля скорости и положения. На входе те же самые данные модуля расчета траектории: перемещение (только в абсолютных координатах) + скорость.
Задача «переместится» в заданное значение энкодера, поддерживая как можно точнее заданную скорость.
Все нормально работает для относительно высоких скоростей (отклонение в пределах 1% от заданной скорости).
И Вы правы. Проблема, что при фактическом (с учетом редуктора) разрешении энкодера 14-16 отчетов на оборот двигателя, явно не возможно обеспечить заданную скорость с требуемой точностью для всех диапазонов перемещений и скоростей. (энкодер не на валу двигателя, а на измерительном ролике).
На практике это выглядит, как волнистая линия (2..5 мм отклонения от требуемой) на стене вместо прямой прочерченная фломастером (фломастер на каретке).
Впрочем, я изначально планировал рисование по растру с фиксацией одного из моторов. Просто захотелось попробовать еще и по G-коду перемещения сделать. Похоже все одно не выйдет для данной конструкции.
Спасибо, что уделили внимание. То что Вы рассказываете в любом случае очень интересно. Чужой опыт то же бесценен.
Разрешение энкодера в 512/оборот для выбранного диаметра измерительного ролика дает около 0.5 мм/на отсчет энкодера для линейное перемещение троса…
в результате 12-16 отсчетов энкодера на оборот вала двигателя. ШИМ аппаратный 20Кгц. частота расчета скорости — раз в 100ms (чаще нет смысла).
Обработка каналов энкодера — аппаратный режим/счетчики STM32F103. Производительности для обслуживания 2-х двигателей (все на прерываниях по таймерам) для таких времен хватает с избытком. Еще и на вывод графики на экран и расчет траектории остается.
Но, наверное, я слишком много хочу и стабильной скорости подачи троса для 1-3 мм/сек в при таких условиях (разрещения энкодера) добиться в принципе нельзя.
Хотя уже 5mm/сек и выше вполне стабильно (по данным координата/скорость в реальном времени от контроллера).
Но раз говорите что для коллекторного двигателя может улучшить результат управление током… попробую добавить.
Жаль в шлейфе запасных линий не предусмотрел.
Кстати, а как грамотно снять бы? Операционником падение напряжение на токовом шунте, а потом ADC усреднить за период PID? (1Мгц частота ADC у STM32F3) А с какой частотой PID по току лучше делать, при ШИМ 20Кгц?
Подскажите пожалуйста, никогда этой темой не занимался.
Не могли бы Вы, опираясь на свой опыт, подсказать мне…
Делая управления коллекторными двигателями (приводы стеклоподъемников) для своеобразной разновидности ЧПУ (polargraph), поленился сделать схему съема тока двигателя.
В результате 3-х контурная схема сократилась на элемент управления током двигателя. Т.е. управляющий выход PID регулятора скорости задает % ШИМ, не ток.
В принципе и такой вариант справляется с теми требованиями, что мне нужны.
Но на малых оборотах (< 2 об/сек) двигателя плавности хода заметно не хватает. Хотя для работы данной железки это не принципиально, но…
Есть ли смысл для коллекторного двигателя (12 обмоток на якоре) вводить PID управления током? Точнее, даст ли это выигрыш в плавности (ускорения) на столь маленьких оборотах в режиме разгона, стопа (т.е. разные моменты на валу) и поддержания скорости?
И я не знаю такого способа.
Лично на своем опыте и на сумме знаний которой обладаю в данной теме могу изложить только следующее:
Снимать и обрабатывать информацию по двум каналам энкодера высокого разрешения нужно всю (по фронтам или спадам) и обрабатывать синхронно. Иначе будет накапливаться ошибка.
Найдете способ и докажете его работу на практике — обязательно поделитесь!
Только pls, не теоретическими рассуждениями, а фактом что это работает в железе.
Критерий я называл… 15-20 минут хаотических перемещений каретки с разной скоростью и короткими остановами — хоть руками(для мазохистов), хоть программно и, что бы по возврату в фактический 0 (метка на столе карандашом) по энкодеру то же был бы 0.
У меня накопленная ошибка при программной реализации колебалась: 0.05-1%. Для меня это было много. При использование аппаратной обработки интерфейсом контроллера — ошибка 0 (ну 0 по и в пределах разрешения энкодера, конечно).
По поводу теорий… попытайтесь их вначале сами хотя бы теоретически проверить. Взять картинки осциллограмм с каналов энкодера и по проигрывать их в голове для очередной программно/аппаратной идеи.
Omron E6B2-CWZ6C крут… меня жаба задавила когда то похожий или такой же на e-bay покупать.
Освещенность преобразуется в 1 или 0 по пороговому значениям. И результат может «плясать» между 1 и 0 даже когда вал условно (может и медленно вращаться) неподвижен по причине:
1. питание никогда не бывает стабильным.
2. механические вибрации.
jitter актуален для энкодеров высокого разрешения. Это для крупных полосок/фотодатчиков можно четко задать разнесенные уровни освещенности 0-1.
для мелких рисок все гораздо хуже. И разница между тень/свет не такая выраженная и механические колебания (постучать рядом с энкодером) вполне могут сдвинуть риску на критическу величину.
Отличить по одному каналу jitter от «полезного» сигнала просто невозможно ибо происхождение у них общее и «полезный»(идеальный сферический конь в вакуме) и «вредный»(реальный мир) сигнал это условности.
Т.е. нужно совместно обрабатывать все сигналы (с максимально доступной скоростью) и получать результат по 2-м каналам.
Сложно объяснить на словах… с картинками понятней.
— гляжу в спеку на Omron E6B2-CWZ6C…
— «открытый коллектор» — значит 74hc14 для согласования уровней не нужна.
— задана максимальная длинна фронта/спада на 2м кабеля в 1us. значит сигнал полностью цифровой и захват уровня освещенности датчиков внутрисхемно у энкодера (что не удивительно). 74hc14 не нужна.
omap l138 это для другой области применения чем АРМ контроллеры. Так же как в котроллерах не делают SATA интерфейс, то в таких не делают даже ШИМ генерацию аппаратную. Ибо для разных вещей предназначены.
Ну повезло Билу с мамой… Как минимум на старте.
Ничего не имею против. Жизнь такая.
Идеализировать просто не надо. Ага… нашел он контракт… мальчик с улицы типа.
Типичный вывод капиталов из крупной фирмы (IBM) топами наружу.
Да еще потом за судьбу OS/2 обидно. Убить ее как конкурента Windows было чисто политическое решение IBM. другими словами шкурное решение тогдашних топов публичной компании IBM.
довольно грязные все эти истории если задаться целью узнать что и почему.
Мысль о «фильтрации» jitter с помощью тригера шмитта не стал комментировать, что бы не обидеть. Но раз вы настаиваете…
Вы просто не совсем верно понимаете термин jitter ИМЕННО в контексте «энкодер».
Это не какие то «магические» внешние(наводки)/внутренние помехи от которых надо «избавляться» фильрами. Это штатный режим работы отического энкодера.
А по поводу выходного сигнала с модуля энкодера высокого разрешения, то…
Не знаю, какой конкретно у вас энкодер, но, обычно экодеры высокого разрешения типа серий HEDS (например) это не просто фототранзисторы с ножками наружу, а содержат законченную схему со специфицированными выходными характеристиками. Никаких полу 0 полу 1 на ее выходе быть не может. И использование 74hc14 совершенно бессмысленно (именно как ее тригерного входа). Хуже не будет. Просто не смысла.
Ну разве что для сопряжения TTL выхода в каком то экзотичном энкодере с 3.3V входом контроллера. Да и то, обычно выход с таких модулей энкодеров — открытый коллектор.
Опять же… не знаю какой конкретно у вас энкодер, Но про энкодеры такого высокого разрешения, где есть только фототранзистор и всю обвязку нужно делать снаружи — даже не слышал.
А какой АРМ от TI?
Если A8, A9… то это «взрослые» ARM, не для контроллеров.
А если cortex M4, то видимо только начали изучать. Практически все контроллеры M3/M4 имеют встроенную поддержку quadrature encoder.
Сумеете найти ARM (именно контроллер общего назначения, а не DSP или что то еще более специализированное), что не умеет… пусть даже не TI, а другого производителя?
Опять же прошу прощения за некую злобность и сварливость, можно было мне сказать все мягче, но уж стиль такой у меня.
А STM32… да ничего сложного нет… Хорошая и понятная документация… много библиотек.
Цена? ну платка с STM32F103C8t6 стоит столько же сколько ардуиновская того же размера. А характеристики просто не сопоставимы.
Все же STM сделала мудрый шаг. NXP контроллеры ничуть не хуже, но…
HCTL-2032. Мне проще купить готовый модуль с контроллером, чем искать такую экзотику.
А из Atmel только Tiny и Мегу в мелких корпусах использую, когда что то нужно мелкое. Их еще можно самому впаять.
14.3.16 Encoder interface mode
Figure 93. Example of counter operation in encoder interface mode.
Осциллограммы еще раз возится делать не буду (личного времени жалко). Но ширина и частота импульсов jitter была < 1us. И их количество просто не помещалось в буфер осцилографа (больше 20-30 точно).
Это точно помню.
Можете сами прикинуть возможность обработки каждого импульса по прерыванию и/или опросу и какую "магическую" помеху это вносит в результат.
Интернет просто переполнен (включая англоязычный сегмент) жалобами "ой… я перешел на другой процессор/сменил частоту опроса и у меня вдруг перестал работать энкодер правильно!" или "никак не могу запустить энкодер… показания скачут!".
И советы в ответ: "почисть кАнтакты у тебя навреное экодер испортился… навреное наводка от… НЛО… поставь RC фильтр- мне помогло".
За злобность прощу прощения.
Сочувствую преподам… но у них хоть карательная ручка для зачеток есть.
не люблю показывать незавершенные проекты (жду лета что бы завершить… не дома же краской на обоях рисовать по фото… для отладки размером 2 на 5 метров)
Но вот эта штука в течении часа таскает 2 кг по стене с шагом в 2 мм и возвратом в туже точку 0 с точностью до 1мм.
так что все это я уже проходил…
и энкодер на фото видно и коллекторный двигатель (привод стеклоподъемника)
Потому что это было в данной ветке. Потому что вопрос опять же говорил о том, что по теме особо не читали…
А то что что ответ не понравился и его заминусовали — это ну просто верх корректности.
Желание общаться дальше пропадает.
Судя по видео, размеру шкива в районе 15..20мм, это дает… ну пусть 50мм линейного перемещения на
оборот. Для балансира отклонение в 50 мм — это уже не балансировка, а ловля падающего "маятника". Безнадежно падающего. Поэтому и игнорировал.
Т.е. рабочий диапазон в пределах одного оборота. Ну зачем здесь компенсация по третьему каналу?
Правильно подключенный энкодер, к "правильному" контроллеру "держит" точную координату в течении пары часов непрерывного перемещения туда сюда с переменной скоростью, включая нулевую местами и вибрациями.
простой тест:
Если 0 не ушел, то все в порядке, можно двигаться дальше и писать программу управления двигателями полагаясь на показания энкодера.
А если ушел — то… я бы дальше накладывать неопределенности друг на друга не стал бы.
я же не от балды все это пишу, а потому что все эти этапы уже прошел.
Вы опять не удосужились ничего прочитать и развиваете теории только на основе своих собственных рассуждений.
Если Вам так уж хочется узнавать все на своем личном опыте:
Обработка по прерыванию… ну ну. Это и более "взрослый" контроллер не обработает.
Заодно посмотрите что что ваша программа будет выдавать при таких условиях.
В общем надоело мне на эту тему убеждать почитать… (нормальную серьезную литературу, а не рассуждения чайников на форумах). В основном, правда, все доки на английском..
Нет никаких "зашумленных" данных! Я поэтому и возмущаюсь, что вы так и не захотели прочитать что означает термин jitter и суть его проявления и повторяете совершенно неграмотные рассуждения.
Ну не принимайте всерьез эти форумы… ну или хотя бы читайте кроме форумов что то! Я даже ключевые слова сказал для поиска.
Джитер — это высокочастотный сигнал с обоих каналов в ситуации, когда "штрих" стоит на грани. Частота джитера такова, что обработка его программными средствами фактически невозможна. Для энкодеров в 1000 штрихов на/оборот это может быть несколько мегагерц.
Считывать состояние каналов по опросу — терять информацию. По прерыванию — просто не успеет.
Аппаратные схемы работы с квадратурным сигналом энкодеров (датчиков холла) в современных контроллерах заключаются в аппаратной обработке сигналов внутренними счетчиками контроллера. А программно читается фактическое значение энкодера. А квадратурная "разность" считается аппаратно. Могу порекомендовать заглянуть в доки на контроллеры, где этот режим поддерживает. Сразу станет понятно в чем суть и как это работает.
Даже зная теорию, и сразу подключив энкодер правильно (STM32) я ради любопытства пробовал и по опросу и по прерыванию (ну раз подключено, что бы не поэкспериментировать).
По прерыванию — сразу увидел, что не успевает. По опросу в бесконечно цикле с выводом результатов через DMA в RS323 (ну что бы вообще все минимизировать) — очень хорошо заметно как ползет случайным образом координата в ± сторону порядка 1-3 отчета в 5 сек.
А если щелкнуть ногтем по конструкции в 10 см от энкодера, то сразу скачек 15-30 отчетов в случайную сторону.
Программный же опрос условно можно считать как НЧ фильтр (хотя если уж игнорировать то схемная RC цепочка была бы лучше)… Задействовав его на медленной ATMega, Вы вполне можете получите иллюзию отсутствия джитера. А на самом деле будете просто терять информацию.
Вам же нужно не скорость мерять для удержания оборотов… (типичная задача регулирования оборотов двигателя для контроллера, реализуемая на ATMega).
Для контроля оборотов (энкодер крутится без остановку) отлично работает и программный опрос ибо эффекта джитера нет (лишь бы опрос был с частотой выше чем частота стробов на каналах).
Вы же собираетесь сделать "балансир"?
А там движения основания в пару мм — норма… Оно конечно будет работать "магически" и так… но именно магически и с дерганьем (полно роликов на youtube с мелко подрагивающими как эпилепсии балансиров). Но Вы же, наверное, хотите добиться какого то более идеального варианта? Если нет, то достаточно было бы энкодера от мышки например…
Просто всегда нужно понимать суть процессов. Тогда никакой "магии" не будет.
С аппаратным квадратурным энкодером, за час работы станка (ЧПУ) я не вижу отклонений от расчетного/фактического (по шагам шагового двигателя) к считанному с энкодера. В режиме с софтверным опросом — разница в метры.
Ставил на ЧПУ станок с шаговиками энкодер исключительно для экспериментов (там он особо не нужен).
Но заодно и проверил теорию.
Фраза про "принципиальной разницы нету" и "магически потерянные данные" говорит мне о том, что смотреть что такое quadrature encoder jitter и способы компенсации, Вы просто не стали.
А я разжевывать тему не собираюсь. Хотя еще раз замечу, что задача "балансировки" связана с очень точными и мелкими перемещениями. Не удивляйтесь, потом, автоколебаниям и невозможностью "поймать" баланс.
Фразу про воинствующих невежд, в изначальном комментарии употребил, что бы поиск не ограничился тематическими конференциями по arduino, где очень много совершенно невежественных постов и в основном тусуются школьники и студенты первых курсов.
Типичные алгоритмы и примеры работы с энкодерами на arduino (программный опрос каналов), кочующие по этим форумам применимы для других целей. Да и редко кто там сталкивается с энкодерами высокого разрешения (от $30 за штуку на e-bay).
Особенно умиляют на этих форумах предложения добавить схемный НЧ (R+C) фильтр на каналы, когда народ сталкивается с "магическими ситуациями" при работе с энкодерами и/или использует прерывания по фронту/спаду сигнала с канала.
Но раз не стали смотреть… и абсолютно уверены что Вы ВСЕ знаете, то это Ваше дело и Ваши проблемы.
Ваше и вашего будущего работодателя.
Сколько раз зарекался писать комментарии на статьи вида "а вот что я начал делать!"...
Ну если результирующая ошибка вполне в рамках заданной величины, то почему бы и нет.
Мне нужна была более высокая точность и предсказуемый результат чем дает этот метод. Коллекторный двигатель с типичным количеством щеток/обмоток при малой скорости (мощности/заполнения ШИМ) ведет себя весьма нелинейно. Не уверен, что в заявленной задаче будет достигнут результат. Балансировка — это "мелкое" и точное управление.
Не важно какой программный способ Вы применяете для фиксировании импульсов с каналов энкодера высокого разрешения на ATMega.
И… джитер энкодера практически НЕ проявляется при его вращении.
Эффект дребезга энкодера с большим разрешением отлично видно на близких к 0 или "практически" 0 скоростях.
Проявляется это так, что вычисленная программными методами координата "плывет" при 0-й скорости.
Теории и практики в Интернете полно (jitter quadrature encoder)… только ищите без слов aduino.
Слова arduino и "воинствующее невежество" для меня, как то ассоциировалось. Не на 100% но с большой вероятностью. Без обид. Я в общем имею в виду… статистически…
Впрочем, не буду Вас ни в чем убеждать и доказывать. Но стоит, наверное, задуматься зачем в контроллерах существует специальная аппаратная поддержка (обычно режим работы счетчиков) работы с энкодерами и сенсорами, где возможен данный эффект дребезга:
Supports incremental (quadrature) encoder and hall-sensor cicuitry for positioning purposes.
Как мне кажется это задача очень похожа на классическую подзадачу управления сервомоторами для ЧПУ станка.
И она классически решается разбиением на две части:
Первой задачей занимается ПО управляющее станком (автономные контроллеры или ПО типа: Mach3, Linux CNC, управляющее ПО для 3D принтеров).
В промежуточных расчетах, как результат: скорость на участках траектории. На выходе могут быть как step/dir сигналов для шаговых двигателей, так и управляющие сигналы для контроллеров сервоприводов (управляющее напряжение).
Если используются шаговые двигатели, то обычно выдачей степ сигналов для них все и заканчивается.
Для сервоприводов, контроль за скоростью возлагается на привод (контроллер двигателя).
Сделав, в свое время автономный контроллер ЧПУ на STM32f103, второй частью задачи не заморачивался, поскольку станок собрал на шаговых двигателях.
Но именно сейчас не торопясь занимаюсь похожей задачей только для коллекторных двигателей. Первое что пришло в голову "ну интересно же попробовать сделать не типично, не так как классически все делают".
Решил сделать "попроще"… и начал именно так, как описано в статье (включая съем графиков и пр. анализ)
Ну… ну…
Не получится. Я на это потратил довольно много времени. Используя исключительно предложенный в статье метод, добиться точного позиционирования невозможно в принципе.
Но если хотите наступать на те же грабли, то будет повод написать еще несколько статей.
Вернулся к классике (дискретный расчет участков скорости и поддержка скорости на участке разновидностью PID) — и все работает плавно и в пределах заказанных ускорений.
Оптически энкодер 1000/оборот и ATMega не имеющая аппаратной схемы работы с энкодером (как у серий STM32, например) — это тупик.
"Дребезг" энкодера программными методами не давится.
Даже с использованием 72-х МГц проца софтверная обработка (на прерываниях) не справляется (проверял ради эксперимента для энкодера 512/оборот), не говоря уж о древней atmega.