Laser engraver m67

More
25 Aug 2018 17:33 #116577 by Hakan
Replied by Hakan on topic Laser engraver m67
I tried the following on my router and watched the intensity signal.
It seems to work, and if you like you can try it. It is worthwhile testing.

Insert the following in the hal file.
Disconnect the output from motion.analog-out-00
Connect the target of motion.analog-out-00 to the signal intensity-velocity-compensated (some pwm?)
# Laser intensity velocity-controled

loadrt ddt count=2
loadrt hypot
loadrt scale
loadrt mult2

addf ddt.0   servo-thread
addf ddt.1   servo-thread
addf hypot.0 servo-thread
addf scale.0 servo-thread
addf mult2.0 servo-thread

setp hypot.0.in2    0.0          # Don't use Z
setp mult2.0.in1    0.03333333   # 1/F1800 in 1/(mm/sec)
setp scale.0.offset 0.0

net x-pos-fb                       => ddt.0.in
net y-pos-fb                       => ddt.1.in
net Xvel                           <= ddt.0.out            => hypot.0.in0
net Yvel                           <= ddt.1.out            => hypot.0.in1
net current-velocity               <= hypot.0.out          => mult2.0.in0
net relative-velocity              <= mult2.0.out          => scale.0.gain
net intensity                      <= motion.analog-out-00 => scale.0.in
net velocity-compensated-intensity <= scale.0.out => # Insert pwm device here

#

The reference speed is F1800 (from the ngc file). I don't know how to get it from
the actual running G-code and there is the issue if potential division by zero.
Solvable I guess.

See how it perform. You should see an improvement at speed changes/direction changes.
Ideally though, this should run at 100 kHz, not 1 kHz, but that could be a future step.

Please Log in or Create an account to join the conversation.

More
25 Aug 2018 18:39 #116578 by PCW
Replied by PCW on topic Laser engraver m67
You can simplify this a bit by using motions commanded velocity pins so the ddt comp is not required

Please Log in or Create an account to join the conversation.

More
25 Aug 2018 20:59 #116581 by Kaspret
Replied by Kaspret on topic Laser engraver m67
I think I already found the main issue, problems cause X axis due to a defected bearing which causes little jamming at hight acceleration.
I tried to modify gcode and change with places X and Y values so all main movements made by Y axis. Adding engraved photo, results are much better.

File Attachment:

File Name: custom.hal
File Size:0 KB

File Attachment:

File Name: Burn.hal
File Size:4 KB


drive.google.com/open?id=1Qw-4rOg3qtbEb8u2xBB7uAKjpqv-Qv5a
the image is mirrored because I didn't changed -/+ values from X and Y

Did you do some intensity-gradient in the picture? Or is that a result of laserweb4?

Its been done by laserweb4, my only touch in gcode is changing S values with M67

Adding my hal and custom hal
Attachments:

Please Log in or Create an account to join the conversation.

More
25 Aug 2018 21:09 #116582 by tommylight
Replied by tommylight on topic Laser engraver m67
As Tod mentioned early in this thread, this is an acceleration issue, namely acceleration is set to low. Lasers require an acceleration of over 3000mm/s/s otherwise the result is what you posted at the beginning.

Please Log in or Create an account to join the conversation.

More
25 Aug 2018 21:12 #116583 by Kaspret
Replied by Kaspret on topic Laser engraver m67
At moment acceleration is 900mm/s/s

Please Log in or Create an account to join the conversation.

More
25 Aug 2018 21:20 #116584 by rodw
Replied by rodw on topic Laser engraver m67
I think the other thing is biting on a short segment is that the trajectory planner will reduce the commanded velocity to what can physically be achieved. so you might command 1000 mm/sec speed but LinuxCNC might only command a maximum of 200 mm/sec so you never get to the speed you asked for. As said earlier, you need a leadin and leadout that allows the machine to get up to speed either side of your image.

You've got this far so I would look at how you can fine tune your gcode generation.
The following user(s) said Thank You: Kaspret

Please Log in or Create an account to join the conversation.

More
25 Aug 2018 22:22 #116585 by Hakan
Replied by Hakan on topic Laser engraver m67
Kaspret, here, save away your current custom.hal and use the code below as your custom.hal.
I am pretty sure it will make a difference.
loadrt pwmgen output_type=0
addf pwmgen.update servo-thread
addf pwmgen.make-pulses base-thread

