Laser engraving doesn't maintain constant speed

kmalu87 · February 12, 2024, 9:36pm

Hi All!

I have a Openbuilds Custom CNC that uses X32 blackbox controller running GRBL HAL (Build 20230501). My issue is that the machine stutters (likely taking pauses with every change in power value) leading to engraving being super slow. A 2 min engraving file (based on preview in Lightburn) takes well over 10min on the machine with speed no where close to my engraving speed of 12000mm/min. Running Grayscale image more of Jarvis - no constant engraving speed…the laser seems to be firing up correctly but engraving doesnt take place. When I run material test setting, I can get engraving even at 20000mm/min speeds. unsure what is going on but any help troubleshooting this would be appreciated

Here are my GRBL settings:
$0=10.0 ; Step pulse time, microseconds
$1=15000 ; Step idle delay, milliseconds
$2=0 ; Step pulse invert, mask
$3=4 ; Step direction invert, mask
$4=0 ; Invert step enable pin, boolean
$5=7 ; Invert limit pins, boolean/mask
$6=1 ; Invert probe pin, boolean
$8=0 ; Ganged axes direction invert as bitfield
$9=1 ; PWM Spindle as bitfield where setting bit 0 enables the rest
$10=1 ; Status report options, mask
$11=0.010 ; Junction deviation, millimeters
$12=0.002 ; Arc tolerance, millimeters
$13=0 ; Report in inches, boolean
$14=0 ; Limit pins invert, mask
$15=0 ; Coolant pins invert, mask
$16=0 ; Spindle pins invert, mask
$17=0 ; Control pins pullup disable, mask
$18=0 ; Limit pins pullup disable, mask
$19=0 ; Probe pin pullup disable, boolean
$20=0 ; Soft limits enable, boolean
$21=1 ; Hard limits enable, boolean
$22=1 ; Homing cycle enable, boolean (Grbl) / mask (GrblHAL)
$23=3 ; Homing direction invert, mask
$24=100.0 ; Homing locate feed rate, mm/min
$25=1000.0 ; Homing search seek rate, mm/min
$26=250 ; Homing switch debounce delay, milliseconds
$27=5.000 ; Homing switch pull-off distance, millimeters
$28=0.100 ; G73 retract distance, in mm
$29=5.0 ; Step pulse delay (ms)
$30=1000.000 ; Maximum spindle speed, RPM
$31=0.000 ; Minimum spindle speed, RPM
$32=1 ; Laser-mode enable, boolean
$33=5000.0 ; Spindle PWM frequency
$34=0.0 ; Spindle off Value
$35=0.0 ; Spindle min value
$36=100.0 ; Spindle max value
$37=0 ; Stepper deenergize mask
$39=1 ; Enable printable realtime command characters, boolean
$40=0 ; Apply soft limits for jog commands, boolean
$43=1 ; Homing passes
$44=4 ; Homing cycle 1
$45=3 ; Homing cycle 2
$46=0 ; Homing cycle 3
$62=0 ; Sleep Enable
$$384=0 ; unknown
$396=30 ; WebUI timeout in minutes
$397=0 ; WebUI auto report interval in milliseconds
$398=35 ; Planner buffer blocks
$481=0 ; Autoreport interval in ms
$63=2 ; Feed Hold Actions
$64=0 ; Force Init Alarm
$65=0 ; Require homing sequence to be executed at startup
$70=7 ; Network Services
$73=1 ; Wifi Mode
$74= ; Wifi network SSID
$75= ; Wifi network PSK
$100=26.667 ; X-axis steps per millimeter
$101=26.667 ; Y-axis steps per millimeter
$102=200.000 ; Z-axis steps per millimeter
$110=38000.000 ; X-axis maximum rate, mm/min
$111=38000.000 ; Y-axis maximum rate, mm/min
$112=3000.000 ; Z-axis maximum rate, mm/min
$120=1000.000 ; X-axis acceleration, mm/sec^2
$121=1000.000 ; Y-axis acceleration, mm/sec^2
$122=150.000 ; Z-axis acceleration, mm/sec^2
$130=630.000 ; X-axis maximum travel, millimeters
$131=1280.000 ; Y-axis maximum travel, millimeters
$132=100.000 ; Z-axis maximum travel, millimeters
$320=grblHAL ; Hostname, max: 64
$325=23 ; Telnet port
$326=80 ; HTTP port
$327=81 ; Websocket port
$341=0 ; Tool Change Mode
$342=30.0 ; Tool Change probing distance
$343=25.0 ; Tool Change Locate Feed rate
$344=200.0 ; Tool Change Search Seek rate
$345=200.0 ; Tool Change Probe Pull Off rate
$346=1 ; Restore position after M6 as boolean
$370=0 ; Invert I/O Port Inputs (mask)
$384=0 ; Disable G92 Persistence

