Сравнение бюджетных систем управления ЧПУ

[michael-yurov]

PKM, ну вот смотри, например, мы рассматриваем случай, когда фреза проходит по окружности с диаметром 2 мм (ну, например, при трохоидальной обработке) и траектория сохранена линейными сегментами и KMotinCNC строит скругления на стыках, и мы задали такие параметры, что радиус этих скруглений равен радиусу участка траектории, т.е. 1 мм.
При стандартных настройках эти скругления будут разбиты на кусочки с углом изменения траектории в 1°.
Допустим, в настройках системы ЧПУ задано предельное ускорение по осям 500 мм/сек², тогда исходя из центростремительного ускорения в 500 мм/сек² получим, линейную скорость 22,36 мм/сек (1341 мм/мин).
Полная окружность была бы пройдена за 0,281 сек, т.е. в случае LinuxCNC была бы разбита на 281 кусочек.
KFlop с настройками по умолчанию разделит ее на 360 кусочков, и потом еще "подравняет" фильтром и выдаст результат, плавно изменяя скорость 3100 раз за время прохождения полной окружности!
И это при достаточно низких значениях ускорения, и при настройках по умолчанию!
Если бы речь шла про дорогой станок с большими значениями ускорения - разница была бы намного больше. И при этом никто не мешает настроить KMotionCNC на более мелкое разбиение изменив один единственный параметр.

Полагаю, и в LinuxCNC можно "повысить точность", но есть ли в этом смысл?
Так что на счет "проигрывает полностью", "корявый способ" и "детские недостатки" - это ты явно не прав.

[PKM]

В реальности в момент ступенчатого изменения скорости возникает возникает всплеск ускорение бесконечно большой величины.

Это не совсем так.
Сервопериод 0.001с, значит при ускорении 1000 мм/с2 изменение скорости за сервопериод не должно превышать 1мм/с, так? Не вижу здесь проблемы.
Иначе любой принтер на ардуино имеет хороший планировщик, почему нет? И это мы еще на jerk не смотрим, там вообще мрак будет

Если так рассуждать - то у нас с каждым импульсом Step возникает бесконечно большое ускорение

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

Сомневаюсь, что расчетной единицей в данном случае является сервопериод. Кстати, у KFlop он в 11 раз меньше, чем у LinuxCNC! И я считаю, что это имеет значение для систем с очень высокими требованиями.

Насчет этих требований мы уже не раз спорили. Они на станках дешевле 100К зеленых совершенно бессмысленны. Синдром принцессы на горошине.

А сможешь ты его поставить так, чтобы он не влиял на траекторию и станок проходил точно по координатам вершин? KFlop делает именно так.

Я этого не заметил. На графиках явно показано отклонение от вершины. Это обычный ФНЧ, такой же как у тебя в плате. Он не имеет отношения к планировщику траектории, просто сглаживает выбросы постфактум.

Ну так а между сервоциклами что происходит?

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

Там, вроде бы речь про разбиение на отрезки участков скругления, а круговая интерполяция в KFlop честная - дуговые сегменты так и передаются в контроллер в виде дуг.
А угол разбиения для участков скругления задается в настройках планировщика - хочешь 1°. Хочешь - 0,1°.

Да, здесь принципиально разный подход. Интерполяция окружностями и отрезками. Конечно, разбиение на бесконечное количество отрезков даст окружность. Но тогда почему они по умолчанию не забили деление на бесконечное количество кусочков? Вот и приходится крутиться со всякими ФНЧ...
А вот применение ФНЧ к интерполированной траектории LinuxCNC даст уже S-кривую.


Я с LinuxCNC вожусь уже лет 5, и не устаю поражаться ее возможностям. Был единственный серьезный недостаток - планировщик без предпросмотра, и тот исправили.
Сегодня поставил KMotionCNC, такое впечатление, что пересел с ПК на советский игровой автомат
Да, неплохая по сравнению с Mach3, довольно настраиваемая. Но это система чуть выше начального уровня и не более того.
Там практически нет планировщика, просто кусочный аппроксиматор. Например они сами пишут: вот при таких параметрах the velocity is much smoother and the Acceleration is less Jerky. То есть это ничего не меняет, а только сглаживает выбросы скорости. А если вам еще сильнее надо сгладить выбросы, то включайте ФНЧ. И только тогда (!) реально впишетесь в пределы по ускорениям.

