Умножитель частоты шагов на STM32

[MX_Master]

Продолжаю тесты с аппаратным выводом шагов на больших частотах. С помощью не очевидных ухищрений с DMA, удалось получить точный вывод нужного кол-ва шагов на частоте 3.2 МГц (ядро пашет на 72 МГц). Вся сложность в том, чтобы вовремя остановить генерацию. На частотах выше 3.2 МГц аппаратная часть всё-таки успевает сгенерировать лишнего. Например, вместо 10 шагов на выходе будет 11. И это, несмотря на то, что генератор останавливается аппаратно (DMA). Если останавливать программно, то уже после 500 КГц могут проскакивать лишние шаги.

2017-07-30_114522.png (8.33 КБ) 4630 просмотров

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

[wldev]

Предлагаю поменять стратегию умножения)
1.Нужно ввести понятие типа "накопление данных" допустим 1мс (сервоцикл и прочее).
2.Далее нужно считать сколько импульсов попало в этот промежуток.
3.Выдавать эти импульсы в след участок времени (условно +1мс). и параллельно считать новые импульсы.

[MX_Master]

Предлагаю поменять стратегию умножения)
1.Нужно ввести понятие типа "накопление данных" допустим 1мс (сервоцикл и прочее).
2.Далее нужно считать сколько импульсов попало в этот промежуток.
3.Выдавать эти импульсы в след участок времени (условно +1мс). и параллельно считать новые импульсы.

Я не против, в одном из начальных вариантов такое даже было. Есть пара нюансов, которые делают этот способ не таким простым. Во-первых, обработка и вывод сигнала DIR. Во-вторых, обработка шагов, между которыми период больше, чем 1 мс. В-третьих, 1 мс это довольно большой линейный кусок, который сделает вывод ускорений на больших частотах не таким плавным. К примеру, 100 мкс вместо 1 мс дадут более плавный вывод.

Да и чтобы сделать вывод действительно плавным, нужно "копить данные" больше чем 1 мс. Например, наблюдать за входом 40-50 мс, периодически (раз в 100мкс) складывая в буфер частоту входных шагов. После наблюдения надо подравнять собранные частоты относительно друг друга, чтобы не было резких скачков. А затем можно подавать собранные шаги на выход, меняя частоту вывода раз в 100мкс. Но обработка сигнала DIR тут тоже подпортит картину.

[wldev]

Во-первых, обработка и вывод сигнала DIR. Во-вторых, обработка шагов, между которыми период больше, чем 1 мс. В-третьих, 1 мс это довольно большой линейный кусок, который сделает вывод ускорений на больших частотах не таким плавным. К примеру, 100 мкс вместо 1 мс дадут более плавный вывод.

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

[wldev]

Меня посетила ещё одна мысль.... что если ...
ШД при малых перемещениях лучше работают с делением шага, а при больших на целом шаге. Что если в определённый момент включать умножитель шагов и делитель на контроллере. Тогда у нас сохраниться высокий момент на большой скорости и не будет жужжания на низких. Так сказать "Адаптивное деление шага".

[Сергей Саныч]

Меня посетила ещё одна мысль.... что если ...
ШД при малых перемещениях лучше работают с делением шага, а при больших на целом шаге. Что если в определённый момент включать умножитель шагов и делитель на контроллере. Тогда у нас сохраниться высокий момент на большой скорости и не будет жужжания на низких. Так сказать "Адаптивное деление шага".

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

[MX_Master]

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

А ты представь, что шаги на входе идут с периодом 50 мс. В реальности бывает и медленней. Как будет выглядеть умноженный вывод, если сервоцикл всего 1мс? Это ж будут отдельные кучки умноженных шагов, разнесённые друг от друга на 48-49 мс.

Как только ты начнёшь проверять на новой идее все возможные случаи входных периодов, то сразу станет ясно, что реализация будет не из лёгких. Если не задумываться о мелочах, то можно и синхронизацию выходных шагов на основе входных придумать. И всякие фильтры, и замену кривых разгона/торможения, и много чего интересного.

Так сказать "Адаптивное деление шага".

Этим должен заниматься отдельный цифровой драйвер ШД. Также он должен бороться с резонансом и прочими нюансами управления ЩД. А контроллер с умножителем должны чётко и в срок выполнять свою задачу.

[wldev]