Also, have set S value max of 1000 in Lightburn

Please help!

Dskall · February 12, 2024, 10:33pm

In order to get more accurate time estimate you will need to read from controller.

Do you have fast white space scan on?

kmalu87 · February 13, 2024, 2:18am

Thanks! I do not have the fast white space scan on. Thats also one of the things I checked upon reading some of the comments on the forum. To add a bit more context, when the image I am trying to engrave, where the color is all the same across a line, it works as expected and engraves at a constant speed. However, when the color changes within the line (gradient greyscale color), thats where the machine stutters throughout the same line.

kmalu87 · February 13, 2024, 6:58pm

A detail I missed out here is that I also setup my machine to “GRBL” during “Device Setup” in Lightburn. Unsure if this is causing the issue?

JohnJohn · February 13, 2024, 7:29pm

This is an excellent choice.

Please screen-capture your Device Settings window. (Windows Snip will work if you don’t have a different tool that you prefer more.) Drag and drop the image from your computer into a reply here.

Please also, scroll back in the Console window, Select and Copy the initial connection message sent by the Laser engraver to LightBurn. I am interested to know if the ‘Build Options’ are shared in the initial message and if so, precisely what these Build Options are.

If you are engraving an Image, make a copy of the file you are working on and shrink the image in the copy to make the smallest image that clearly demonstrates the stuttering behavior.

You can turn the power on the laser down to 0.5% or lower to verify the behavior persists without consuming material.

Once you have this diagnostic version of your file with the small image, in LightBurn click File, click Save GCode and save that file somewhere convenient for you. Drag and Drop that file into a reply here as well.

kmalu87 · February 14, 2024, 4:43am

Thanks for your response. Please see all the things you asked for below:

Device Settings Window:

Console Window:

I ended up recording a video to demonstrate the actual issue - please note that I decided not to supply power to the laser since I had already run this job with laser turned ON previously and decided to re-run the same program from same spot as previous. Video here:

The gcode file as you had requested here:
12K_Grey.gc (653.7 KB)

Lastly, this is the image I was trying to engrave:

And this is what I got below highlighted in the red rectangle:

As you can see only the darkest regions are getting engraved when I know that my laser is fully capable of engraving at 12000mm/min even with 30% power…

Hope this information helps… Really looking forward to fix this issue. Many Thanks!!

JohnJohn · February 14, 2024, 6:51pm

I see nothing wrong with the GCode that could cause the awkward pausing.

This is a very helpful image. Thank you.

This generally indicates that the selected engraving speed is too fast for the range of power applied. The 90% power setting is reasonable. You may find that selecting 9000 mm/min improves the gradiant of the engraving.

The GCode shows that your ‘Greyscale’ image is dithered. If you’re attempting to achieve Greyscale shading with a diode laser (without dithering), you’ll want to change your Image Mode in Cuts/Layers. Double-click the Image layer in the Cuts / Layers window to open the Cut Settings Editor, and when you are satisfied with the settings, click OK to make sure they are set.

The lower, speckled image in the work space is a faithful import of the GCode showing the dithering effect. The upper (selected) image is the image file you provided.

I haven’t tested the different Image Modes to see which is more memory intensive, but this may help.

In the Console window in LightBurn, please test this setting adjustment by typing the following:
$398=100
then press Enter. Then resend your file to the Engraver.

There was an adjustment made to the grblHAL firmware in Build 20231210 to improve laser performance.

There were other changes to the firmware in this build that may be relevant.

The changelog.md file may be of interest to you.

I could not determine which processor is used in the X32 blackbox controller. Knowing which processor is used may be relevant as ESP32-S3 firmware development is still in progress.

kmalu87 · February 14, 2024, 7:51pm

I changed this as suggested and re-ran the same file but unfortunately, no luck!

After that, I flashed the firmware with 20240205 where $398=100 was default value and tried with the same file again and that too didnt work!

Wondering if it has to do with buffering, would enabling Lightburn clustering help any?

JohnJohn · February 14, 2024, 9:03pm

As I was reviewing, I saw that GCode Clustering was a possible option on the controller. If it’s active on the controller, you can activate it in LightBurn.

I’m not as optimistic about that one.

Did you test with Greyscale?

Any info about the processor?

kmalu87 · February 15, 2024, 3:48am

