Шаговый генератор на STM32 (STEP/DIR/ENBL)

[tims]

Это накладывает дополнительное ограничение, все оси и сигналы должны быть заведены на этот "генератор"

[MX_Master]

А оси ты как синхронизировать собираешься?

Хотя это и не ко мне вопрос, но очередь присланных команд - общая. Каждый элемент очереди содержит задание для всех координат. Наглядной аналогией являются кадры G кода - G0/G1. Они тоже содержат задания для всех координат.

[Argon-11]

Это накладывает дополнительное ограничение, все оси и сигналы должны быть заведены на этот "генератор"

Ну да, STM32 вполне справится с несколькими осями. Но вообще при чем тут оси? Шаговый двигатель и генератор могут использоваться вообще не в чпу станках, а там где никаких координатных осей нет, синхронизация не требуется и иногда даже кривые разгона не имеют особого значения. Примеров можно набрать сотни. Автор темы разве говорил, что собирается ЧПУ станок делать на основе этого генератора?

[MX_Master]

Подправил первый пост в соответствии с текущими планами
К проекту вернусь сразу после того, как заточу среду разработки под Armbian на Orange Pi One

[Serg]

Генератор ващето можно считать реалтаймным девайсом, он и будет синхронизировать оси.

Как именно? Например при движении по окружности.

Хотя это и не ко мне вопрос, но очередь присланных команд - общая. Каждый элемент очереди содержит задание для всех координат. Наглядной аналогией являются кадры G кода - G0/G1. Они тоже содержат задания для всех координат.

Это ты сейчас лёгким движением мысли засунул планировщик траектории в генератор, между прочим работающий в RT...
Но тут возникает небольшой вопрос: А зачем тогда нужен "мастер" и что он будет делать?

[MX_Master]

Хотя это и не ко мне вопрос, но очередь присланных команд - общая. Каждый элемент очереди содержит задание для всех координат. Наглядной аналогией являются кадры G кода - G0/G1. Они тоже содержат задания для всех координат.

Это ты сейчас лёгким движением мысли засунул планировщик траектории в генератор, между прочим работающий в RT...
Но тут возникает небольшой вопрос: А зачем тогда нужен "мастер" и что он будет делать?

Сергей, все планы строит как раз мастер. И тот факт, что мастер отдает приказы, похожие на кадры G кода, не говорит о том, что планировщик есть в генераторе. Мастер может изменить начальную траекторию и подачи, взятые из g кода, как ему угодно. Например, загрубить изначальную дугу на отрезки. А потом прикажет генератору выполнять эти отрезки с другими подачами.

Генератор четко выполняет приказ движения из точки А в точку Б, со строго указанными подачами и ускорениями. Единственное, что он может планироаать - это формулы ускорения и формулы движения по дуге. Все эти формулы должны чётко соответствовать выданным приказам. Самостоятельно менять траекторию генератор не должен.

[tooshka]

Михаил никого не слушай, ждем от тебя контроллер)))

[MX_Master]

