Ghosting laser while rastering

jay_s_uk

@Arcnsparks tbh I've gone back to grbl for the moment. Too many other projects and the Mrs wanted some stuff cutting

Arcnsparks

@jay_s_uk Definitely understand that!

paulg4h

@jay_s_uk said in Ghosting laser while rastering:

moment. Too many other projects and the Mrs wanted some stuff cutting

Hello Jay,

as you know I run my K40 with RRF now and use Estlcam as CAM, to set it up I watched some videos where the guy told how to setup Eslcam and there he show do not switch of the Laser, just set the power to 0 in Cam

on cut start GCode:

M03 S<s>

on cut end:

M03 S0

Maybe this would help in your case too?

paulg4h

@dc42 now I try a lot to get usable raster engraving with RRF 3.3 connected to the bed mos fet of an SKR 1.4T board

Here are my config.g snipped:

;############## Laser Settings #########################
M452 C"bed" R255 S1 F100 ; laser uses bed pin,  PWM frequency 100Hz

I use Lightburn to create the Gcode with this settings:

Here you can see the same gcode with different laser frequency settings:

I also try to change the M05 in GCode by search and Replace with M03 S0 but no change.

What can I do get the quality of letters as shown with 100 and the area engraving quality like 500hz?

paulg4h

I get the Information that the SKR 1.4T board with his LPC chip do not have a hardware PWM just Software PWM which can not handle more than a few hundred Hz, so I changed the 1.4 by an SKR 2 with n STM chip and now I can run the laser with 500 hz and get this quality when I connect the laser to the bed mos fet which is also software driven:

After reducing the Laser power in Lightburn it looks like:

After changing the laser connection from bed mos fet to the e1heat mos fet which is hardware PWM driven I was able to revert the laser settings to 5kHz and got this result after reducing the laser power again:

This are my Lightburn settings for the result above:

paulg4h

Today I get an test firmware for my BigtreeTech SKR 2 board to improve the raster engraving quality and speed dramatically!

This is on trotec laser "plastic" aluminium / black 1.6mm

The 500mm/s made with the test firmware and the others below with the stock firmware https://github.com/gloomyandy/RepRapFirmware/releases/tag/v3.4.0beta5_1

With default firmware and 150mm/s on an 70 x 23 mm size work sheet I do get such results:

(each vertical line of the ruler is 0.5mm)

this are the lightburn settings for that:

with the test firmware and at the speed of 500mm/s and changing from LINE+FILL to FILL only as increasing the laser power I get this now:

Here are the lightburn setting for that:

So hopefully this major improvement made by @gloomyandy will be available in the future to the RRF release at least when it is in laser mode!

paulg4h

I now also do an engraving test with an picture I found in Internet, the speed limit for the SKR 2 so far seams to be 250mm/s, at 300mm/s the head stops in the middle of an move and at more than that it either lost his reference and hit in my case the right machine limits.

The first 10mm of engraving works as expected even at 500mm/s but then it stops, so this seams for me some sort of CPU power / cache / code issue.

Maybe @dc42 there is some chance to cleanup / improve the code for laser usage beyond the proof of @gloomyandy s test version?

But at 250mm/s I get this engraving quality which looks great for me:

o_lampe

@paulg4h Did you use input shaping?

paulg4h

@o_lampe no, I am not use M593 currently (https://duet3d.dozuki.com/Wiki/M593)

Would this improve it also?

o_lampe

@paulg4h I don't know your engraver mechanic, but resonance from acceleration can be avoided by input shaping.

T3P3Tony

@paulg4h

thanks for these tests. its great to see the speed/quality improvements.

@gloomyandy how you been incontact with @dc42 about what the changes were and the potential to port this into the main branch of RRF?

gloomyandy

@t3p3tony Hi tony, yep I've emailed dc42 with my findings and a link to this thread. There may be a better way to do things than my simple fix (which is literally a one line change), so I'm waiting to see what dc42 has to say.

dc42

Thanks to @gloomyandy for identifying this. I agree with the fix he proposed and it will be included in RRF 3.4.0beta6.