2022 laser Revisit

Yes please!

That is the part I am just not understanding. With the ramping turned off it is not processing anything, it is just changing the ttl/pwm. No accelerations until the ends when the ttl is not changing. I feel like it should easily handle more, it can’t be processor intensive to change the ttl frequency, can it?

Now for whatever reason it seems when you do use just M3 (not M3 I) accelerations are enabled for the change in laser power so it is a burnt mess.

The programming is still very wrong. I mean M4I doesn’t work, and when I did some cut tests with ramping the lines were obviously wrong. Check this out.


The math seems to work pretty dang good above 31mm/s, just below that it is a mess.

Have you tried posting to Marlin/thinkyhead about it? I wonder what their test case is if they keep changing everything and then it still ends up like that.

Maybe I should redo the tests on s fresh piece of wood to clearly show the issues. That might help over at the Marlin github, not sure how much interest they have in the laser stuff but getting this right would be a game changer.

Use the inside of cereal (or other food) boxes. Cheap and consistent surface material. Great for testing.

2 Likes

Well today was super fun! I ran @johnboiles GRbl on my Rambo…stupidly easy, no wire swapping laser is good to go…Top notch work John!!! I ran vector burns at more than 300mm/s no issues other than my laser ran out of power to make a mark, corners always looked great no over or under burn. The big thing is Raster burns were stable at 81mm/s!! The other crazy find is even at 150mm/s when it did hiccup a bit you could not tell in the burn, you could hear the motors change sound but the burn stayed perfect. In Marlin you got visible glitches.

Raster - Raster Grbl Test on the MPCNC - YouTube 150mm/s
Vector - Vector Grbl Test on the MPCNC - YouTube 250mm/s

So I need to figure out a SKR Pro GRBL version. I want to see what 32bit can do or maybe that is not the bottleneck??

7 Likes

@vicious1 , i reply your 79$ laser thread’squestion here as it seems to be a better place.
I had made a dedicated thread here with my progress on it.

The grblHAL driver to use for skr pro board is this one:

Also interressing reading on that github skr pro issue(old repository) where we were able to make it work: https://github.com/terjeio/grblHAL/issues/337

Here are the plateformIO building paramaters i used in December to get it work:

[env:btt_skr_pro_1_1]
# Untested and might not boot.  Please report issues at:
# https://github.com/grblHAL/STM32F4xx/issues
board = genericSTM32F407VGT6
board_build.ldscript = STM32F407VGTX_BL32K_FLASH.ld
build_flags = ${common.build_flags}
  # See Inc/my_machine.h for options
  -D BOARD_BTT_SKR_PRO_1_1=1
  -D USB_SERIAL_CDC=1
  # Boot loader offset (32K)
  -D HSE_VALUE=8000000
  -D HAS_BOOTLOADER
  # TMC2209 stepper drivers
  -D TRINAMIC_ENABLE=2209

  # Motor ganging & auto-squaring for MPCNC Primo
  -D X_GANGED=1
  -D X_AUTO_SQUARE=1
  -D Y_GANGED=1
  -D Y_AUTO_SQUARE=1

lib_deps = ${common.lib_deps}
  eeprom
  trinamic # TMC2209 UART support
lib_extra_dirs = ${common.lib_extra_dirs}

Trejeio, the maintainer, doesn’t own a skr pro but he is very reactive on issues if we can make tests on his behalf.

1 Like

I can’t wait to try it! Thank you for all that info.

And it can build with platform dot io that is rad!

1 Like

I’m running my own tests. Can you share you Grbl settings and test pattern Gcode file?
I’m having trouble to get Grbl to engrave the grayscale @ 100mm/s even at 100% power on my 5W (optical) laser.

Thanks

I topped out at 81mm/s it started to stutter a bit, marlin was 22.

I used lightburn with a 4mm overscan. Let me see if I have the gcode still on the card or not.

1 Like

Ahh ok. I saw the title of your video (150mm/s) and thought I had done something wrong.

So far my testings tell me that µCNC runs about the same speed as Grbl. But there are significant differences in the laser power handling that leads me to believe I can get more juice out of µCNC.

Grbl @ 60% power and 100mm/s

µCNC @ 30% power and 100mm/s

EDIT: I had to run the file for µCNC at a lower power or it would be too burned.
For both runs the same setups (top speed, accel, etc…) and on the same machine and electronics.

Just one side note. The image was about 6cm wide so both firmware were actually not hitting the 100mm/s mark but close.

I also used lightburn but with an overscan of 2.5mm

I’m way out of my league making suggestions about other firmware versions that Marlin, but is there any chance that µCNC treats PWM values in the g-code as 0 to 100 rather than 0 to 255?