So I did reflash the firmware using the GRBLHAL Web Builder where I enabled the LightBurn Cluster option under the “plugin” tab. Activated the clustering setting in Lightburn and reprocessed the image using “Greyscale” and tried running on the machine again. At first 30sec where you saw some stuttering in the previous video…that was gone! However, right where the greyscale starts, it started to stutter the same way it did before… So you were right, not much help using the clustering either.

As for the processor, its the ESP32 because thats what the Web Builder also defaults to when you select the X32 Blackbox controller. Moreover when I did the firmware upgrade with clustering activated, it gave me this information where it does say the chip is ESP32D0WDQ6:

[22:32:03] [ $I ] [VER:1.1f.20240204:leadmachine1010laser]

[22:32:03] [ $I ] [OPT:VNSLW2,100,1024,3,0]

[22:32:03] [ $I ] [AXS:3:XYZ]

[22:32:03] [ $I ] [NEWOPT:ENUMS,RT+,HOME,ES,REBOOT,SED,RTC]

[22:32:03] [ $I ] [FIRMWARE:grblHAL]

[22:32:03] [ $I ] [SIGNALS:HSE]

[22:32:03] [ $I ] [NVS STORAGE:*FLASH]

[22:32:03] [ $I ] [FREE MEMORY:257K]

[22:32:03] [ $I ] [DRIVER:ESP32]

[22:32:03] [ $I ] [DRIVER VERSION:240205]

[22:32:03] [ $I ] [DRIVER OPTIONS:4.3.2]

[22:32:03] [ $I ] [BOARD:BlackBox X32]

[22:32:03] [ $I ] [AUX IO:2,0,0,0]

[22:32:03] [ $I ] ok

[22:32:03] [ $G ] [GC:G0 G54 G17 G21 G90 G94 G49 G98 G50 M5 M9 T0 F0 S0.]

[22:32:03] [ $G ] ok

[22:32:04] [ connect ] Firmware Detected: grbl version 1.1f on COM6

[22:33:56] [ Firmware Upgrade ] [Starting…]

[22:33:57] [ disconnect ] PORT INFO: Port closed

[22:33:57] [ Firmware Upgrade ] esptool.py v2.6 Serial port COM6 Connecting…

[22:33:57] [ Firmware Upgrade ] .

[22:33:58] [ Firmware Upgrade ] .

[22:34:00] [ Firmware Upgrade ] _

[22:34:01] [ Firmware Upgrade ] _

[22:34:01] [ Firmware Upgrade ] .

[22:34:02] [ Firmware Upgrade ] Chip is ESP32D0WDQ6 (revision 1) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None MAC: c8:f0:9e:bd:27:9c Uploading stub… Running stub… Stub running… Changing baud rate to 460800 Changed. Configuring flash size… Auto-detected Flash size: 4MB Compressed 17104 bytes to 11850… Writing at 0x00001000… (100 %)

Hope this information helps… Really not sure where the problem might be so appreciate you taking time to help me troubleshoot this.

JohnJohn · February 15, 2024, 9:28pm

That’s plenty of power for a CNC controller.
240 MHz is also likely correct.

The Mark on the RF Shield should be ESP32-WROOM-32. Again, no issues.

With clustering enabled, click File, click Save GCode, and save that file somewhere convenient. If you drag and drop it into a reply here I may be able to see the difference.

If you’re also willing, please share the lbrn2 project file here as well.

I did see some unusual output working with the imported GCode with a poorly chosen Optimization Setting here while testing. I don’t think it applies to image engraving, but I’d be interested in seeing what Optimization Settings may have been set, or selected as a Default.

In the Laser window, click Optimization Settings and capture the window as shown. I’m hoping something strange has happened here and the solution is trivial. This also seems unlikely but I’d like to confirm.

kmalu87 · February 16, 2024, 1:24am

Yes, I did confirm with Openbuilds support and they said: “Its is not powered by the ESP32-S3, it actually uses the older ESP32”

Here you go:
12k_grey_Cluster.gc (258.9 KB)

Ofcourse! See below:
GreyScale Test File.lbrn2 (32.1 KB)

Also, this is the preview I get after all the settings you recommended were applied:

NicholasL · February 16, 2024, 5:56am

It’s a good idea for you to use the GCode clustering, I can see in the latest GCode file you sent everything looks much better, although at 12000mm/min you may be pushing it at 300DPI, so as @JohnJohn suggested try reducing that speed, or the DPI, preferably both. Eg. 9000mm/min 254DPI.

