Расчет стыковки скоростей (G61/G64) линейных осей и осей вращения.

[AuDin]

Добрый.

Пишу свою CNC.
Сделал расчет скругления траектории по G64/61 - рассчитал все эти дуги (даже трехмерные) - все стыковки изменения направлений , заходы и выходы из спиралей и прочая математика, матрицы, трансформация и пр....
Вот примерно так:

Радиусы скругления на скрине безбожно завышены - чтобы видно было..

Осталось рассчитать подачи - т.е. расчет точек, ускорений, скоростей замедления и разгона.
Думал - да что там сложного - одни умножения и деления.....

И тут я понял что напрочь забыл про стыковку скоростей осей линейных и вращения...
Вот пол года делаю!
В уме пол года одни расчеты.
А это упустил из виду
Вот как так!
Как шоры какие-то.....

И я Впал в ступор - нет понимания как делать эту стыковку.
Пример:
G1 X0 Y0 Z0 A0
G1 X10 A10
G1 X20 A100
На стыке второго и третьего кадра - резкое изменение скорости по оси А.
И получается если траектория идеальная - то надо делать остановку до нуля перед 3 кадром.
На практике - нужно как-то рассчитать плавную стыковку - как и в плоскостях XYZ.
В XYZ - там все понятно - замедление (не до нуля), расчет дуги (пусть даже и в произвольной трехмерной плоскости - а не G17/18/19)- которая бы давала ошибку не более чем указано в G61/64 и далее опять разгон....
А тут как?

Т.е надо ка-то проложить траекторию и ускорения так - чтобы ошибка была не более чем указано в G61/64..
Тогда вопрос - а что есть ошибка на осях вращения?
Как ее рассчитать? (хотя-бы на пальцах - формулы надеюсь сам выведу)

Если Ось "A" допустим ось вращения детали - как я понимаю ошибка - это длина дуги по углу рассогласования...
Слава богу у Меня в CNC можно вычислить расстояние от точки резанья до оси вращения любой оси - для расчета этой дуги.
Но это если по линейным осям не было изменения направления..
А если было...?
Пренебречь?
Или отдельно считать ошибку позиционирования по линейным осям и отдельно по осям вращения?

А если ось А - это ось вращения не детали - а шпинделя?
Тогда вообще не понятно - что тогда в этом случае есть ошибка позиционирования..
Точка реза то не меняется вообще при повороте по A шпинделя...
Меняется только угол инструмента к точке резанья....

Может кто знает как это сделано в других CNC?
В том-же LinuxCNC например...

Или какие другие идеи...

[hmnijp]

В XYZ - там все понятно - замедление (не до нуля), расчет дуги (пусть даже и в произвольной трехмерной плоскости - а не G17/18/19)- которая бы давала ошибку не более чем указано в G61/64 и далее опять разгон....
А тут как?
Тогда вопрос - а что есть ошибка на осях вращения? Как ее рассчитать? (хотя-бы на пальцах - формулы надеюсь сам выведу)

Или отдельно считать ошибку позиционирования по линейным осям и отдельно по осям вращения?

Ну по большому счету да - задается отдельно параметр линейного и углового максимального отклонения

Может кто знает как это сделано в других CNC?
В том-же LinuxCNC например...

Сейчас - никак там этого не сделано, обратные кинематические преобразования есть, но при вызове поворотных осей планнер все равно из g64 сглаживания с предпросмотром переключается в построчный режим.
НО!, там как раз, прямо сейчас этим занимаются в теме про новый планнер(с s-кривыми, nurbs сглаживанием, а не только дуговым локальным), и ты можешь понаблюдать, посмотреть код, поучаствовать , если есть желание) Да и в целом там полистать тему, есть всякие ссылки на литературу, и подобные реализации, я и сам там об этом несколько сообщений оставлял для кругозора. например о том что локально(дугами) сглаживать многоосевые пути нерационально, тк на практике такие траектории это огромная плотность точек на мм - тысячи кадров в секунду. там банально негде дуги строить - большинство занимаются глобальным сглаживаием - заново апрокcимируют сплайнами или разными алгоритмами фильтрации/компрессии, получая единый гладкий путь с геометрической непрерывностью g2-g3(что также является условием для ограничения рывка/s-кривых)
https://www.youtube.com/watch?v=TXA9uAc-mT4
https://forum.linuxcnc.org/38-general-l ... 480#304938