А в настоящем планировщике LinuxCNC от параметров точности реально зависит скорость прохождения траектории, соблюдаются все ограничения.

Так что на счет "проигрывает полностью", "корявый способ" и "детские недостатки" - это ты явно не прав.

Это ты просто не знаешь LinuxCNC, см. выше...

ПС: самое главное подтверждение - не встречал ни одного человека с глубокими знаниями LinuxCNC, которого удалось бы заставить купить KFLOP

Мой совет - разберись в LinuxCNC, не пожалеешь! Замечательная ЧПУ, чем свою писать - лучше что-то доработать в LinuxCNC!

[PKM]

michael-yurov, хоть убей не пойму, как мач3 работает!
Вот свежий пример Mach3 срезает углы. #1
Но как он может срезать угол 90 градусов, если ему явно сказано в настройках НЕ СРЕЗАТЬ больше 20 градусов?
Это не ЧПУ, а недоразумение...

[michael-yurov]

Сервопериод 0.001с, значит при ускорении 1000 мм/с2 изменение скорости за сервопериод не должно превышать 1мм/с, так? Не вижу здесь проблемы.

Да и нет никакой проблемы.
Но в момент ступенчатого изменения скорости теоретически получаем бесконечно большое мгновенное ускорение, т.к. ΔV / Δt (при Δt стремящемся к нолю) = бесконечность.

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

Так у нас и теоретическая мгновенная скорость в момент каждого шага тоже бесконечна.
Мне кажется ты путаешь график ускорения со скоростью.

Я этого не заметил. На графиках явно показано отклонение от вершины. Это обычный ФНЧ, такой же как у тебя в плате. Он не имеет отношения к планировщику траектории, просто сглаживает выбросы постфактум.

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

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

Конечная смена скорости- это и есть бесконечно большое мгновенное ускорение.

Насчет этих требований мы уже не раз спорили. Они на станках дешевле 100К зеленых совершенно бессмысленны. Синдром принцессы на горошине.

Ну а что же ты тогда докопался до KMotionCNC у которого есть ступеньки смены скорости (при чем при стандартных настройках на порядок мельче, чем у LinuxCNC), и KMotionCNC стал для тебя "системой чуть выше начального уровня и не более того", "Там практически нет планировщика" и т.п?

Есть конечная смена скорости, которая не превышает заданного ускорения.

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

Интерполяция окружностями и отрезками.

Ты, видимо, половину моих слов мимо пропускаешь.
KMotionCNC не разбивает дуговые сегменты на линейные! Линейными сегментами передаются лишь данные скругления участков траектории.

Конечно, разбиение на бесконечное количество отрезков даст окружность. Но тогда почему они по умолчанию не забили деление на бесконечное количество кусочков?

Деление чего? Участков стыковки сегментов? А что же у самой УП не сохранили с бесконечно мелким разбиением? KMotionCNC только улучшает исходную траекторию, но до необходимого, заданного в настройках уровня.

Вот и приходится крутиться со всякими ФНЧ...

Да не приходится никому крутиться. Если его не использовать - никто ничего и не заметит.

А вот применение ФНЧ к интерполированной траектории LinuxCNC даст уже S-кривую.

Так и KMotionCNC даст. Хочешь - используй.

Сегодня поставил KMotionCNC, такое впечатление, что пересел с ПК на советский игровой автомат

Интерфейс программы - сырой, не спорю. Но все необходимое работает практически идеально.

Там практически нет планировщика, просто кусочный аппроксиматор.

Ну, это уже какое-то "бросание какашками".
Планировщик - лучше некуда. Чего тебе там не хватает?

Например они сами пишут: вот при таких параметрах the velocity is much smoother and the Acceleration is less Jerky. То есть это ничего не меняет, а только сглаживает выбросы скорости.

Не выбросы скорости, а выбросы jerk (скорости изменения ускорения).

И только тогда (!) реально впишетесь в пределы по ускорениям.

Ну это уже какой-то бред.

А в настоящем планировщике LinuxCNC от параметров точности реально зависит скорость прохождения траектории, соблюдаются все ограничения.

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

