EMC2 гравировка CO2 лазером

[Nick]

Задача

Управление лазерной резкой при помощи EMC2 выполняется достаточно просто. Также мы можем гравировать контуры без особых усилий - эта та же резка но на более большой скорости, или с более маленькой мощностью. Но если мы хотим не разрезать, а гравировать растровый рисунок возникает проблема, как управлять мощностью лазера на большой скорости?
К сожалению, методы с управлением через M62/M63, через скорость шпинделя или включение/выключение вспомогательных устройств не работает, т.к. перед переключением этих режимов станок останавливается до 0. И скорость обработки падает.

Как управлять лазером, возьмем простой вариант - пин шим, который задает мощность лазера в текущий момент.

Вот пример гравировки:
https://www.youtube.com/watch?v=dT5m0YdxhjM

Варианты решения

Одним из вариантов называли добавление координаты z, с оочень большим ускорением и не большим перемещением, выход этой координаты подаем на pwm с необходимым коэффициентом.
Плюсы: просто, не нужно ничего дополнительного писать.
Минусы: может притормаживать на резких изменениях интенсивности, длинный Gкод. Никак не отследить скорость перемещения на краях рисунка.

Второй вариант, можно написать компонент, который бы контролировал мощность лазера. Но основной проблемой такого компонента является чтение громадной картинки в реальном времени. Как вариант можно попробовать реализовать такой компонент через streamer, читаем из файла строку, одно значение на шаг, потом вешаем компонент на, base-thread который отслеживает перемещение по оси x и выставляет необходимое значение.
Плюсы: точно не будет остановок. Gкод будет коротким - просто n строчек для прохода змейкой по картинке. Есть возможность отслеживать текущую скорость и в соответствии с ней выставлять необходимую мощность.
Минусы: нужно писать компонент и специальным образом готовить файл (нужно написать спец препроцессор для графических файлов).

