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

[aftaev]

Тем более по умолчанию у них стоит 180 и единицы в дюймах. Это вообще чертзнает что тогда

Да многовато В мануале часто Units упоминаются и это какие единицы выбраны.

[shalek]

Я по Mach3 уже определился. Чем меньше ускорение поставлю, тем точнее траектория углы проходит. Медленно!

[aftaev]

Тем более по умолчанию у них стоит 180 и единицы в дюймах. Это вообще чертзнает что тогда

180 градусов, а это считай ровная линия

[PKM]

180 градусов, а это считай ровная линия

Да не градусов, а "юнитов". Там где в градусах, по умолчанию 0 стоит.

А у Кфлопа что все настройки только в дюймах?
Похоже, что LinuxCNC - единственная нормальная ЧПУ с гарантированной точностью отработки траектории, остальные Мач3 и даже частично Кфлоп - филькина грамота с непонятными настройками. Ну Мач3 вообще жесть конечно

[aftaev]

Ну Мач3 вообще жесть конечно

началось в деревне утро
Щас как появится Мач4 в 2050 году, вот он уделает LinuxCNC

[PKM]

Щас как появится Мач4 в 2050 году, вот он уделает LinuxCNC

Не уделает. Собственно, он уже появился.

А теперь важный факт: американский производитель полу-профессиональных станков Tormach перешел с Mach3 на "свою" ЧПУ PathPilot, которая оказалась... LinuxCNC с новым планировщиком и новым интерфейсом.
И стоит там карточка Mesa 5i25. А вовсе не KFLOP и не SmoothStepper.
А это означает простой факт: LinuxCNC на голову выше остальных систем по возможностям, планировщику траекторий, и плюс к этому у нее открытый исходный код. Конечно, это не Fanuc или Siemens, но у Tormach весь станок стоит дешевле фирменной ЧПУ .

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

[michael-yurov]

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

Тесты применительно к Mach3 я провел плохо! Оказалось, что скорость прохождения траектории сильно зависит от конкретного компьютера. Может быть причина в том, что я забыл переключиться с дюймов на миллиметры. Может быть в том, что не был установлен драйвер LPT.
Что самое странное - время прохождения траектории сильно зависит от настройки моторов (от количества импульсов на миллиметр).
Я пробовал проводить те же тесты на компьютере станка, и там почему-то получилось время прохождения более близкое к оптимальному (хотя по прежнему сильно его превышающее).
Те подтормаживания в местах стыковки дуг и соседними сегментами заметны визуально при работе станка, так что планировщик реально "тормозит", но в цифрах это измерить сложно.

В LinuxCNC точность задается командой G64 Px Qy, где x - максимальное отклонение от траектории при сглаживании, у - максимальное отклонение от прямой, при котором соседние отрезки проходятся как один.
А вот что значит в Mach3 CV Dist Tolerance 4 units? 4 мм? 4 шага моторов?

В Mach3 в нашем случае величина задается именно в миллиметрах, но!, это не отклонение от вершины, как в случае LinuxCNC, а это расстояние не доходя по траектории до вершины откуда Mach3 начинает строить скругление (парабола это, или что я точно не знаю).
Если задано ограничение угла в 20°, то отклонение составит около 0,17 мм, или меньше.

В их тестах Мач3 тоже нарушал ограничения по ускорениям.

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

Еще вопрос, результаты по системам ЧПУ получены на отрезках или дугах? Хорошо было бы привести по 2 цифры

И то и другое проверял.
С отрезками у Mach3 существенно лучше, чем с дугами.
Однако с дугами он показывает лучшую точность при неправильных настройках планировщика (те, что по умолчанию - ни в 3.1415 ни в Красную армию).

И еще вопрос, выполнение программы засекалось от 0.0 или "стартовая точка - в начале траектории в координатах X84 Y-122"

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

Да еще и Collinear Tolerance - 0.0005 дюйма, Corner Tolerance - 0.03 (тоже дюйма?)

Да, все в дюймах. Collinear Tolerance - не должен влиять на результат вообще.

Corner Tolerance - 0.03 - довольно большое значение, однако стоит заметить, что "скругление" выполнялось лишь там, где было незначительное изменение угла, и KMotionCNC скругляет траекторию не дальше середин стыкующихся отрезков.
Т.е. в реальности такого большого отклонения нигде не было. А там где скругление выполнялось - оно, в общем-то было нужно для восстановления более плавной траектории из линейных сегментов.