Более опытных людей надо слушать обязательно, а у Сергея опыта ровно на вагон больше, чем у меня (:

[Serg]

Сергей, все планы строит как раз мастер. И тот факт, что мастер отдает приказы, похожие на кадры G кода, не говорит о том, что планировщик есть в генераторе. Мастер может изменить начальную траекторию и подачи, взятые из g кода, как ему угодно. Например, загрубить изначальную дугу на отрезки. А потом прикажет генератору выполнять эти отрезки с другими подачами.

Т.е. синхронизация должна происходить довольно часто, генератор-же не знает по какой траектории происходит движение. Где в этом случае генератор сможет применить свои умения типа разгона по S-кривой?

Генератор четко выполняет приказ движения из точки А в точку Б, со строго указанными подачами и ускорениями. Единственное, что он может планироаать - это формулы ускорения и формулы движения по дуге. Все эти формулы должны чётко соответствовать выданным приказам. Самостоятельно менять траекторию генератор не должен.

Только я вижу противоречие между "Генератор четко выполняет приказ" и "он может планировать"?
Что за формулы, где он их возьмёт, в каком виде они будут заданы? Как они будут синхронизироваться между осями?

[MX_Master]

Сергей, как сделаю первый тестовый образец, вам первому покажу.

Тут будет всё как в жизни: поступил сверху приказ покрасить забор в зелёный цвет за три дня, и дальше солдат может планировать и думать как хочет, может ваще не думать, но выполнить обязан.

[tims]

Была вот такая тема на форуме http://www.cnc-club.ru/forum/viewtopic. ... k&start=80
Правильно ли я понимаю, для реализации s-кривых нужна поддержка и в планировщике и в драйвере (генераторе), или в пределах сервоцикла они не нужны и будет достаточно реализации в планировщике?

[Shkryab]

Тут будет всё как в жизни: поступил сверху приказ покрасить забор в зелёный цвет за три дня, и дальше солдат может планировать и думать как хочет, может ваще не думать, но выполнить обязан.

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

[Serg]

Тут будет всё как в жизни: поступил сверху приказ покрасить забор в зелёный цвет за три дня, и дальше солдат может планировать и думать как хочет, может ваще не думать, но выполнить обязан.

Солдат может запланировать покрасить забор за 2 дня и целый день отдыхать, но проблема в том, что у поставщика краски могут быть свои планы - поставлять каждый день краску в количестве на 1/3 забора, а строители забора могут вообще запланировать построить забор за 4 дня...

Правильно ли я понимаю, для реализации s-кривых нужна поддержка и в планировщике и в драйвере (генераторе), или в пределах сервоцикла они не нужны и будет достаточно реализации в планировщике?

В планировщике нужна обязательно (для рабочих движений по G1, G2, G3), чтобы результирующая траектория движения нескольких осей получалась именно такой, как задумал планировщик, а не как решили генераторы/приводы, каждый по своему. Да и длительность сервоцикла (LinuxCNC -1ms, Mach3 - 2ms) ничтожна в сравнении с мех. характеристиками приводов - т.е. им просто не хватит этого времени на реализацию S-кривой разгона/торможения. А продолжать свой разгон/торможение за пределами одного сервоцикла они не имеют права, ибо это будет вопервых искажение заданной траектории, а вовторых они просто не знают какая команда ждёт их в след. сервоцикле.

[tims]

А подождать команду следующего сервоцикла и начать исполнять предыдущий это криминал?
Тогда часть функционала s-кривой будет в приводе, но планировщик будет в курсе этого функционала - расчёт будет вестись с его учётом.

[Serg]

А подождать команду следующего сервоцикла и начать исполнять предыдущий это криминал?

Ну если забить на синхронизацию с внешними сигналами от датчиков и т.п. и на возможность работы со вторым контуром ОС (линейками), то не криминал.

Тогда часть функционала s-кривой будет в приводе, но планировщик будет в курсе этого функционала - расчёт будет вестись с его учётом.

Т.е получается, что в этом случае расчитывать S-кривые должны уметь и планировщик и генератор/привод. Но тут опять возникает всё тот-же неудобный вопроос: нафига в таком случае S-кривые в генераторе, если он может получать результаты расчёта вместе с командами от планировщика?

P.S. Вам всё ещё не кажется подозрительным, что S-кривые ещё пока никто не реализовал для рабочего движения по G1, G2, G3?..

[sidor094]

Привода разгоняются по экспоненте.Она накладывается на разгонную характеристику чпу(линейный или s образный).Может сделать как в приводах и не заморачиваться с s обраным разгоном?

[tims]

P.S. Вам всё ещё не кажется подозрительным, что S-кривые ещё пока никто не реализовал для рабочего движения по G1, G2, G3?..

Непонятно )
В роботах есть.
В 3д принтерах есть.
В остальных применениях фича не востребованная?

Мдя, получается что от реализации кривых в приводе смысла мало.

[wldev]

P.S. Вам всё ещё не кажется подозрительным, что S-кривые ещё пока никто не реализовал для рабочего движения по G1, G2, G3?..

Да много где реализовано, и я реализовал в WLMotion. и по прямым и по кругу... и по спирали..

Также сейчас стыкую контроллер WLMotion и программу управления станком для гибки проволоки. Там будет и асинхронные движения осей.
Например поворот головы идёт по S кривой (большая масса=инерция=пружение=при передачи момента движения), а все остальные по трапеции.

вот старое видео для понимания...
https://www.youtube.com/watch?v=87Z_q4AGwLg

[Serg]

В роботах есть.

Если не требуется согласованного движения нескольких суставов одновременно, т.е. соблюдения точной траектории.
Если-же этого не требуется, а нужно просто переместиться в конкретную точку неважно по какому пути, то S-кривые применяются. Но это аналог G0, а я писал про G1-G3.

В 3д принтерах есть.

Не встречал. Правильная реализация S-кривых для G1-G3 в 3д принтерах сильно сомнительна - в применяемых в них МК просто не хватит вычислительных ресурсов для этого.

Также сейчас стыкую контроллер WLMotion и программу управления станком для гибки проволоки. Там будет и асинхронные движения осей.
Например поворот головы идёт по S кривой (большая масса=инерция=пружение=при передачи момента движения), а все остальные по трапеции.

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

Ранее тут уже выяснили, что разгон по S-кривой занимает больше времени, чем обычный линейный. А одно из требований к рабочему ходу (G1-G3) - как можно быстрее выйти на заданную скорость, ибо от этого зависит качество обработки и долговечность инструмента. Т.е. получается, что S-кривые вредны для рабочего хода...

Чтобы в живую посмотреть, какие траектории получаются достаточно на станке с сервоприводами (желательно с осями, заметно отличающиеся массой/инерцией) загрубить настройки PID сервоприводов (чтоб они были "помягче") и пробовать разные траектории, чем они будут мельче, тем эффект будет заметнее.
В LinuxCNC с обратной связью от приводов результат заметить, и даже измерить будет проще - при отклонении от заданной траектории станок будет аварийно останавливаться по "following error".

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

В моем проекте (поршневой дозатор) это тоже не требуется и даже будет вредно, поскольку мастером является одноплатник с ОС Android

Для шприц-дозатора может оказаться удобнее полностью автономное устройство, наподобие этого:

Конкретно в этом один канал, но в неспешной разработке трехканальный вариант.