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.
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?
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 the 32bit boards, 8 bit is not liking 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.
Do you have this enabled for true grayscale lasering?
“LASER_POWER_INLINE”
It requires some processing power but most 32 bit boards should be able to handle it.
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.
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.
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.
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 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.
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?
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.
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.
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.