Это ты просто не знаешь LinuxCNC, см. выше...

Ну так расскажи, чего я про него такого не знаю.
Я сравнивал лишь те параметры и возможности, которые были мне интересны.
То, что LinuxCNC открытая система, я я там могу изменить все - меня мало волнует.
Для KMotionCNC тоже есть исходники программы, но мне от этого не легче.

ПС: самое главное подтверждение - не встречал ни одного человека с глубокими знаниями LinuxCNC, которого удалось бы заставить купить KFLOP

Банально - приставляешь к виску пистолет, даешь денег и он его покупает.

А встречал хоть одного человека с глубокими знаниями KMotionCNC, которого удалось бы заставить поставить на свой станок LinuxCNC?

Мой совет - разберись в LinuxCNC, не пожалеешь! Замечательная ЧПУ, чем свою писать - лучше что-то доработать в LinuxCNC!

Чем лучше - не могу понять.

Я хочу написать свою простую, понятную, относительно недорогую, без существенных недостатков, красивую, простую в установке, настройке, освоении и использовании систему ЧПУ.
Основные цели - заполнить брешь на рынке, применить свои знания, и заработать себе на жизнь. Как в этом случае мне может помочь "что-то доработать в LinuxCNC"?

[michael-yurov]

michael-yurov, хоть убей не пойму, как мач3 работает!
Вот свежий пример Mach3 срезает углы. #1
Но как он может срезать угол 90 градусов, если ему явно сказано в настройках НЕ СРЕЗАТЬ больше 20 градусов?
Это не ЧПУ, а недоразумение...

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

А вот о чем там говорит Bert - я не знаю.
Скорее всего смотрит на визуализацию на экране.
Она не соответствует реальной траектории.

Где УП, где фото результата?

[PKM]

michael-yurov, давай дадим некоторые определения.
Пускай есть два состыкованных линейных сегмента с неким углом между ними.
Если в этом углу НЕТ скругления, значит ускорение бесконечно большое, т.к. конечное изменение скорости происходит за (условно) нулевое время.
Если же скругление ЕСТЬ - ускорение конечное, т.к. конечное изменение скорости происходит за конечный интервал времени прохождения скругления.
Согласен?

[PKM]

Я хочу написать свою простую, понятную, относительно недорогую, без существенных недостатков, красивую, простую в установке, настройке, освоении и использовании систему ЧПУ.
Основные цели - заполнить брешь на рынке, применить свои знания, и заработать себе на жизнь. Как в этом случае мне может помочь "что-то доработать в LinuxCNC"?

LinuxCNC уже является такой системой... выпускай под нее железо и продавай. Сделай свою конфигурацию для этого железа и наслаждайся жизнью. Красивую - напиши интерфейс! Добавь то, чего в ней не хватает, заполни брешь на рынке. Но зачем писать с нуля новую ЧПУ?

[michael-yurov]

michael-yurov, давай дадим некоторые определения.
Пускай есть два состыкованных линейных сегмента с неким углом между ними.
Если в этом углу НЕТ скругления, значит ускорение бесконечно большое, т.к. конечное изменение скорости происходит за (условно) нулевое время.
Если же скругление ЕСТЬ - ускорение конечное, т.к. конечное изменение скорости происходит за конечный интервал времени прохождения скругления.
Согласен?

С небольшим уточнением.
Если скругление есть, то мгновенное значение ускорения равно (V(t+Δt) - V(t)) / Δt при Δt стремящемся к нолю.
т.е. нужно брать не весь участок скругления, а минимальный, стремящийся у к нолю участок, на котором мы сможем определить наклон графика скорости (ускорение).

Но зачем писать с нуля новую ЧПУ?

Даже если не смотреть на финансовую сторону вопроса (а я не готов работать бесплатно), мне проще написать с ноля, чем довести LinuxCNC до такого уровня, как я хочу.

[PKM]

Планировщик - лучше некуда. Чего тебе там не хватает?

Собственно планировщика