И да, Миша, мне кажется что сильно очень зажат CV в маче для этих тестов... от 20 градусов - это вообще считай отключить его. Я бы ориентировался хотя бы на 90.

Да, зажат.
Но для качественных точных траекторий, мне кажется это вполне допустимо.
Там где плавная кривая (например окружность) будет построена из линейных сегментов - изменение угла в вершинах будет не таким уж и большим. 20° - это если разбить окружность на 18 линейных сегментов. Полагаю, можно и не экономить строки УП так сильно.

А если в УП сохранен угол - я не понимаю, почему бы системе ЧПУ не пройти его точно, с остановкой в вершине. Если сказано, что нужно сделать угол - так нужно его и сделать.
Ну, например, мы вырезаем шестигранное отверстие - вполне логично, что нужно вырезать внутренние углы как можно острее. А если мы вырезаем шестигранник снаружи - то CAM программа построит скругление равное диаметру фрезы обходя углы шестигранное фигуры, и двигаясь по такой траектории можно будет не останавливаться.

4мм - это не для ЧПУ точность

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

"Продолжение следует."

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

Попробовал сравнить старый и новый планировщики LinuxCNC

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

G1 (line)
            старый     новый
G64         5м36       2м32с
G64 P1.	  3м24с      2м39с	
G64 P0.1	 4м52с      3м03с
G64 P0.01	6м46с      3м12с
G61         7м09с      7м09с

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

G1/G2/G3 (arc)
            старый     новый
G64         3м10с      2м43
G64 P1.     3м24с      2м45
G64 P0.1    4м36с      3м25с
G64 P0.01   5м07с      3м39с
G61         4м52с      4м09с

G64 без параметра - режим "постоянной скорости", когда программа заботится о более-менее постоянной скорости движения, не обращая внимания на точность следования и безбожно скругляя углы.
G64 Pxx - заданная точность следования по траектории. Отклонение не может превышать xx миллиметров.
G61 - режим точного прохождения.

[aftaev]

Не уделает. Собственно, он уже появился.

он еще не появился, будут доделывать Мач до 2050

но у Tormach весь станок стоит дешевле фирменной ЧПУ .

гложут сомнения. Tormach стоит почти в 2 раза дороже пром. стойки

[PKM]

А если в УП сохранен угол - я не понимаю, почему бы системе ЧПУ не пройти его точно, с остановкой в вершине. Если сказано, что нужно сделать угол - так нужно его и сделать.
Ну, например, мы вырезаем шестигранное отверстие - вполне логично, что нужно вырезать внутренние углы как можно острее. А если мы вырезаем шестигранник снаружи - то CAM программа построит скругление равное диаметру фрезы обходя углы шестигранное фигуры, и двигаясь по такой траектории можно будет не останавливаться.

А зачем его точно проходить? В большинстве случаев не будет заметно, если срезать на 0.01-0.02мм. Ведь все равно мы не получим острого угла, т.к. диаметр инструмента намного больше!
Зато потери времени на полное торможение гигантские.

[PKM]

гложут сомнения. Tormach стоит почти в 2 раза дороже пром. стойки

Пусть так. Все равно им не выгодно увеличивать стоимость станка в 1.5 раза за счет ЧПУ.

[michael-yurov]

Я по Mach3 уже определился. Чем меньше ускорение поставлю, тем точнее траектория углы проходит. Медленно!

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

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

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

Тем более по умолчанию у них стоит 180 и единицы в дюймах. Это вообще чертзнает что тогда

180 градусов, а это считай ровная линия

По умолчанию там так:

2015-03-09 16-32-19 Скриншот экрана.png (1.78 КБ) 5605 просмотров

Это, конечно, полный бред!
Это именно 180 мм (или дюймов для тех у кого имперская система единиц).
А ограничение для угла - вообще отключено (галочка снята).

Plasma Mode - устаревшая настройка. Ее рекомендуется НЕ включать.
Про G100 ничего не знаю, но, полагаю, к нашим вопросам особого отношения не имеет.

Есть предположение, что разработчик, использовав исходники планировщика EMC2 толком сам не понял, что это за параметры и как их правильнее настроить, и задал по умолчанию такие значения, при которых Mac3 показывал бы наилучшие результаты по времени.

