Laser Inline Power processing slow?

[Hauke]

I am currently finding my way into laser-engraving black acrylic with the 2W IR laser. Using a few test patterns, I established that at a speed of 10000 mm/min, a nice and fine line spacing of 0.05 mm, and using laser power between 10% and 40% I get beautiful true greyscale (no dithering or halftone)! So I was very much looking forward to engraving my first image. Lightburn produced a fine file working with inline power for each dot - so basically a loooong sequence of 0.05 mm movements with a given laser power. And basically the file works - I do get greyscale - but not the one I intended, but a too intensly lasered one - reason: The laser creeps at a speed far below 10000 mm/min across the workpiece! The touchscreen shows that the target speed is 10000 mm/min, but the de facto speed is less than half of it I’d guess. My main assumption: The GCode-processing eats up too much time, and the controller just hasn’t it in itself to process 0.05 mm spaced inline power commands…

I mean: obvious solution is to find the sweet spot that the controller can handle - but this will “compress” the achievable power range to 10% - 20% or so, which may mean loosing dynamic range… Still, I’ll try this and keep you posted!

Anyone any insights that may help me?

Btw. here the test patterns, which show how nice a greyscale you can have! Please note: This is not in any way dithering or halftone - varying the laser power causes the whitening to be gradually stronger, but within a square of the test pattern the laser holds the same power for the entire scan time.

[Skreelink]

@Hauke

My main assumption: The GCode-processing eats up too much time, and the controller just hasn’t it in itself to process 0.05 mm spaced inline power commands…

Indeed the controller can’t keep up with the shear number of gcode lines being fed to it. Especially if it’s waiting on an ‘ok’ response for each and every line, doubling the bandwidth load. Which I assume it does so between the touchscreen/controller.

If available, you could try running via Lightburn over USB. Lightburn’s default send method, buffered, is usually faster. As it just keeps the command buffer full so the controller runs every line in queue and doesn’t wait on an ok response. On my 3018, there’s such a noticeable difference in speed. Using the offline controller (similar to using the touchscreen on the snapmaker) it gets the slow stuttering as it waits on ok responses, whereas via lightburn’s buffered (or gSender by Sienci) it’s fluid back and forth no matter the speed.

I’ll try to do a test later today running it via touchscreen, wifi start (my batch file), and lightburn and see if there’s a difference. Being Marlin, it might not help.

[Hauke]

Thanks for these insights! I guess I’ll do the same and put Lightburn on my old laptop and run it directly. Honestly, my hopes are not too high: Often the touchscreen controller already shows 100% while the device is still executing several moves - which I assume is an indication that the touchscreen also uses buffered commands.

In the meantime I have continued my experiments, and I am considerably frustrated and thrilled at the same time. I am thrilled because the 2W tiny focus allows for such a detail, and also that true greyscale in principle works, but frustrated because the stupid software gets once again in the way.

I lowered the laser movement speed, down to 2000 mm/min in the end, but the laser still moves visibly slower in dotted regions than if it can do a longer stretch. So it is not only the absolute speed that causes the problem - even at moderate speeds the effect of command processing is there and creates problems. Here are a few results - I plan to laser Escher’s metamorphosis strip and picked a few very different parts as test patches. The top, “complete” image is done with dithering, not greyscale, and even that is not too shabby. The lower, incomplete image is the same as true greyscale.

The arrow points on a square which is full white - and because of that, Lightburn cleverly says: Let’s not split this into single dots, but let the laser run a few mm at max assigned power - just one GCode command for a few mm’s rather than dozens in the more dynamic regions. The result is that the laser can finally speed up, and the laser energy disposed is no longer good enough to get the square fully white - so instead of being the brightest part of the image, it is slightly darker than the surroundings. And you can even see the speed-up and slow-down phase of the laser - so trapezoid power adjustment not up to the situation or not working at all And as you can see, the problem is true either for dither and for greyscale…

Oh, btw - the height of the full image is 33 mm - this gives you an idea of the stunning detail you get with the 2W!

But where I have the slowed-down dots, greyscale is really nice - here’s a detail for comparison - top dithered, bottom greyscale, the lower strip is 6mm high (these details!!!):

This gives me hope - I’ll get there eventually…

[xchrisd]

10000mm/min means 167mm/sec, this means at least for printing, the firmware limits the speeds to 120mm/sec.
It has to be verified if the limits for laser are the same, enter M503 and have a look.

[Skreelink]

The controller definitely cannot handle such a low resolution. I get the same slowdown sending it via my batch code to start directly on the controller, and in Lightburn.

EDIT: I love the difference in estimate vs actual. Estimate time? 3.5 minutes. Actual time from slowdown? 22. I set the speed at 9000mm/min 0-100% 0.05 interval grayscale.

Comparison; Lower is direct on the controller, upper is via USB Lightburn. Obviously burning waaaay too hot.

However; it’s worth noting that using my drag/drop script to send it directly to the controller actually has a higher fidelity if you zoom in. It’s especially noticeable in the lower right iris, upper right eyelashes, and in the folds of the upper eyelid. The lower lashes also seem to muddy out and vanish in the Lightburn USB one. So apparently over USB is still indeed slower than directly on the controller.

