In hopes of making using a laser more beginner friendly by having them enabled in the firmware by default and the instructions more complete I have been burning all sorts of things.

Looking for some wisdom.

Running on a 32bit board.

Those dark black specs vary with each burn. I have rewired the laser completely tried a resistor on the signal pin. I can swap to a different laser, try M106 instead, Frequency setting in Marlin?

Any ideas?
E2 Engraving Test.gcode (304.6 KB)

Super happy the timing stuff seems to be fixed. The lines start and stop where they should except for these glitches.

12/6 edit.

Junction deviation brings the speeds up. Raster SKR Pro 28mm/s, Rambo 22mm/s. Both seem to be able to vector even faster.
Use inline commands, no power ramping is needed if you use “over burn”. Ramping is an option on teh 32bit boards, 8 bit is not liking it.


Throw in some notes while I am at it.

My 2.5W laser seems to need 15W at full power.
All three axis moving (dual endstop) and the laser at full power the whole system pulls 43W.
So that means the the 70W PS I ship with the kits is overkill, probably too much. I will see if I can go down to a 5A if that saves any money. Originally I got the 6A to be able to run a hotend as well as the 3 axis.

Using //#define LASER_POWER_INLINE_TRAPEZOID_CONT @10 steps made the etching pretty bad almost like it skipped every other line. Not sure if this needs to be revisited as it is only for 32 bit boards and probably overkill.


Can’t wait for more details on config, firmware, laser specs and board wiring.

Do you have this enabled for true grayscale lasering?
It requires some processing power but most 32 bit boards should be able to handle it.


Jeff had a good idea last night and I will try it shortly.


Okay got it for the SKR, need to do it all over again for the 8 bit boards, should be much faster to dial it in though.

No glitches, turns out it was speed related. I did mess with speeds but not that low. 27mm/s on the 32bit SKR is glitch free, 30 gets a couple glitches. 8 bit boards are probably going to be slower.

#define SPINDLE_LASER_ENA_PIN PB0   // Heater2

Uses heater 2 as enable, no random boot or shutdown laser blasts.

Vector tests. You can see the oblong laser shape. Testing the ramping functions. No help. All off is as good as ever other step. cool! Turning up accels will help with the corner over burn but probably not too much. *Make sure overscan is on, rasters will be great with no power ramping.

Taking notes.

Next up might be dot size but 0.19 looks pretty good.

I will get the SKR changes into the Marlin Builder firmware shortly!!!


This thread is just what I’ve been waiting for to get into the laser scene! You are the man!


I have a large picture burning now. Looks like 27mm/s is a touch high, there are a few tiny glitches. Probably bump it down to 25mm/s

HAHAH just persistent. I have been putting this off for a good 5 years. I was never happy with how the lasers were working I knew it would not be simple to get it as perfect as I would accept. Looks like we might finally have it!!! I need to work on the other boards and then update the instructions and links. So soon, but probably a week or so until it is all done, provided nothing crazy happens between now and then.


Can you tell us the laser you used so we can get orders in. Maybe some nice family member will put it under the Christmas tree as gift :wink:

Great work. Looks fantastic!

I wonder what is causing those glitches. Is the buffer running out again? I wonder if marlin would like an issue for this.

The skr boards are supposed to be stupid fast, so I am wondering if it is something with the geometry and not the processor speed. Like 5 tiny 0.1mm movements and the serial port can’t send them faster than the tool is moving, so it has to stop.

I don’t know the terms, but in the marlin config, are you using the setting where it dims the laser while it is accelerating? It is called “laser mode” in grbl and I thought there was a similar feature in marlin.

I am using a couple for testing but this seems to be the one I would recommend so far.

2.5W version

I am not sure. That is why the speed thing through me off. I made a smaller file/less commands per mm and it still glitched. When I got it to go glitch free I started turning things back on. one of which says 32bit only and I turned it all the way up…no noticeable performance hit, did not add glitches back. That was continuous ramping I tried every ten “steps” and every other.
This is using inline commands so instead M3 S155 on a line it is just added to a move G1 X10 S155. M106 and the regular M3 did not work nearly as well.

I think we will know more when I start testing the rambo again. It previously got super glitchy in a fairly plain part of the picture. What I assume if few commands. I can see it happen to the machine before I can see the laser results. It is like what was happening with the arcs if that makes sense. It just starts to slow down for no reason.

Yes/no, I keep calling it ramping but Marlin has a few options for it. I use inline commands but find the ramping to have no noticeable effects if you use overscan.


Also going to put a huge asterisks on that recommendation. I have only got the SKR going well, the 8 bit boards might not be ready for lasers yet. Or Marlin might not be optimized enough.

1 Like

Thank you for getting to this. I know in the old/current laser doc there is the video from styropyro about laser safety goggle testing. One thing most people don’t mention is where they got their goggles and/or which type they got.

Is SurvivalLaser the only place to get affordable goggles? As the laser most people use (and what is mostly sold) is the 445-450nm blue laser, is the orange tinted 190-540nm OD6 pair of goggles the best option? Or are we also looking out for infrared/uv radiation from these, and need something with two ranges of protection?

What wattage are you using 2.5k?

1 Like

I would get whatever protects from the largest range that you can afford. Most important is just keep them on anytime the laser is near. If you are not looking at it or getting hit by it, nothing can go wrong. Now that I am confident in my setup I turn it on stay far away and only glance over to make sure there is not a fire going.
I had a close call yesterday and dam near shot it straight in my eye, no joke 1/3 second later and I would have at least one less good eye. I was being very stupid and had the glasses right next to me and forgot to put them on. They are a bit uncomfortable to wear as they block enough of the visible spectrum that it is almost uncomfortable for the eyes. After that scare I just keep them on anytime there will be power to the laser…even if it is not running.

I am not sure… I would love to find a couple sources but these are the only ones I saw tested.

@techguy682 @vicious1 I have two pairs of these. According to their graph, at ~450nm they are ~OD7 .

1 Like

But overscan is a setting in cam, right? So it would be better for other cam programs if it wasn’t needed.

I am mostly just basing this on the fact the grbl folks seem to love it. I have only turned my laser on once.

Yes. It can be enabled I think. I would have to test it more. The reason I did not enable it is vectors and rasters actually look pretty good even without overscan and I am doubting the 8bit boards can use it as the basic version messes up vectors.

I am thinking the glitches is a Marlin issue that needs to be fixed so for now maybe just enabling the basics and getting more to test it is a good solid first step to figuring out the actual issue.

1 Like

Looks like the bugfix branch is good to go for the SKR in Marlin builder. Now that I found the right command. That was the branch I was testing in so it is okay that the current branch is borked.

Maybe, but I think the SKR has more than enough power. Smoothie has a laser specific firmware that writes the gcode a different way to add more commands per buffer line, and it maxes out at about 300mm/s at 300 dpi, so the SKR is probably fine with a diode laser running 27mm/s at 133dpi.

1 Like