Давай посмотрим на их же графики, первые три. Траектория же кусочная, так? Как ее нужно нормально проходить, чтобы не было запредельных выбросов ускорения, о которых ты говоришь? Нужно остановиться в конце каждого отрезка, потом разогнаться в начале следующего. Мы это видим на графиках? Нет. На графиках мы видим, что "планировщик" тупо прет с заданной скоростью подачи, на углах скорость не сбрасывается, что дает в моменты перехода на следующий отрезок выбросы ускорения в 10 раз превышающие норму!
Хваленое "сглаживание" состоит в дроблении отрезков и соответственном уменьшении выбросов ускорения. Внимательно смотрим на следующие графики, сравниваем с первыми - средняя скорость прохождения даже не изменилась.
Где здесь планирование? Это просто загонять ускорение в заданные рамки, вот и все. Причем дальше сами признаются, что это проблему решает не полностью, а For still further motion smoothing an additional KFLOP feature can be used.
Ты говоришь, что ФНЧ проходит через заданные точки? Где же? Например на графике The case below is with 3 milliseconds of filtering with a path error of ~ 0.1 mil (2.5um)

Что же с такой траекторией делает настоящий планировщик LinuxCNC?
При работе в режиме точной остановки G61 он будет полностью останавливаться в каждом углу. Иначе добиться точного прохождения кусочной траектории невозможно.
При работе в режиме сглаживания G64 задается максимальное отклонение от заданной траектории, исходя из которого планировщик строит скругления между сегментами. Которые и позволяют пройти эти углы без полной остановки, а всего лишь с некоторым снижением скорости при полном выполнении ограничений по ускорению. Чем больше допустимое отклонение, тем больше величина скругления, тем меньше сбрасываем скорость. Так работают настоящие системы ЧПУ. Вот пример прохождения по квадрату со скругленными углами

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

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

Это совсем разные библиотеки

[PKM]

KFlop с настройками по умолчанию разделит ее на 360 кусочков, и потом еще "подравняет" фильтром и выдаст результат, плавно изменяя скорость 3100 раз за время прохождения полной окружности!
И это при достаточно низких значениях ускорения, и при настройках по умолчанию!
Если бы речь шла про дорогой станок с большими значениями ускорения - разница была бы намного больше. И при этом никто не мешает настроить KMotionCNC на более мелкое разбиение изменив один единственный параметр.

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

То есть я не говорю что в Кфлопе вообще нет планировщика. Конечно он взял планировщик из первого ЕМС, он разгоняется, тормозит. Но вот эти кусочные траектории проходит по-тупому без снижения скорости. Я это нормальным признать не могу.
Качественный планировщик Том не потянул, а скорость на кусочных траекториях в ЕМСшном была очень низкой. И он решил "плевать на ускорения, кто там будет разбираться! Зато скорость обработки повысим"
И был прав! Нафига вообще эти планировщики, ограничения... если клиенты и Мачем довольны, Кфлоп тем более хорош.
Интересно, Фанук и Сименс тоже плюют на ускорения?

[michael-yurov]

Давай посмотрим на их же графики, первые три. Траектория же кусочная, так?

Да, для примера взяли кусочную траекторию (такой был файл УП, что нижняя правая дуга состоит из линейных сегментов).

Как ее нужно нормально проходить

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

чтобы не было запредельных выбросов ускорения, о которых ты говоришь

Ничего такого не говорил.
Путаешь теорию и практику.

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

Нет, на графиках не работа планировщика. На графиках теоретические изыскания - как бы было, если бы было все по простому...

на углах скорость не сбрасывается,

Зачем ее сбрасывать, если по идее там должна быть дуга?, просто ее в УП сохранили сегментами.

то дает в моменты перехода на следующий отрезок выбросы ускорения в 10 раз превышающие норму!

Еще раз повторюсь - график просто для наглядности. Выбросы ускорения зависят от интервала дискретизации. Какой он там - никто не знает.

Хваленое "сглаживание" состоит в дроблении отрезков и соответственном уменьшении выбросов ускорения.

Не в дроблении отрезков - а в построении скругления с необходимой точностью (по умолчанию - 1°, чего более чем достаточно для типовых задач).

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

Она и не должна была измениться - траектория то ведь прежняя!

Где здесь планирование? Это просто загонять ускорение в заданные рамки, вот и все.

Ну еще траектория была сглажена. А что еще требовалось?