На linuxcnc была коротенькая тема по гравировке, но ничего дельного они там не решили, писали, что кто-то сделал, вроде по первому пути, но решения я не увидел. (Вот эта тема http://www.linuxcnc.org/component/optio ... g,english/ )

У кого есть какие-нибудь соображения ?

[Impartial]

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

[aftaev]

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

Прийдется дописывать прогу которая будет генерить Gcode например Инскейп.

Самое простое решение - вывод растровой графики по принципу струйного или игольчатого принтера.

Судя по платам DSP контроллеров которые для этого предназаначены не все так просто

[PKM]

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

[Nick]

Итак, раз все не против, углубим и расширим второй вариант.

Нам будет нужен halstreamer - он читает строки из входного потока (обычно файл) и записывает в FIFO буфер (у на с на матмехе это называли простым русским словом очередь ).

Потом нужен streamer - он читает значения из очереди и настраивает пин выхода на мощность лазера. Streamer нужно будет запускать и останавливать каждый раз при совершении шага (минимальном перемещении вдоль поперечной оси рисунка, считаем 1 шаг шаговика = 1 пиксель рисунка). И останавливать при смене строки рисунка. Также значение полученное от стримера нужно умножать на текущую скорость. Скорость можно получить из ddt от пина положения по горизонтальной оси.
Сразу вопросы: как запускать и останавливать стример? И надо ли это делать?

И нужна программа, которая создаст Gкод, который пройдет змейкой по всему рисунку, и файл в котором будут необходимые значения для streamer.

Еще вопросы: Как контролировать, что streamer не "сожрал" лишнего? И надо ли это делать?

Умножить два пина друг на друга можно при помощи mult2.

Судя по платам DSP контроллеров которые для этого предназаначены не все так просто

Да, забыл 3-й вариант плата DSP, но правда тут EMC2 уже не нужен, а нужны 500$ .

[psha]

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

Если объявить ось Z угловой с большим ускорением, то G1 F* не будет её учитывать и скорость будет фиксирована (настолько насколько это возможно).
А через Z можно вполне себе задавать мощность лазера.
Является ли это "тривиальной кинематикой с интерполяцией"?

[Nick]

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

[psha]

Ну так поставь ускорение и скорость на Z over 9000!!11
К тому же никто не заставляет измерять Z в единицах, можно считать её от 0 до 0.01 - пофигу.
Она же не настоящая физическая ось, посему её ускорение особо никого не волнует.

По крайней мере идея с samplerом более тухлая...

[aftaev]

Nick я за свою идею №1. Можно заняться, попробывать, лазер есть хоть и ездит 3м/мин. Проблема: я не силен в ЕМС и нужно написать своеобразный Gcode.

[Impartial]

А через Z можно вполне себе задавать мощность лазера.
Является ли это "тривиальной кинематикой с интерполяцией"?

Да, является.
По определению тривиальная потому, что все характеристики системы приводятся к кинематике одной точки - точке контакта фрезы и материала.
Какие бы характеристики не закреплялись за любой осью они будут отражаться интерполятором на все оси.
В ЕМС это происходит приблизительно так. Рассматриваем случай установок по умолчанию.
Планировщик траектории каждые 10 мс выдает грубые новые координаты, а интерполятор домысливает на основе алгоритма кубической интерполяции сплайнами промежуточные точки, причем во всех 3 плоскостях. Поэтому использование координаты Z, для изменения мощности лазера в форме Z(+-min/max)в первую очередь будет интерпретироваться как входящая координата интерполятора. Поэтому в данном случае желательно вообще отключить планировщик траектории. А это значит практически отключить ЕМС2

[aftaev]

А ежели взять и попробывать. Nick рисует Hal и Ini + Gcode. я пробую на своем лазере

[PKM]

Собственно, попробовать первый вариант можно, как-то это сработает. Он достаточно простой - никаких realtime модулей, всего лишь, скажем, доработать gcodetools. Но вряд ли стоит ожидать нормального качества.

Сразу вопросы: как запускать и останавливать стример? И надо ли это делать?

А зачем? Пусть выдает ноль на выходе вместо остановки.

[Nick]

Можно попробовать и вариант 1, раз вы так просите .
По факту нужно:
Взять стандартный 3-х осевой конфиг. На оси Z поставить большое ускорение. Из hal вообще убрать stepgen для третьей оси, вместо этого commanded position сразу запихать в feedback и выход на pwm.
+ добавить 1 pwm (можно добавить стандартное управление шпинделем и переделать его под управление лазером).

Теперь самое прикольное, ПО дополнительное не нужно, подойдет обычный image2gcode, который идет вместе с EMC2.

А зачем? Пусть выдает ноль на выходе вместо остановки.

Мф же не знаем, сколько времени уйдет на перемещение к следующей точке (и следующей строчке), а стримеру пофигу, он будет читать без остановки, в итоге картинка поплывет.

[psha]

2Nick
Надо еще ось Z сделать не линейной, а угловой. Тогда она не будет учитываться при расчете G1 F* - собственно это недавно про контактный обсуждали.

[psha]

Планировщик траектории каждые 10 мс выдает грубые новые координаты, а интерполятор домысливает на основе алгоритма кубической интерполяции сплайнами промежуточные точки, причем во всех 3 плоскостях. Поэтому использование координаты Z, для изменения мощности лазера в форме Z(+-min/max)в первую очередь будет интерпретироваться как входящая координата интерполятора. Поэтому в данном случае желательно вообще отключить планировщик траектории.

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

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

G1 F100 X0 Y0 B0
X1
X2
X2.99
X3 B0.1
X4
X4.99
X5 B0
X6

То мы получим включение лазера постепенное на участке в 0.01мм
Это плохо?

upd
Еще раз отмечу что ось используется не Z, а B. Угловая. Ссылка на описание расчета feed rate: http://www.linuxcnc.org/docs/devel/html ... :Feed-Rate

[Impartial]

То мы получим включение лазера постепенное на участке в 0.01мм
Это плохо?

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

[PKM]

2Nick
Надо еще ось Z сделать не линейной, а угловой. Тогда она не будет учитываться при расчете G1 F* - собственно это недавно про контактный обсуждали.

Странно, но на своем станке я убедился, что при одновременной интерполяции по линейным и угловым координатам параметры угловых учитываются. Да и как ты себе это представляешь? Перемещение по XY закончилось, а по В все еще доворачивает? Они синхронизированы, разумеется. all other axes (ABCUVW) move so as to start and stop in coordinated fashion

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

Во-вторых,

То мы получим включение лазера постепенное на участке в 0.01мм
Это плохо?

Это не так плохо, но на картинку 100х100 мм с постоянно изменяющейся насыщенностью могут понадобиться миллионы строк кода (даже при дискретности 1 мм по Y)

[psha]

Нет, ускоряться и замедляться не будет, собственно это я на симуляторе и проверил.
Идея в том, что бы сделать ускорение по оси управления лазером (пусть будет Z, хотя это должноа быть одна из ABC), таковым, чтоб за время перехода на включенеи/выключение он успел бы разогнаться и встать в нужное положение. Тогда скорость движения будет неизменной.
Попробуй кусок кода который я привел сунуть в 5axis симулятор (возможно, надо будет увеличить ускорение по оси B)

Количество строк кода будет большое, да. Никто и не спорит, а что делать? Так или иначе на каждый пиксель, если он у тебя отдельный, должна быть сигнализация о включении и выключении.
Здесь она разбивается на четыре строчки (x0-\epslion, 0), (x0, 1), (x1, 1), (x1+\epsilon, 0)
Разница с двумя небольшая
Более того, если рисунок векторизовать то можно буквально тем же кодом его отрисовывать нормально, а не растрово

[aftaev]

По факту нужно:
Взять стандартный 3-х осевой конфиг. На оси Z поставить большое ускорение. Из hal вообще убрать stepgen для третьей оси, вместо этого commanded position сразу запихать в feedback и выход на pwm.
+ добавить 1 pwm (можно добавить стандартное управление шпинделем и переделать его под управление лазером).

Тогда делаем так:
Я дам настройки станка с Мачем, нарисуешь HAL под мой станок. Поставлю ЕМС с твоим HAL и будем проверять теорию на практике

[psha]

Эти точки получаются с дискретностью 1 мс.

Да, будет постепенное наростание мощности лазера за какое-то расстояние. Сколько на него уложится точек временных - зависит от его длины и заданной feed rate.
Параметры "управлющей" оси надо подобрать так, чтоб они позволяли без замедления уложиться в этот промежуток. Так что как точки будут разбросаны особой разницы нет. Главное что в начале отрезка 0, в конце - нужная мощность.

А как устанавливать фокус?

Я несколько не в курсе что и как там происходит, поэтому могу пороть чушь
Разве фокус устанавливается не один раз?

Здесь же проскакивала здравая идея по поводу шага-точки. Берем картинку, например 256 градаций, и начинаем выводить по точкам (точка - шаг, значение яркости-мощность).

Идея ни разу не здравая. Для этого придется делать свой собственный планировщик траектории, что весьма геморройно
Как ты собираешься "выводить точки"? jog'ами?