Это ж будут отдельные кучки умноженных шагов, разнесённые друг от друга на 48-49 мс.

Да кучки, но! на минимальной частоте...
Всё равно нужен предел минимальной частоты который будет определяться сервоциклом.
А если 1имп/час то что тогда? в любом случаем от кучек не деться...

[MX_Master]

Это ж будут отдельные кучки умноженных шагов, разнесённые друг от друга на 48-49 мс.

Да кучки, но! на минимальной частоте...
Всё равно нужен предел минимальной частоты который будет определяться сервоциклом.
А если 1имп/час то что тогда? в любом случаем от кучек не деться...

умножитель, который будет выдавать такой рваный STEP сигнал, к сожалению, никому не пригодится

[wldev]

умножитель, который будет выдавать такой рваный STEP сигнал, к сожалению, никому не пригодится

Если не будет минимальной частоты шага, то у тебя при шаге 1 имп/час (x4) будет сформировано 4 импульса с периодом 15 мин?

[wldev]

Так вот тоже у тебя будет рваный шаг:

Умножение происходит между двумя шагами. Но у меня есть максимальное время ожидания второго шага, на тот случай, если был только 1 шаг.

[MX_Master]

Максимальное время ожидания второго шага = 65 мс в текущей версии в связи с текущим способом аппаратного вывода. И это плохо. Но 65 мс это, всё-таки, не 1 мс. В новом способе вывода (в процессе) можно выдавать шаги с частотой 1 Гц и ниже. Т.е. период может быть 1000мс и выше.

Я ж не против. Попробуй сделать так как советуешь, с сервоциклом в 1 мс. И stm'ка у тебя есть для тестов. Осциллограмму с анализатора обязательно выложи. Если люди посмотрят и решат, что так будет приемлемо, то твой способ имеет место быть. Я всеми руками и ногами за новые способы.

[wldev]

понятно, везде есть + и -.

интересно а, у stepmastera куда (на какой вход) приходят сигналы step и dir?

[wldev]

Я ж не против. Попробуй сделать так как советуешь, с сервоциклом в 1 мс. И stm'ка у тебя есть для тестов. Осциллограмму с анализатора обязательно выложи. Если люди посмотрят и решат, что так будет приемлемо, то твой способ имеет место быть. Я всеми руками и ногами за новые способы.

пока ещё точно не знаю как лучше)))

[Сергей Саныч]

Михаил, когда разрабатывал Степмастер, первоначально делал только фильтр, без умножения частоты. Идея ввести умножение появилась позже. Может и здесь есть смысл начать с фильтрации? То есть проектировать не абстрактный алгоритм умножения частоты, а учесть, что это частота будет управлять механическим, достаточно инерционным устройством, которое не может мгновенно изменить скорость.

[MX_Master]

Михаил, когда разрабатывал Степмастер, первоначально делал только фильтр, без умножения частоты. Идея ввести умножение появилась позже. Может и здесь есть смысл начать с фильтрации? То есть проектировать не абстрактный алгоритм умножения частоты, а учесть, что это частота будет управлять механическим, достаточно инерционным устройством, которое не может мгновенно изменить скорость.

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

[wldev]

пока ещё точно не знаю как лучше)))

Вроде кое что придумал...

1. Все входные сигналы нужно загонять в таймера чтобы они считались аппаратно (как энкодерный вход AB (нужно поставить доп. логику)) и ничего не пропадало.
мы сразу учитываем направление.
2. Далее обрабатываем значение счётчика (я так сделал у себя в WLMotion / энкодерный вход) ч/з определённый промежуток времени.Для вычисления его
приращения.
Счётчик никогда не сбрасываем, чтобы непропадали шаги!!! (определяем наименьший путь приращения и берём его за истинный, надеюсь поняли)))
3. Вычислив преращения счётчика энкодера умножаем его (сдвигом). и пребавляем в наш счётчик рассогласования.
4. Обрабатываем наше рассогласование....

дальше пока непридумал)))

[MX_Master]

А шо такое "рассогласование"?

[wldev]

А шо такое "рассогласование"?

Ах да....
Это накопительный счётчик с которого мы будем списывать импульсы в процессе генерации.

[MX_Master]

А шо такое "рассогласование"?

Ах да....
Это накопительный счётчик с которого мы будем списывать импульсы в процессе генерации.

Осталось дело за малым - сделать тестовый образец прошивки