Причем дальше сами признаются, что это проблему решает не полностью,

Полностью - это на сколько? До состояния передачи контроллер криволинейной траектории вместо линейных сегментов? А есть ли в этом реальная необходимость? Я сильно сомневаюсь.
Можно вообще передавать данные в виде коэффициентов ряда Фурье, но зачем?

Да может быть еще применен фильтр нижних частот. Ну, и хорошо. Я считаю это хорошей идеей.

Ты говоришь, что ФНЧ проходит через заданные точки? Где же?

В конце написано, что для достижения точного перехода в вершину рассчитывается кубический сплайн:

To complete the path the final position and velocity of each of the coordinated axes are used to calculate a Cubic Spline to complete the final small motion. The Cubic Spline allows continuous velocity from the end of the smoothed path to the target position in a manner where the velocity also reaches zero at the target position. A Time duration of the Cubic Spline set at 2xTau of the low pass filter provides a relatively constant deceleration to the Target.

Последний график довольно сложен для понимания, но он показывает реальную ситуацию.

Что же с такой траекторией делает настоящий планировщик LinuxCNC?
При работе в режиме точной остановки G61 он будет полностью останавливаться в каждом углу.

Ну это понятно. Нет никаких проблем использовать G61 в KMotionCNC.

При работе в режиме сглаживания G64 задается максимальное отклонение от заданной траектории, исходя из которого планировщик строит скругления между сегментами.

Ну и как он их строит? Полагаю, что точно так же.

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

С чего ты это взял?
Если LinuxCNC строит скругление из отрезков, как KMotionCNC - то разницы в результате не будет. Разве что в KMotionCNC можно задать точность построения скруглений.

Вот пример прохождения по квадрату со скругленными углами

Это график того что LinuxCNC старается сделать, а не то, что реально делает.
И график приведен с шагом в 1 мсек, что явно больше, чем графики KMOtionCNC.
И ты говоришь про квадрат со скругленными углами - так там дуговые сегменты, или линейные в исходной УП?

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

ну это уже какая-то отсебятина не имеющая к вопросу никакого отношения.

Но вот эти кусочные траектории проходит по-тупому без снижения скорости.

Чего это вдруг?
Все прекрасно рассчитывает и проходит ровно так, чтобы не превысить допустимые ускорения по осям.

Качественный планировщик Том не потянул,

Ну опять бросание какашками.

а скорость на кусочных траекториях в ЕМСшном была очень низкой.

Вот именно! Даже сравнивать не было смысла.

И он решил "плевать на ускорения, кто там будет разбираться! Зато скорость обработки повысим"

Выдаешь желаемое за действительное.
Так как ты описал работает "планировщик" PlanetCNC (вот там реально "нет планировщика"). Там реально дикие превышения ускорения и т.п.
Такая же фигня и у EdingCNC - на кривых из линейных сегментов жуткие превышения допустимых ускорений.

И был прав! Нафига вообще эти планировщики, ограничения... если клиенты и Мачем довольны, Кфлоп тем более хорош.

Ну опять какая-то фигатень, не имеющая отношения к вопросу.
Ведешь себя, как тролль!

Кстати, а какую величину ускорения на графиках превысили в 10 раз?

[michael-yurov]

Вот пример прохождения по квадрату со скругленными углами

Я так понимаю - график отсюда: http://wiki.linuxcnc.org/cgi-bin/wiki.p ... oryControl
Ну и чего? Там квадрат со скруглениями, которые записаны командами G2.

Код: Выделить всё

%
(1" square with 1/4"r corners)
G90 G54 G20
G64
G0 X0 Y.25 Z.25
z0
G1 Y.75 F999
G2 X.25 Y1 I.25
G1 X.75
G2 X1 Y.75 J-.25
G1 Y.25
G2 X.75 Y0 I-.25
G1 X.25
G2 X0 Y.25 J.25
G0z.25
M30 

G2 / G3 и в KFlop передаются в виде дуговых сегментов без всякого разбиения: http://www.dynomotion.com/Help/CoordinatedMotion.htm

[PKM]

Еще раз повторюсь - график просто для наглядности. Выбросы ускорения зависят от интервала дискретизации. Какой он там - никто не знает.