В кратце, как это сделано у большинства чпу, современный метод решения этой задачи:
Берем единичный вектор ориентации на оси инструмента, соединяя его вершину по точкам в коде - получаем как бы второй путь паралельный пути кончика инструмента(тут есть нюанс с поворотами более 180°, но это редкий случай, и может решаться на уровне постпроцессора) - сглаживаешь этот путь вектора ориентации c ограничением отклонения угла от запрограммированного, аналогично как и путь кончика инструмента - получаешь две кривые/сплайна которые должна пересекать ось инструмента, далее уже интерполируешь и считаешь профиль скоростей-ускорений. если нужно, применяешь обратные кинематические преобразования - они решают вопрос максимальной ошибки - тк важна только максимальная ошибка отклонения инструмента(в системе rtcp), а какое отклонение самих осей будет, уже не важно. Многие это считают даже не в реалтайме... то есть заранее сглаживают по ограничению, не подгоняя величину отклонения под ускорения по факту, а просто потом уже пускают по этому рассчитанному пути машину.
Более подробно - поищи статьи на английском 5axis toolpath smoothing, spline/nurbs interpolation.. их в принципе много в открытом доступе находится, с примерами расчетов. и довольно много китайских за последние годы.

[AuDin]

О!!!.
Я уже думал никто не ответит.
СПС за наводку на форму- буду вдумчиво читать.

Ну по большому счету да - задается отдельно параметр линейного и углового максимального отклонения

Мне видится чуток по другому.
Как таковое задание "углового максимального отклонения" на мой взгляд бесполезно.
Т.к. на осях имеем "Гусиную шею"
Т.е. при увеличении расстояния точки резанья от оси поворота допустим в 2 раза - получаем увеличение рассогласования на 2*Pi - т.е. сразу в шесть раз.
И если задавать "угловое максимальное отклонение" - то оно по разному будет работать на разных радиусах от центра вращения.

Планирую так:
Есть расстояние максимального рассогласования (Зареза, отклонения, скругления) по G64.
На основе этого значения и расстояния от текущей точки резанья до оси вращения - я рассчитываю "Текущее максимальное угловое отклонение".
И вот на основании этого "Текущего максимального углового отклонения" и надо построить траекторию разгона и торможения по линейным осям и осям вращения.

И вот тут я пока не понимаю что должно получится в итоге.
Именно - что - а не как.

Сделал в СолидКам УП по 5 осям (полное 5-ти осевое - а не 3+2).
Солид при совместном движении по более чем 4 осям выдает УП мелкими шажками - все ок.
Я по черновому прикинул кривые разгона и торможения по осям для этой УП.
И вот что у меня получается:

- Если расстояние от текущей точки резанья до оси вращения небольшие то все ок.
Есть запас по ускорениям для сглаживания траектории, тормозится до нуля не нужно все ок.
И самое главное не нужно сильно оттормаживать оси А и B.

- Но вот если расстояние от текущей точки резанья до оси вращения становятся значимыми (например или в патроне обрабатываем колесный диск с диметром до метра или если вращается шпиндель - а не деталь - и в шпинделе зажат длинный инструмент + длина оправки + расстояние до оси вращения шпинделя) то получается очень грустно:
И за большой "Гусиной шеи" по расчётам для поддержания рассчитанного максимального рассогласования при интерполированном движении по линейным осям и осям вращения придется оттормаживаться до нуля.
Иначе траекторию без зарезов не пройти. (или резко превышать заданные максимальные ускорения)

Я попробовал посмотреть - а как на других то CNC Сделано?
Они по осям вращения если и тормозят - то это ну прямо не заметно.
И у меня стойкое ощущение что другие CNC и не пытаются поддерживать согласованное интерполированное движение между линейными осями и осями вращения ВНУТРИ КАДРА УП.
Т.е. просто делают так чтобы положение Линейных и осей вращения совпало с заданным в УП кадре к КОНЦУ КАДРА!
А в внутри кадра УП даже не пытаются их согласовать.
Типа САМ системе виднее! - в конце кадра координаты совпадают - типа что не так?!
И это работает когда Кам выдает траекторию мелкими шажками.

Я попробовал рассчитать так-же - тогда да - нет постоянного "старт-стопа".

Но ведь САМ система может и по другому создавать УП.
Например СолидКам может создавать траекторию 3+1 (как они это называют)
Там просто для расчета вместо плоскости подсовывается цилиндр - и КАМ считает что допустим ось X - это ось вращения по выбранной оси.
И УП тогда она рисует большими шагами, может в одном кадре ось повернуть и на 30 гр.
И тогда согласованное интерполированное движение между линейными осями и осями вращения архиважно.

Вот как оно всё-таки должно быть на выходе? (пока абстрагируемся от вопроса - как сделать - вопрос - что сделать)

[hmnijp]

Мне видится чуток по другому.
Как таковое задание "углового максимального отклонения" на мой взгляд бесполезно.
Т.е. при увеличении расстояния точки резанья от оси поворота допустим в 2 раза - получаем увеличение рассогласования на 2*Pi - т.е. сразу в шесть раз.

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