setp pwmgen.0.enable TRUE

# net analogout motion.analog-out-00 => pwmgen.0.value
# This line was replaced by below

# Laser intensity velocity-controled

loadrt ddt count=2
loadrt hypot
loadrt scale
loadrt mult2

addf ddt.0   servo-thread
addf ddt.1   servo-thread
addf hypot.0 servo-thread
addf scale.0 servo-thread
addf mult2.0 servo-thread

setp hypot.0.in2    0.0          # Don't use Z
setp mult2.0.in1    0.03333333   # 1/F1800 in 1/(mm/sec)
setp scale.0.offset 0.0

net x-pos-fb          => ddt.0.in
net y-pos-fb          => ddt.1.in
net Xvel              <= ddt.0.out            => hypot.0.in0
net Yvel              <= ddt.1.out            => hypot.0.in1
net current-velocity  <= hypot.0.out          => mult2.0.in0
net relative-velocity <= mult2.0.out          => scale.0.gain
net intensity         <= motion.analog-out-00 => scale.0.in
net analogout         <= scale.0.out          => pwmgen.0.value

net laserpwm pwmgen.0.pwm => parport.0.pin-01-out

PCW, I understand what you write, but can't find the pin you refer to. Can you please be explicit?

Cranking up the acceleration helps, but there are limits to what belts/screws and motors can do. Also that pesky Newton comes with F = ma.

I implemented laser engraving in Marlin, the 3D-printer firmware. The intensity there is recalculate at every motor step, so the step generation is driving it. Typically at 50-200 steps/mm. This put requirements on the pwm frequency and how it is set. I was working with a step frequency at 100 kHz and speeds up to 30 m/min at 300 dpi. Then it doesn't matter how fast acceleration there is, it will never be fast enough. The black lines at direction change were always there, always visible to the eye. There could also be other external things, like G-code starvation, so the speed could get reduced a bit unforeseen. By doing the intensity-calculation to follow the speed, there were always perfect engraving results. I made tests with ridiculously low acceleration, high accelerations, G-code starvation, and more. Always perfect results. This is also how smoothieware does it. At least then, this was maybe three years ago.

So what I have done here in the hal file is something in that direction. There will be a difference in engraving results, I am sure. But a real, super-cool leaser engraving module in linuxcnc should be run at the 100 kHz level, maybe driven by the stepper generation.
The following user(s) said Thank You: Kaspret

Please Log in or Create an account to join the conversation.

More
25 Aug 2018 23:00 #116587 by Kaspret
Replied by Kaspret on topic Laser engraver m67
Thanks Hakan,
I will give it a try after a few hours and post results.

Please Log in or Create an account to join the conversation.

More
26 Aug 2018 06:37 - 26 Aug 2018 06:38 #116595 by tommylight
Replied by tommylight on topic Laser engraver m67

At moment acceleration is 900mm/s/s

That will not do for a laser engraver as it will slow down to much near the end of the move and ramp up slowly when moving at the opposite direction, therefore ending with to much burn at the direction reversal.
I use accelerations of 700 to 1500mm/s/s on plasma cutters, just so you get an idea how slow that acceleration is.
BTW, on the last CO2 laser i worked on, i had it set at 10000 as it had big motors and it could manage that easily.
Last edit: 26 Aug 2018 06:38 by tommylight. Reason: More info

Please Log in or Create an account to join the conversation.

More
26 Aug 2018 11:00 #116599 by Hakan
Replied by Hakan on topic Laser engraver m67
With the hal code above it is actually better to have a low acceleration.
The 1 kHz update frequency is a bit slow and will introduce a slight
error in velocity, I mean it is not constant during 1 ms when accelerating,
that is the error one can expect.

If my math is correct, it takes 33 ms to go from full speed to zero v/a=(1800/60)/900.
During that time the head travels 0.5 mm (0.5 a t^2 = 0.5 * 900 * 0.033^2) so that is 5 dots at 0.1mm dot size.
Having 33 intensity changes during 0.5 mm, well I think it should be ok. It is also a matter that pwm will keep up to that change rate.

Please Log in or Create an account to join the conversation.

Moderators: snowgoer540
Time to create page: 0.120 seconds
Powered by Kunena Forum