cnc-club.ru

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

UAVpilot писал(а):А оси ты как синхронизировать собираешься?

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

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

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

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

Argon-11 писал(а):Генератор ващето можно считать реалтаймным девайсом, он и будет синхронизировать оси.

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

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

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

UAVpilot писал(а):

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

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

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

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

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

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

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

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

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

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

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

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

MX_Master писал(а):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tims писал(а):В роботах есть.

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

tims писал(а):В 3д принтерах есть.

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

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

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

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

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

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

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