Ну и расчет траектории заранее тоже упрощение ради этого - ты скармливаешь сглаженную траекторию с уже установленной максимальной ошибкой - а дальше планируешь/интерполируешь движение кинематики для её соблюдения. Это немного отличается от планирования в 3х осях - где радиус скругления меняется в зависимости от текущей скорости. Хотя если есть ресурсы, можно было бы попробовать считать в реалтайме, на на сколько я знаю и видел примеры реализации - lcnc и opencn на rt ядре считать это не успевают, возможно вопрос оптимизации. сам я такое не хардкодил.

И за большой "Гусиной шеи" по расчётам для поддержания рассчитанного максимального рассогласования при интерполированном движении по линейным осям и осям вращения придется оттормаживаться до нуля.
Иначе траекторию без зарезов не пройти. (или резко превышать заданные максимальные ускорения)

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

И у меня стойкое ощущение что другие CNC и не пытаются поддерживать согласованное интерполированное движение между линейными осями и осями вращения ВНУТРИ КАДРА УП.
И УП тогда она рисует большими шагами, может в одном кадре ось повернуть и на 30 гр.
И тогда согласованное интерполированное движение между линейными осями и осями вращения архиважно.

Ну нет, по большей части у большинства чпу логика одинаковая - кадр квантуется на равные мелкие отрезки по времени сервоцикла, и там не может получиться рассинхрона внутри кадра, (разве что внутри сервоцикла небольшое)... согласованность движения в приоритете. И g93 тоже для этого был придуман, где f это время синхронного выполнения кадра линейных и угловых осей, а не скорость, чтобы чпу было проще считать.
Ну а отклонение какой либо оси от задания планировщика (following error) более чем на максимально установленную величину - это ошибка и и повод для остановки всей системы. проверка происходит каждый сервоцикл, а не в концах кадра. чем меньше цикл, соответственно тем точнее. у фанука это 10кгц к примеру - можете прикинуть какой уровень синхронизации у всех осей на какой-то целевой скорости...

А вот то что стойки без rtcp никак физически не способны оценить реальную ошибку на конце инструмента - это да, есть такое....
В приличных 5осевых сейчас особо нигде не используют координаты физических осей в коде заранее предрасчитанные в посте... везде стараются применять rtcp код, в котором координаты и углы - это центральная точка и наклон инструмента, и соответственно стойки его поддерживающие.
https://linuxcnc.org/docs/html/motion/5 ... atics.html

[AuDin]

И g93 тоже для этого был придуман, где f это время синхронного выполнения кадра линейных и угловых осей, а не скорость, чтобы чпу было проще считать.

Так расчеты от этого не проще становятся - а сложнее.
На мой взгляд G93 был придуман именно для CNC без TCP.
Такие CNC ничего не знаю про геометрию вращения осей - соответственно не могут рассчитать нужную угловую скорость от подачи.
Вот и скармливают им не скорость резанья, а время, за которое нужно пройти кадр УП.
Показательно - если забить в поиск G93 - выдает:
ICD-Code: G93: Другие поражения головного мозга гугл врать не может!
Кстати в СолидкСам уже дано нельзя выдать УП по G93 - СолидкСам уже где-то два года неправильно считает время кадра - я пытался извратится в пост-процессоре - но бестолку - они просто забили на расчет обратного времени.

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

Имеется в виду что выдают точки в режиме: "Координаты точки резанья + угловые координаты наклона режущего инструмента"???
Просто Все Сам - называют это режимом TCP...
И это да - это я и пытаюсь сделать в обязательном порядке.

Вопрос про S-кривые (при разгоне и торможении)
Каким параметром это задается в настройках CNC?
Вернее так: Каким параметром ПРАВИЛЬНО задавать параметры S-кривой в настройках CNC?
Я встречал такие варианты:
1. Время в процентах от времени разгона от нуля до максимальной скорости (допустим 20% времени уходит на плавный разгон - далее разгон на максимальном ускорении)
2. Тоже самое что и 1 - но время в мс - а не в процентах
3. Дельта скорости (в начале разгона и в конце торможения)- на которую применяется сглаженные ускорения

И применяется ли в ЧПУ "динамические" S-кривые?
Это когда - если допустим ускорение от нуля до максимума - применятся стандартное время сглаживания.
А если разгон идет допустим от 0 до 20% от максимальной скорости - время сглаживания S-кривой уменьшается.
Соответственно разгон идет быстрее, Но это компенсируется зачет меньшего набора скорости и соответственно меньшего времени набора и соответственно меньшего "общего импульса" ускорения.
????