Синхронизация асинхронного двигателя и шагового

Всем привет!
Заранее предполагаю, что мой вопрос останется без ответа, но все же счастья попытаю!)
Есть некое устройство, которое состоит из асинхронного двигателя, управляемого частотным преобразователем, шкива на котором две метки, датчика индуктивности (который эти метки "видит") и шагового двигателя.
Задача состоит в том, что бы синхронизировать движение шагового двигателя относительно асинхронного.
Шаговик должен шагать очень маленькими шагами. Т.е. к примеру при частоте вращения шкива 646 об/мин я передаю на шаговый двигатель частоту 81 гц. Но беда в том, что шаговому двигателю нельзя передать дробную частоту и выходит, что при частоте вращения шкива 650 об/мин я тоже передаю на шаговый двигатель 81 гц, что меня не устраивает.
Отсюда вопрос - как сделать так, что бы вся эта система функционировала как надо?)
К сожалению, асинхронник невозможно заставить вращаться четко с одной скоростью. Его скорость все время колеблется в пределах +/- 10 об/мин и желаемый результат достичь не удается.
Есть у кого-нибудь идеи?
Буду рад любым предположениям и высказываниям по теме.
Заранее спасибо.

 

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

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

 

Вот пример реализации в псевдокоде:

Код (C++):

float difference = 0.0; // накопленная разность
float divider = 123.0; // делитель зависимости частоты шагового от оборотов асинхронника

unsigned int compute(unsigned int rpm) // вычисляем параметры для шагового
{
  float approximate = rpm/divider + difference; // вычисляем приближённое значение с учётом предыдущей погрешности
  unsigned int intApprox = ceil(approximate); // округляем до целого
  difference = approximate - intApprox; // накапливаем погрешность измерений

return intApprox;
}

 

DIYMan, спасибо за совет! О накоплении ошибки я не подумал!
Контроллер шагового двигателя и так работает в режиме 1/32 - я ж говорю, нужны оооочень маленькие шажочки.
Что бы было понятно о чем речь - я навиваю проволоку 0,1 мм на проволоку 0,2 мм и шаговый двигатель отвечает за передвижение "основы", что бы "намотка" ложилась ровно виток к витку. Эта вот неравномерность, описанная в первом посте, приводит к тому, что время от времени намотка либо спешит, либо отстает.. Надеюсь понятно объяснил!)
В любом случае, спасибо за Ваш совет - буду думать в этом направлении!

 

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

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

 

И да, аппаратное решение для увеличения хода шагового - тоже очевидно: редуктор. Чтобы ему не приходилось шагать совсем уж маленькими шажками

 

Ха!)
Видимо летний тупняк на меня напал - это действительно прекрасное решение! Особенно с учетом того, что вся конструкция напечатана на 3д принтере и переделать аппаратную часть не представляется сложным.
Думаю, что Ваш первый совет + второй в конце концов дадут мне приемлимый результат!
К сожалению, в последнее время не так много времени заниматься проектом, но как только реализую, обязательно отчитаюсь!)
Спасибо еще раз!

 

простите за назойливость, а это не похоже на укладку на бобину кабеля или ещё чего? Когда бобина от частотника с разной скоростью - к примеру от натяжки, подачи или ещё чего, а требуется укладывать плотно (допустим виток к витку).
Простите не прочитал весь пост - теперь понял!
Аналогичная проблема но не такая тонкая штука (порядка 70мм в диаметре) и тоже концевые индуктивные датчики. Хочу на RPI + OpenCV датчик (камеру) соорудить (смотреть на наклон в право или влево) с сигналом для перемещения. правда в моём случае вместо шагового тоже асинхронник с редуктором + частотник. У меня по мере намотки и скорость вращения бобины меняется (угловое перемещение уменьшается).

 

По сути похоже, только у меня бобина бесконечная и движется) А у Вас укладчик или каретка перемещается туда-сюда. А зачем камера? Почему не использовать просто переменное сопротивление? По сути у Вас задача типа "обратный маятник")

 

Скорость барабана зависит и от того сколько уложили и от того ссколько подают. на скорость барабана и так переменное сопротвление - зависит от натяжки, а значит и от скорости подачи того, что надо укладывать. а в OpenCV проде добился срабатывания - перемещения туда-сюда. правда физически ещё не реализовал.

 

Сел сегодня попробовать этот код!)
Эмулировал rpm в пределах 645...655 и выходила полная фигня по началу!
Скопировал значения, которые получались в эксель, построил график и понял, что ceil() тут просто не подходит! Заменил на round() и получил ожидаемый график! Так что спасибо еще раз!

 

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