Нет, на графиках не работа планировщика. На графиках теоретические изыскания - как бы было, если бы было все по простому...

Давай хотя бы разберемся, что там изображено...
To see more clearly the improvement the X Axis motion was captured in real-time (180us sample rate) and plotted.
Это разве не реальные данные, а теоретические изыскания?


At constant velocity the facet angle change causes the x velocity to drop while the y velocity increases
Сами признают, что с постоянной скоростью движутся через углы, то есть не считают нужным тормозить.
Далее этот же эффект просто уменьшается за счет сокращения длины отрезков и угла между ними. Признать полноценным планировщиком это нельзя.

Все прекрасно рассчитывает и проходит ровно так, чтобы не превысить допустимые ускорения по осям.

Кстати, а какую величину ускорения на графиках превысили в 10 раз?

На графиках выбросы ускорения до 300"/с2. Думаешь, это реальные пределы ускорений станка?
А вот после фильтров выбросы снижаются примерно до 30"/с2, вот это уже похоже на "допустимые ускорения по осям".

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

Мы понимаем, а ЧПУ не так просто это понять, между прочим.
Вот это делает LinuxCNC - строит по отрезкам дуговую траекторию и проходит ее.

Это график того что LinuxCNC старается сделать, а не то, что реально делает.

Это реальный график работы планировщика. Давай мне любую траекторию и я тебе построю графики из линукса.

Дай мне кфлоп и я тебе из него построю реальные графики и сравним. К сожалению, без своей платы он не запускается.

Если LinuxCNC строит скругление из отрезков, как KMotionCNC - то разницы в результате не будет. Разве что в KMotionCNC можно задать точность построения скруглений.

LinuxCNC строит траекторию со скруглениями на стыках, а Кфлоп из мелких отрезков. В этом и разница, отсюда и выбросы ускорений.

Так как ты описал работает "планировщик" PlanetCNC (вот там реально "нет планировщика"). Там реально дикие превышения ускорения и т.п.

Вот же сам Том записал дикие превышения ускорения в Кфлопе, какие еще доказательства нужны?

[PKM]

Я так понимаю - график отсюда: http://wiki.linuxcnc.org/cgi-bin/wiki.p ... oryControl
Ну и чего? Там квадрат со скруглениями, которые записаны командами G2.

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

[michael-yurov]

Я читать умею. To see more clearly the improvement the X Axis motion was captured in real-time (180us sample rate) and plotted.
Это разве не реальные данные, а теоретические изыскания?

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

Если взять интервал в 1 мс - никаких всплесков не останется.

Сами признают, что с постоянной скоростью движутся через углы, то есть не считают нужным тормозить.

Так это намеренно сделано каким-то способом!

Далее этот же эффект просто уменьшается за счет сокращения длины отрезков и угла между ними. Признать полноценным планировщиком это нельзя.

Так тут, вроде бы про планирование скоростей и ускорений ни слова не было.
Допустимая скорость движения по этой кривой рассчитывалась где-то раньше.

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

речь про то, что планировщик достраивает скругления на стыках, чтобы избежать всплесков ускорения. Что тебе не нравится - не пойму.
Так же и говорят - если двигаться по траектории в том виде, как она сохранена в УП - придется ступенчато изменять скорость, это приведет к сильным всплескам ускорения в вершинах траектории, что плохо,
поэтому KMotionCNC достраивает в углах такой траектории скругления и это сильно снижает всплески ускорения.

Про допустимую скорость движения по такой кривой там ничего не говорится. Как она рассчитывается - я не знаю.
Знаю только что при движении по окружности состоящей из линейных сегментов скорость очень близка к теоретически допустимой рассчитанной на основе центростремительного ускорения.
Это я проверял.

Мы понимаем, а ЧПУ не так просто это понять, между прочим.

Так о том и идет речь в той статье. Рассказывается, что результат в итоге очень близок к идеалу.

Вот это делает LinuxCNC - строит по отрезкам дуговую траекторию и проходит ее.

Правда что ли?
Где ты такое узнал?

Это реальный график работы планировщика. Давай мне любую траекторию и я тебе построю графики из линукса.

Ну так возьми квадрат, как в той статье со скруглением радиусом в 1 дюйм, и разбиением на сегменты с изменением угла в 3°,
задай такие же настройки, и посмотри, что будет.

