cnc-club.ru

Смотри, слишком большие значения при равных требованиях к качеству и конкретной УП не дают заметных улучшений по скорости работы, то же и при слишком маленьких значениях, их изменение не сильно ускорит выполнение работы.
Перебирая значения и запуская УП, естественно "по воздуху", тебе надо найти промежуточный между этими двумя крайними областями участок.
Ну а там на этом участке и подбираешь нужный тебе баланс.
Для моих настроек существенный прирост скорости работы при приемлемой точности заканчивался на 0.03, это значение я и ставил.

; Arc Centre Cordinates
FORMAT = [I|@|I|1.3]
FORMAT = [J|@|J|1.3]

FIRST_CW_ARC_MOVE = "G2[X][Y][J][F]"
CW_ARC_MOVE = "G2[X][Y][J]"
;
FIRST_CCW_ARC_MOVE = "G3[X][Y][J][F]"
CCW_ARC_MOVE = "G3[X][Y][J]"
можно попробовать убрать из постпроцессора эти строчки
чтоб он генерировал только линейные участки
в место дуг будут короткие линейные отрезки

Да в том и дело, что мне надо дуги маленьких радиусов, а у меня получаются короткие отрезки (дуга ломанная из отрезков)

а точность в арткаме какая стоит?

в арткаме точность 0.3
Если сделать точность больше, то УП вообще не открывается.
Вот пример УП где дуги становятся ломаными линиями.

WWW116 писал(а):в арткаме точность 0.3

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

П.С. На всякий случай вопрос, какая точность с твоей точки зрения больше, 1.0 или 0.0001?

LinuxCNC жалуется на строки в которых встречаются маленькие радиусы.
С моей точки зрения точность больше 0.0001 чем 0.1

WWW116 писал(а):С моей точки зрения точность больше 0.0001 чем 0.1

Правильно считаешь, всегда 0.0001 и ставь и приведи в соответствие с этим свой постпроцессор:

; Tool moves in x,y and z
FORMAT = [X|#|X|1.4]
FORMAT = [Y|#|Y|1.4]
FORMAT = [Z|#|Z|1.4]
; Arc Centre Cordinates
FORMAT = [I|@|I|1.8]
FORMAT = [J|@|J|1.8]


START = "M3[S]"
; Эти оболтусы собираются не разогнанным шпинделем материал резать, по этому надо добавить паузу.
START = "G04 P12"
START = "G64P0.03Q0.03"
START = "G0[ZH]"
START = "G0[XH][YH]"

WWW116 писал(а):LinuxCNC жалуется на строки в которых встречаются маленькие радиусы.

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

Эти оболтусы собираются не разогнанным шпинделем материал резать, по этому надо добавить паузу.
START = "G04 P12"
Мне пауза не нужна для разгона шпинделя, поэтому её там нет.
Шпиндель включаю в ручную, жду разгона и потом в "путь" -пилить, крошить.

torvn77 писал(а):Если бы ты внимательно изучал тему, то в пятом посту увидел шпаргалку по параметрам постпроцессора и если бы должным образом относился к изучению своего инструмента,
то посмотрел бы её чтобы знать что постпроцессор в принципе может и какие есть настройки его работы.

Согласен, каюсь. Обязательно на досуге почитаю. Самому интересно и полезно!

torvn77 писал(а):; Эти оболтусы собираются не разогнанным шпинделем материал резать, по этому надо добавить паузу.

Не надо паузу - в LinuxCNC есть штатные средства ожидания разгона шпинделя.

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

Вот так выдает стандартный пост:

M03
G00 Y 0.0000
G00 X 20.0000
G00 Z 10.0000
G00 A 0.0000
G00 A -0.0072 X 0.0010 Z 10.0000
G01 Z 8.9999 F250.0
G01 X 0.0040 Z 9.0000 F350.0
G01 X 2.9979
G01 X 3.0010 Z 8.9999
G01 A -0.0265
G01 A -0.1640 Z 8.9997
G01 X 2.9980
G01 X 1.6745 Z 8.9998
G01 X 0.2467
G01 X 0.0041
G01 X 0.0010 Z 8.9997
G01 A -0.1841
G01 A -0.3216 Z 8.9995

А нужно чтоб было так

M03
G00 Y 0.0000
G00 X 20.0000
G00 Z 20.0000
G00 A 0.0000
G00 A -0.0072 X 0.0010 Z 20.0000
G01 Z 16.9999 F250.0
G01 X 0.0040 Z 18.0000 F350.0
G01 X 2.9979
G01 X 3.0010 Z 17.9998
G01 A -0.0265
G01 A -0.1640 Z 17.9994
G01 X 2.9980
G01 X 1.6745 Z 17.9996
G01 X 0.2467
G01 X 0.0041
G01 X 0.0010 Z 17.9994
G01 A -0.1841
G01 A -0.3216 Z 17.999

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

torvn77, спасибо что откликнулись

Если в ArtCam делать обработку по кругу, ну например кольца, то в УП мы увидим что координата Z берет значения от нулевой плоскости. Например если диаметр обрабатываемой поверхности равен 50мм, то координата Z будет равна 25мм. Т.е. ArtCam использует радиус! А мне для станка радиус не подходит - мне нужна обработка по диаметру, так как это реализовано во многих токарно фрезерных станках.
Как заменить знаки и изменить оси - я справился, а вот как значение R умножить на два не знаю. Возможно я туплю) и есть настройка в программе где ArtCam будет брать данные диаметра, но таких настроек не нашел.

Aleksandr_999 писал(а): Т.е. ArtCam использует радиус!

Artcam использует нечто вроде "карты высот" и понятия фигуры в нём нет.
Это в других, более сложных программах.

Так у меня есть шансы?

Aleksandr_999, сначала объясни, что ты хочешь сделать, пока я не понимаю, как ты хочешь сделать, что и зачем.
Ты хочешь кольцо отфрезеровать?

Aleksandr_999 писал(а):Так у меня есть шансы?

Если не хотите переписывать LinuxCNC, то нет.

UAVpilot писал(а):Если не хотите переписывать LinuxCNC, то нет.

Это ему не потребуется, в самом сложном случае напишет специальный постпроцессор или процедуру на G-Code.Но сначала надо понять, что он хочет сделать и почему его фрезеровка с переворотом не устраивает(ну раз его волнует диаметр не по ХУ, а по Z)

torvn77 писал(а):FORMAT = [X|#|X|1.4]

Если мы используем G64P0.03, то эта точность не избыточна?

Вопрос: если поставить точность FORMAT = [X|#|X|1.3], как это повлияет на производительность станка?

1240 писал(а):Вопрос: если поставить точность FORMAT = [X|#|X|1.3], как это повлияет на производительность станка?

Более точная траектория всегда более медленная.

У меня вот какое соображение, низкая точность в Арткаме не означает того, что в траектории не будет резких поворотов при прохождении которорых будет падать скорость.
Это означает только то, что траетория им будет создаваться с помощью более крупных участков, что действительно уменьшает время её прохождения.
Но при этом нет гарантии, что она будет сглажена оптимально, плюс коды G02/G03 могут создаваться с заведомо неправильными координатами.
По этому лично я подумал поступить иначе, траектория в арткаме создаётся с максимальной точностью, какая не приводит к длительным вычислениям,
а упрощение траектории делает уже планировщик движений ЧПУ по сделанным в G64 настройкам и результат применения к избыточно точной траектории G64P0.03 меня вполне устроил, мог бы сделать и ещё менее точно, но в моём конкретном случае значимого уменьшения времени обработки от дальнейшего снижения точности не происходит.