[Hauke]

Thanks for trying this! I’ll grab your gCode sender and try with that! And yes, 100% is too much - my black acrylic (the matte stuff that came with the 10W laser as a sample) “saturates” at 40% @9000 mm/min. I like that you also picked an Escher picture

I have now found kindof a sweet spot - painfully slow 500 mm/min with Atkinson dithering. At 500 mm/min the difference between fast and slowed-down move is not really dramatic, so I get consistent result. And with the wonderful 0.05 m line spacing, the dithering looks very good. I’d have loved to do true greyscale, but with 500 mm/s the acrylic is fully white at ~20% laser power, and it does not start to whiten at all below 10% - so there are 10% of laser power range to squeeze the whole dynamic range into, and I suppose that will not work out. I may still give it a try.

I currently cannot post a photo, but will do so later - all in all I’m pretty satisfied - and that is mainly attribute to the very high resolution you can achieve with the 2W - I like this very much!

[Hauke]

@xchrisd

10000mm/min means 167mm/sec, this means at least for printing, the firmware limits the speeds to 120mm/sec.

Yep, 167 mm/sec - I’ve gone up to 200 mm/sec with 3D printing in the past - so if they limit the max speed, that’s a relatively new thing (meaning: Cannot be in there longer than perhaps 2 years ). But I’ll check, thanks for the hint!

Btw. - there’s this very old post by @Tone where he went up to 350 mm/s with success! Speed Limits on SM2? - #3 by Tone - interestingly enough that thread claims that speed was limited to 150 mm/s already past then… perhaps I actually never went to 200 mm/s and did not realize

[Hauke]

And here’s the promised photo:

And this is the source image:

The result is pretty nice I think - with a bit of adjusting the source image I might get close to perfect. But slow…

[Hauke]

I tried to locate your drag’n’drop script without success - could you point me to it?

[Skreelink]

Here you go.

Guide: Automatic Start via Drag/Drop

This is the “wireless” portion to round out my full Lightburn control guide, found here: Since my main snapmaker (pretty much stays setup with the 10W + Enclosure) is far away from my PC, using a cable + Lightburn isn’t an option. I usually just used Luban to start files. However, as many of you know, their software is slow and iffy, so why not bypass it? Note: Be sure to read all the edits at the end of the post for more info. There’s a few pre-requisites and I’m setting this up on a windo…

EDIT: Also, what profile are you using? I’m currently doing a test between Marlin and GRBL. First thing I noticed is just how lean the GRBL code is vs Marlin. The same file in Marlin is 6.77MB, whereas the GRBL one is 5.59MB. Leaner code runs faster, running a difference test now. However, I forgot to tick ‘invert’ image, so it’ll look funny. but I want to see if there’s any detail difference. I didn’t feel like timing it, so… meh. They both run slow. However, theoretically, the GRBL code might save a minute or two.

[Hauke]

I do Marlin. And to make a difference, a few minutes would not help - I’d need the 0.05mm pixels to be processed as fast as other stretches of GCode - as soon as the speed gets inconsistent, the greyscale gets inconsistent too.

I wish I had more time at my hands… I’d really love to dig into the Snapmaker firmware. The Controller is actually a relatively powerful MCU, so I can hardly imagine that all this is really processing power limited - I guess it is the software, and I would not be surprised if Snapmaker’s coders have considerably botched things here. It might even be a good idea to try and port Klipper over to the SM2, but that’s no small feat… Well, wishful thinking, I definitely have no time for that.

As for your drag’n’drop script: Who is actually processing the API calls? My gut feeling would be that this is handled by the touchscreen controller, so I’d not understand why it would run better, although your Escher’s eye example proves me wrong… Is it really going directly to the actual marlin controller? Does it have the memory?

[Hauke]

@xchrisd

enter M500 and have a look

I suppose you meant M503 - and thanks for pointing me there! I’m shocked: It limits at 100 mm/s!

M203 X100.00 Y100.00 Z40.00 E40.00

How could they??? Grmbl… getting more and more frustrated with Snapmaker’s engineers… And angry with me - I should have seen: the test patterns look the same for 5600, 7300 and 9000 mm/min…

[Skreelink]

I have a stunning test result for you. Apparently, the snapmaker’s trapezoidal power is reversed. I did another test to compare Marlin Inline vs GRBL M4 and the result was striking. I then just ran a filled box, again, Marlin Inline and GRBL M4 and… the edges burned harder with the M4 trapezoidal power. The power output is ALSO different between GRBL M4 and Marline, despite calling the same exact power.

Snippets from the eyes; you can see the only real difference is the inclusion of I, the actual code is the same.

Settings: 5-30% 9000mm/min 0.05 interval for eyes. 6000mm/min 5% 0.05 fill for box.

Inline;