А у Кфлопа что все настройки только в дюймах?

Да. В дюймах.

Похоже, что LinuxCNC - единственная нормальная ЧПУ с гарантированной точностью отработки траектории, остальные Мач3 и даже частично Кфлоп - филькина грамота с непонятными настройками. Ну Мач3 вообще жесть конечно

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

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

Нельзя говорить, что он "серьезно" нарушает пределы ускорений. На самом деле показанные всплески возникают из за того, что дуговые сегменты разбиваются на мелкие линейные кусочки (по умолчанию - окружность на 360 кусочков). Естественно, на стыках в моменты смены скорости получается бесконечно большое ускорение. KFlop позволяет устранить этот эффект используя постобработку сигнала (принцип аналогичен тому, что делает StepMaster). Графики показаны такими лишь для наглядности.
Полагаю, LinuxCNC выступает не лучше - он же изменяет выходную частоту тоже не плавно, а с интервалом в 1 мсек, и в моменты изменения частоты так же возникает бесконечно большое ускорение, и на мелких окружностях (например, при трохоидальной обработке) получается не так уж много этих изменений, и шаг получается достаточно грубым (скорее всего многократно грубее, чем у KMotionCNC), так что здесь я бы хотел встать опять на сторону KFlop.

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

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

он же изменяет выходную частоту тоже не плавно, а с интервалом в 1 мсек

А вот "почувствует" ли механика эту дискретность изменения частоты? Пример с ДВС и автомобилем - он как раз про это.
"Ступеньки" частоты по 1 мсек - они получаются очень маленькие. Инертная масса подвижных частей сгладит их до практической незаметности.
Вообще, когда мы используем понятие "бесконечно большое ускорение частоты", мы должны оперировать термином "мгновенное значение" этой частоты. А при существующих способах формирования сигнала шага, когда берется несущая частота порядка нескольких десятков килогерц и из нее тупо вырезаются "лишние" импульсы, с тем, чтобы получить нужную (в среднем), мгновенное значение частоты теряет смысл.
Снявши голову, по волосам не плачут

[PKM]

Нельзя говорить, что он "серьезно" нарушает пределы ускорений. На самом деле показанные всплески возникают из за того, что дуговые сегменты разбиваются на мелкие линейные кусочки (по умолчанию - окружность на 360 кусочков). Естественно, на стыках в моменты смены скорости получается бесконечно большое ускорение. KFlop позволяет устранить этот эффект используя постобработку сигнала (принцип аналогичен тому, что делает StepMaster). Графики показаны такими лишь для наглядности.

Я полагаю, что заданное ускорение примерно 30-50 in/s2. А выбросы достигают 150-300in/s2.
И показанные графики отображают именно ускорение. Изменение скорости за сервопериод, что это еще?
А LPF в KFLOP - всего лишь корявый способ сгладить детские недостатки планировщика. В LinuxCNC ФНЧ можно поставить элементарно, но в этом нет необходимости.

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

В том-то и дело, что за 1мс в LinuxCNC НЕТ бесконечно большой смены скорости. Там планировщик работает БЕЗ недопустимых выбросов ускорения. Это серьезное ЧПУ, есть все графики.

шаг получается достаточно грубым (скорее всего многократно грубее, чем у KMotionCNC), так что здесь я бы хотел встать опять на сторону KFlop

Это не совсем так. В LinuxCNC применяется круговая интерполяция ARC_BLENDING, а вот именно KFLOP бьет на отрезки, на стыках которых и возникают всплески ускорения! Конечно, чем мельче отрезки, тем мельче всплески. А в LinuxCNC выбросов ускорения вообще нет.
Так что планировщик KFLOP здесь проигрывает полностью.

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

[michael-yurov]

А если в УП сохранен угол - я не понимаю, почему бы системе ЧПУ не пройти его точно, с остановкой в вершине. Если сказано, что нужно сделать угол - так нужно его и сделать.
Ну, например, мы вырезаем шестигранное отверстие - вполне логично, что нужно вырезать внутренние углы как можно острее. А если мы вырезаем шестигранник снаружи - то CAM программа построит скругление равное диаметру фрезы обходя углы шестигранное фигуры, и двигаясь по такой траектории можно будет не останавливаться.

А зачем его точно проходить? В большинстве случаев не будет заметно, если срезать на 0.01-0.02мм. Ведь все равно мы не получим острого угла, т.к. диаметр инструмента намного больше!
Зато потери времени на полное торможение гигантские.