1 Like

I think GRBL does 0-1000 by default.

µCNC treats the value in Gcode as defined in the settings (the default is 0 to 1000 like grbl) and internally is multiplied by the direction (1 or -1).
Then when sent to the tool each tool converts to its own range. In the case of a PWM tool it can be 0 to 255, but the tool itself can have a minimum and maximum.

VFD tools can convert that value to another range.

When I saw the discrepancies between the two burn powers, my thought was that the two versions were somehow interpreting the g-code differently. The power of the laser is fixed, and I’m not seeing artifacts that indicate you are reaching the limit of the feedrate, so in my mind, either µCNC wasn’t moving as fast for the given requested feedrate, or µCNC was interpreting the laser power input value differently. Comparing the job times might give a clue. Again, I have no GRBL experience.

You are right:

µCNC took about 9m17s to run the file.
Grbl took about 8m59s to run the file.

That’s 18 seconds longer. I don’t know how much difference that will make.
I’ll will retry to re-run the tests using the exact same file (bigger to get longer lines for the machine to accelerate to 100mm/s). I will also do some dry runs to try to even-up the execution time but that would mean the settings would be different from firmware to firmware.

Any suggestions on the pattern file?

EDIT: I did a dry run with the 16bit mode enabled in µCNC and I can do the same file in 8m48s with the exact same settings so I will use that to compare side by side.

I would rather have somebody else do the testing but here it goes:

Same settings:
Max speed 6000mm/min
Accel 100mm/s2
Spindle max rpm: 1000
Spindle min rpm: 0

Run on Atomstack A5 with 20w (5w optical) laser.

Same file at 6000mm/min 50% and dynamic laser mode (M4) power with 4% overscan. Image size 70x37 mm.

Grbl on top. Runtime 10m27s.
µCNC on the bottom. Runtime 10m07s.

Some notes:

  • Used stock Grbl.
  • Used 16bit mode on µCNC to be able to at least keep up with Grbl execution speed.
  • Besides the obvious engraving differences Grbl seems to underburn on the exterior edges.
  • µCNC has the opposite problem. There are obvious overburns on the exterior edges.

My first suspicion was that Grbl was using a lower PWM frequency then µCNC and the laser power was not updating fast enough. But they are using the same ~1khz pwm. But I don’t know. It may improve Grbl performance. Testing needed.

In the mist of all this I found a couple of minor planner optimizations that I will add to µCNC and I also want to add play around with laser pwm frequency to see if it adds any quality gain to engraving. I’ll also try to look at the overburning on the exterior edges thingy.

2 Likes

That is such a significant difference… Where is it coming from?

Are you using the same formula to reduce the laser intensity with acceleration?

Can you write a unit test in grbl and ucnc to check some of those functions end up with the same result?

1 Like

I’ll try to figure it out. I’m most probably doing something stupid (or multiple things) :sweat_smile:.

On µCNC the laser scaling is linear to the acceleration/deacceleration.
One thing is that the power is being scaled relative to the top speed of the segment and not the programmed feed (I’m not sure how Grbl does it) . That would explain the exit/entry overburns. This affects the density of energy the laser is sending to the surface.

This accidental bug seems to allow engraving at higher speeds but probably will also play with the contrasts. With higher overscan values might smooth the overburn.

I have to do some further testings.

If the gcode asks for 10mm/s and 25% power, then that segment should be scaling the 25% based on what fraction of 10mm/s it is currently moving (which would only be reduced by acceleration). If it was traveling at 5mm/s, the power should be 12.5%. That makes sense to me. That is what I would expect. But I guess it is sort of a contract between the CAM and the firmware.

2 Likes

I’m 100% with you on that. It is what makes sense. That’s a reason why this puzzles me.
I guess the thing is that at lower (standard engraving speeds) this is almost unnoticeable because the machine has room to reach the programmed speed and apply the correct power by mm/s.

edit: Just fixed tested the code that uses the programmed speed as reference and the results are now similar to Grbl. Overburn is gone and no noticeable underburn on the entry/exit. A bit more burning but not much better.


Grbl on top and µCNC on the bottom

Man this was fun. Learned a ton again.

Just a couple of notes. PWM higher frequencies don’t seem to affect the result but this is only a preliminary conclusion. Needs more testing.

Also one other side note. I ran the same code on Arduino M0, Bluepill and Blackpill (dry run only, not on an actual machine).

For example the Blackpill runs a bit above 5x the clock speed of the Arduino UNO. Yet the gains in execution time were only about 10% faster.

1 Like