; Layer C00
G91
G1 X4.5 F9000 I S0
G1 X0.05 I S32.3
G1 X0.05 I S39.4
G1 X0.05 I S35.8
G1 X0.05 I S28.8
G1 X0.05 I S34.3
G1 X0.05 I S39.1
G1 X0.05 I S37.8
G1 X0.05 I S46.6
G1 X0.05 I S31.1
G1 X0.05 I S39.1
G1 X0.05 I S32.3
G1 X0.05 I S35.6
G1 X0.05 I S34.6
G1 X0.05 I S31.3
G1 X0.05 I S38.4
G1 X0.05 I S33.3
G1 X0.05 I S24

GRBL

; Layer C00
G91
G1 X4.5F9000S0
G1 X0.05S32.3
G1 X0.05S39.4
G1 X0.05S35.8
G1 X0.05S28.8
G1 X0.05S34.3
G1 X0.05S39.1
G1 X0.05S37.8
G1 X0.05S46.6
G1 X0.05S31.1
G1 X0.05S39.1
G1 X0.05S32.3
G1 X0.05S35.6
G1 X0.05S34.6
G1 X0.05S31.3
G1 X0.05S38.4
G1 X0.05S33.3
G1 X0.05S24

The box gcode?
Inline

; Layer Labels
G91
G1 X3 F6000 I S0
G1 X20 I S12.8
G1 X3 I S0
G1 X-0.2Y0.05 I S0
G1 X-3 I S0
G1 X-20 I S12.8
G1 X-3 I S0
G1 X0.2Y0.05 I S0
G1 X3 I S0
G1 X20 I S12.8
G1 X3 I S0

M4

; Layer Labels
G91
G1 X3F6000S0
G1 X20S12.8
G1 X3S0
G1 X-0.2Y0.05
G1 X-3
G1 X-20S12.8
G1 X-3S0
G1 X0.2Y0.05
G1 X3
G1 X20S12.8
G1 X3S0

Results? Bottom is M4, Top is Inline (5% didn’t scratch it on Inline marlin, reran over it with M3 GRBL, same result)

See how it burns more on the edges? M4 trapezoidal is broken, yey! It increases power as it slows down.

Currently running GRBL m3 to see how it compares to Inline now.

EDIT: Yep, my old standby GRBL M3 works as good as it ever did. Same result as marlin inline, just leaner code.

It’s upside down, yes, but upper left M3, upper right Inline.

Overall; DO NOT USE M4

[Skreelink]

@xchrisd

10000mm/min means 167mm/sec, this means at least for printing, the firmware limits the speeds to 120mm/sec.
It has to be verified if the limits for laser are the same, enter M500 and have a look

Baba’s speed is limited to 150mm/sec with the single extruder mounted.

I’ll test Frey’s when it’s done running (it’s mounted with the 2W currently)

With the 2W: indeed limited to 100.

waves a little gcode wand

Now it’s 200.

[Skreelink]

@Hauke

As for your drag’n’drop script: Who is actually processing the API calls? My gut feeling would be that this is handled by the touchscreen controller, so I’d not understand why it would run better, although your Escher’s eye example proves me wrong… Is it really going directly to the actual marlin controller? Does it have the memory?

I wish I knew, but a further test shows the leaner code of GRBL actually does contribute to some finer details. While they are very minute, I was able to catch them. First; results. This was done at 9000mm/min (after changing the limits), 25% power, 0.05 interval, stucki. I also remember to invert the image.

Original:

Results: GRBL M3 on bottom, Marlin Inline on top. These are only 25mm tall, so some details will be lost from squishing the image a little.

While first glance they look the same, but tiny details came out better in the M3 version. As circled below you can see the veins in the right side of the eye, the reflections of the lashes in the iris to the left, and subsequent reflections further to the left. Also overall the colour depth seems more dynamic.

Is this major to swing one way or the other? No. Could some of it be how I took the picture? Mayhaps. I just figured it interesting and decided to share. These tests were all done on aluminum business cards.

[Hauke]

Thanks for running and sharing all these tests! For me it all boils down to: Buggy and inefficient firmware. I mean: why can the trapezoid be implemented reverse? This is nothing they’d need to invent themselves - just pick the well-tested most recent Marlin, and be done with it… Or is it that they did not implement trapezoid at all and you see the effects of the accelerating/deccelerating laser as before trapezoid times? Your test image does look more like the bug you assume, so I’d agree with that analysis.

As for GRBL being more efficient code: Looking at your examples, the shorter code is mainly left out whitespaces and the missing inline “I” - with thousands of lines of GCode this will add to a few kilobytes for sure, but the general information is the same, and the number of commands also, which explains why the effect on execution speed is not significant.

But I was happy to learn that there are stupidly low speed limits for 3DP and Laser - which I’ll change and M500 into the EEPROM… At my own risk of course.

And I am still somewhat thrilled by the tiny 2W focus and its sharp rersults. A pity that it does not work well on wood. Did anyone ever try chemically treating wood to be susceptible to the IR? I seem to remember I read that Borax might be a solution…

[Hauke]

@Hauke

The Controller is actually a relatively powerful MCU, so I can hardly imagine that all this is really processing power limited

Just unscrewed my “spare” SM2 controller. It sports a GD32F305VG, an ARM Cortex-M4@120MHz. This should be very much capable of processing the GCode bombardment if the firmware is decently coded.