I noticed your “$1=15000 ; Step idle delay, milliseconds” seemed wrong, in standard GRBL this is a 0-254 ms value (and 255 if your don’t want them to go idle at all), so I’m not sure what 15000 will do in grblHAL?

The start of the gcode job you attached (12k_grey_Cluster.gc) was a bit jittery for me also when I tried running it due to the text included.

Try this file, it has very clean gradient, and it will be interesting to see the results you get with different speeds and DPI;

GreyScale Test File_FeedsDPI.lbrn2 (43.0 KB)

misken · February 16, 2024, 8:13am

Despite all the settings you already tested, I wanted to add that there is also a bandwidth limitation for the speed you have there.
You have a very low acceleration value compared to your max speed. You will never reach desired speeds, and the system is constantly accelerating and decelerating. On a distance of 100 mm, you only will reach the top speed in 60% of the area. And since you are sending new values all the time, this might block the planner (though I don’t know the internal computation methods there). GCode clustering should help a bit (as you noticed) but might still not be enough.

Check these calculations (sheet coming from FluidNC developers), which deal with the available bandwidth of 115200 baud and the required data to send via serial line. As you can see, the theoretical maximum is about 6000 mm/min, where data exceeds the communication bandwidth. It might be that the better processor in an ESP32 can help here, but the serial communication will stay a bottleneck. I put in the data of your machine as from the first post. Though, gcode clustering will help to reduce the number of bytes per dot, so this might not be not that dramatic in your case.

cggorman · February 16, 2024, 8:50am

@misken , does that take overscan into account? Wouldn’t be a huge difference, but I run a 10% overscan and lower accel on one of may machines because it takes a few milliseconds for the belts and gantry to stop ringing after a Y move.

misken · February 16, 2024, 9:06am

The calculation in the first picture is just a general acceleration calculator, it doesn’t take any overscan into account. Just use it as you do, that’s exactly the use case for it.

But overscan only applies to the acceleration. The data transfer limit is not affected because the acceleration and deceleration phase should only be a single gcode command, so not much data to transfer.

Maybe to add: I don’t want to say this is the issue here, just bring that onto the radar that sometimes the cause is somewhere else

cggorman · February 16, 2024, 9:36am

Understood. Wouldn’t you be able to somewhat accommodate overscan by adding distance to the axis length? I understand that won’t impact comms bandwidth but may be informative for a speed/size/accel relationship. Just thinking out loud.

kmalu87 · February 17, 2024, 4:45pm

First of all, great discussing points on root causes to figure this issue out so appreciate everyone’s responses here!

I tried your file you sent me and mine at 9000mm/min @254DPI and still no good - it behaves the same way, just slower.

I also tried reducing the speeds to 6000mm/min on both files and same, stutters but at lower speeds. I further tried reducing the speeds to 3000mm/min and still no difference. As for acceleration parameter, I tested my machine north of 3000mm/sec^2 acceleration and my machine is now set to this values since motors didn’t stall. This way I get top speed in 90% of the area. This high acceleration combined with lower speeds of 3000mm/mm didn’t seem to make any difference either - just stutters at lower speeds. These tests, also performed with 10% over-scanning as @cggorman was alluding to and still makes no difference.

Like I said above, I still saw stuttering for this file too… only difference being, it didn’t stutter in the “lighter shades” so say about 20-30% of the way but as the shade gets darker, it starts to stutter the same way again. My guess for this behavior is that the greyscale is simply stretched out a bit compared to my file and so I am visually seeing it move at high speeds for a bit longer but probably its behaving the same way overall and stuttering is likely coming from change in power levels.

As to this setting, I actually had it set to 255ms initially where my stepper motors were engaged all the time even when idle, I was getting the same issues. Although GRBL “recommends” for values between 0-255, I set it to 15000ms as after a job is done, the steppers would be disabled after 15sec from when it first idles. motors however enabled again automatically if I jog the machine or if I send it a new job. I preferred this setting since its easier for me to move the machine axes manually so that I can change out tools (laser to router, etc.). But like I said, having the motors enabled all the time with setting value to 255 made no difference.

What I like with all of your suggestions is that troubleshooting is being done with process of elimination but I worry, may run out of options to test. however, confident that experts like yourselves will provide with additional areas to look into so looking forward to that.

cggorman · February 17, 2024, 5:03pm

I didn’t realize grbl allowed stepper idle values over 255. I’ll have to try that myself as, like you, I prefer a long delay but not always energized.

kmalu87 · February 17, 2024, 5:17pm

Yeah! Same here. Also helps with keeping the drivers cool when I have really long idle times or sometimes when I forget to turn off the machine