Дай мне кфлоп и я тебе из него построю реальные графики и сравним. К сожалению, без своей платы он не запускается.

Не хотелось бы раздирать станок. Я им все же иногда пользуюсь.
Да и отправлять далеко - ты, вроде бы из Украины?
Боюсь, что просто не дойдет.

Могу попробовать записать данные с выхода осциллографом.

Да, просто показывает как на скруглениях без всяких выбросов ускорения работает планировщик.

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

[michael-yurov]

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

С чего ты так решил?
Скругления, насколько я понимаю - это не дуга, а парабола, или гипербола, или еще что-то подобное.

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

"Пусть расцветают сто цветов!" (с) Мао Цзэдун
Хочет Михаил делать свою систему - ради бога! И неважно, какой алгоритм будет у планировщика. И если удастся довести ее до выпуска, я буду рад и за Михаила, и за пользователей его системы.
А LinuxCNC имеет один, но очень крупный недостаток - он под линуксом. И портировать его под винду вряд ли кто возьмется, да и смысла особого нет - большинство удовлетворено ломаным Мачем.

[PKM]

Начинаем приходить к общему знаменателю.

Если взять интервал в 1 мс - никаких всплесков не останется.

Не уверен.

Так тут, вроде бы про планирование скоростей и ускорений ни слова не было. Допустимая скорость движения по этой кривой рассчитывалась где-то раньше.

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

Так же и говорят - если двигаться по траектории в том виде, как она сохранена в УП - придется ступенчато изменять скорость, это приведет к сильным всплескам ускорения в вершинах траектории, что плохо,
поэтому KMotionCNC достраивает в углах такой траектории скругления и это сильно снижает всплески ускорения.

Правильно! Но принцип к сожалению не меняется - были выбросы до сглаживания, остались после сглаживания, только меньшие.

Знаю только что при движении по окружности состоящей из линейных сегментов скорость очень близка к теоретически допустимой рассчитанной на основе центростремительного ускорения.
Это я проверял

Похоже что планировщик расчитывает среднюю скорость исходя из допустимого ускорения по осям, но выбросы эти игнорирует. Согласен? Ведь даже в сглаженной траектории есть выбросы, так?
Хотя теоретически при бесконечно мелком разбиении их быть не должно, но зачем тогда еще приплетать ФНЧ??? А затем же, зачем и степмастер сделан... устранить рывки и повысить плавность работы станка, чтобы можно было поднять допустимые ускорения Выходит, без ФНЧ задача сглаживания Кфлопом полностью не решается, так? А в линуксе спокойно решается с заданной точностью, там выбросов ускорения вообще нет.

Не хотелось бы раздирать станок. Я им все же иногда пользуюсь.
Да и отправлять далеко - ты, вроде бы из Украины?

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

Вот это делает LinuxCNC - строит по отрезкам дуговую траекторию и проходит ее.
Правда что ли? Где ты такое узнал?

Выбросов быть не должно С чего ты так решил? Скругления, насколько я понимаю - это не дуга, а парабола, или гипербола, или еще что-то подобное.

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

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

Именно. Как он делает это и при сглаживании кусочных кривых.

Ну так возьми квадрат, как в той статье со скруглением радиусом в 1 дюйм, и разбиением на сегменты с изменением угла в 3°,
задай такие же настройки, и посмотри, что будет.

Попробую сделать

[shalek]

Уважаемые! Ничего, что вклиниваюсь? А нам что делать?

Студент готовится к экзамену. Товарищ спрашивает его: почему сопромат вверх ногами читаешь. А какая нафик разница - отвечает студент ему.

[PKM]

Снова-таки - я не говорю, что Кфлоп не работает. Но он решает задачу сглаживания лобовым методом, некрасиво и неправильно. Хотя это решение вполне сойдет для большинства станков.
Но все-таки раз существует степмастер, актуальность правильного качественного сглаживания траектории в ЧПУ доказывать никому не нужно

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

Кто знает, такой ли это большой недостаток например в 10-летней перспективе.
Все переходят на АРМ, а там сплошной линукс-андроид, даже винда совсем не так что на десктопе...