Все же это не честно как-то - экномить время за счет качества обработки.
Да, конечно, 0,01 - 0,02 мм не заметно при диаметре фрезы более миллиметра.

А сколько было камней в мой огород, когда речь шла о том, что StepMaster в среднем режиме фильтрации срезает угол чуть больше, чем на 0,001 мм!
И при этом никого не волновало, что Mach3 может срезать на 180 мм!
В этом плане огромное спасибо shalek за реальное сравнение в качестве обработки: http://www.cnc-club.ru/forum/viewtopic. ... 40#p178312

И на счет счет "гигантских" потерь времени - тоже не соглашусь!

Возьмем, например, шестигранное отверстие диаметром 10 мм, и фрезу диаметром 1 мм.
Скорость для такой фрезы с обычным шпинедлем на 24 000 об/мин не может превышать 1000 мм/мини.
Ускорения тоже возьму типовые - 500 мм/сек².
...
Блин, арткам не установлен! Допишу чуть позже.

[PKM]

А сколько было камней в мой огород, когда речь шла о том, что StepMaster в среднем режиме фильтрации срезает угол чуть больше, чем на 0,001 мм!

Надо было их ткнуть носом в LPF из KMotionCNC

[PKM]

Все же это не честно как-то - экномить время за счет качества обработки.

На черновых проходах, да еще когда САМ выдает программу из миллиона мелких кусочков - только и надо экономить!
А на чистовых проходах уже смотреть, насколько эта сотка или микрон влияют на точность. У народа ШВП максимум С5, а всем микроны подавай!

Возьмем, например, шестигранное отверстие диаметром 10 мм, и фрезу диаметром 1 мм.
Скорость для такой фрезы с обычным шпинедлем на 24 000 об/мин не может превышать 1000 мм/мини.
Ускорения тоже возьму типовые - 500 мм/сек².

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

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

А сколько было камней в мой огород, когда речь шла о том, что StepMaster в среднем режиме фильтрации срезает угол чуть больше, чем на 0,001 мм!

Синдром принцессы на горошине
Где взять такую механику, чтобы она этот микрон заметила? Да еще на тех скоростях, когда сия ошибка проявляется (насколько помню - тысячи мм/мин).
Замечу, что фреза тоже "дискретна". При 1000 мм/мин и 24000 об/мин подача на зуб для двухзаходной фрезы 0,021 мм. То есть срезаются вот такие стружки. И после этого говорить про микроны?

[michael-yurov]

Я полагаю, что заданное ускорение примерно 30-50 in/s2. А выбросы достигают 150-300in/s2.

Это всего лишь график для наглядного объяснения происходящего.
В реальности в момент ступенчатого изменения скорости возникает возникает всплеск ускорение бесконечно большой величины. Но нельзя на это смотреть только с точки зрения математики. Если так рассуждать - то у нас с каждым импульсом Step возникает бесконечно большое ускорение (UAVpilot, кстати, этим сильно недоволен).

И показанные графики отображают именно ускорение. Изменение скорости за сервопериод, что это еще?

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

А LPF в KFLOP - всего лишь корявый способ сгладить детские недостатки планировщика.

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

В LinuxCNC ФНЧ можно поставить элементарно, но в этом нет необходимости.

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

В том-то и дело, что за 1мс в LinuxCNC НЕТ бесконечно большой смены скорости.

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

В LinuxCNC применяется круговая интерполяция ARC_BLENDING, а вот именно KFLOP бьет на отрезки, на стыках которых и возникают всплески ускорения!

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

Надо было их ткнуть носом в LPF из KMotionCNC

Точно нарываешься!

На черновых проходах, да еще когда САМ выдает программу из миллиона мелких кусочков - только и надо экономить!

А там и экономить нечего - если CAM система рассчитывает траекторию с плавными переходами - там просто нечего скруглять и не на чем экономить.

[michael-yurov]

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

Если речь про обработку рельефов из дерева и про "грубую" траекторию - там, действительно лучше поставить угол побольше.
Я сейчас рекомендую такие параметры, как на втором скрине (2 мм и 35°): http://www.cnc-club.ru/forum/viewtopic. ... 558#p52196
(И это для качественных траекторий. Для грубых - можно еще увеличить значение угла).