I’m using LB to run a laser module attached to an X-Carve using the X-Controller (GRBL). I wasn’t getting the cutting results I expected at very low speeds (e.g., 5mm/min) so I decided to test the speed settings. When I set a simple move (either X or Y direction) of 10mm at 10mm/min I expected that to take 1 minute. Instead, the move is complete in ~13 seconds. I tested other, higher speeds and found that at or above 50mm/min, the speeds were correct. Below 50mm/min, speeds were off. For example, a 40mm move at 40mm/min took 53 seconds and a 20mm move at 20mm/min took 26 seconds. I’m familiar enough with GRBL to make changes to get distances correct, but I’ve never run into this kind of thing and not sure where to look. Any help will be appreciated!
This is interesting. I’ve never actually timed any of my speed settings so not sure if this is common or not.
I guess my first question would be to ask if your burns are dimensionally consistent with your designs. Is 10 mm in design 10 mm in actual burn?
Have your tests been done with a single simple straight line?
Curious where this goes…
Yes…the distances are correct. I calibrated both X and Y directions before starting any of the cuts. All tests have been done by using the “Move” capabilities of LB. I simply enter the distance and the speed and click on the left or right arrows to make the gantry move. LB tells me the time needed (in seconds) to complete the move. It has to be watched carefully since the time disappears as soon as the move is complete.
Oh. I thought this was for a burn.
Are you saying you’re changing the speed value in the Move window? I suppose this should work fundamentally the same way in either case. I may give this a shot tomorrow to see if I get the same behavior.
Right…no laser cutting during these tests, just moves. However, what prompted all this was a cut that didn’t go well because it seemed to be completed in too little time. I think the speed settings stay the same whether the laser is turned on or not. At least, that’s what I’ve assumed.
FWIW…Using Easel, I tried cutting a square that was 2.5mm on each side and set the cut speed to 10mm/min to see how long it would take and it ended up taking 13 seconds. This tells me that the problem lies in one of the GRBL settings not a setting in LB.
The GRBL controller has an accelerate and decelerate feature in the controller settings and Variable Power applies power reduction when slowing down for corners.
Try 4 boxes, one at 2.5 mm per side, one at 5 mm per side, one at 10mm per side and one at 100 mm per side… all at the same speed.
You should see the same amount of acceleration regardless of the size of the box because the corners will be identical. Once you remove the acceleration effect (4 speed ups and 4 slow downs) you should have a linear relationship between the remaining line length and the commanded speed. You should then be able to estimate/predict the time used to accelerate.
That should make a straight line graph for you. Please do let us know.
I see how the acceleration/deceleration feature would affect drawing shapes, but why does a single straight line that’s 20mm long take only 26 seconds to draw using a feed rate of 20mm/min?
In a forum focused on GRBL, I found the following explanation for what I’m experiencing. Unfortunately, my level of GRBL understanding is not sufficient to fully understand its meaning. Maybe you or someone else here could explain it???
Ok, I’ve located the cause of this issue. It stems from the AMASS algorithm and it only using a fixed prescaler in the main timer. AMASS’ lowest tick rate is ~30 step/sec. This translates to roughly 45mm/min for 40step/mm. There isn’t much I can do to fix this with AMASS due to way it was designed. I was not expecting use cases that requires really slow feed rates.
So the solution is to disable AMASS in config.h, which forces Grbl to use the old timing algorithm, and/or increase the steps/mm of the axes, such that the lowest desired step rate is above 30 steps/sec.
Basically it’s saying they hard-coded some parts of the algorithm that don’t hold true beneath a certain speed. You could remedy this by increasing the resolution of the steppers but then you’d have to change the pulley or belt situation to compensate. Alternatively you could use a different timing algorithm.
I don’t have any use cases where this is a problem but it’s interesting. I don’t see these speeds as particularly low though so it might be that steps/mm are typically higher on CNC machines vs laser. Not sure. But I could see CNC operations being in the 10mm/min range.
You’re right and it’s news to me. This is really interesting. Thank you.
In the config.h file this comment is entered to explain it.
// Adaptive Multi-Axis Step Smoothing (AMASS) is an advanced feature that does what its name implies,
// smoothing the stepping of multi-axis motions. This feature smooths motion particularly at low step
// frequencies below 10kHz, where the aliasing between axes of multi-axis motions can cause audible
// noise and shake your machine. At even lower step frequencies, AMASS adapts and provides even better
// step smoothing. See stepper.c for more details on the AMASS system works.
#define ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING // Default enabled. Comment to disable.
stepper.c has a huge comment in it as to what’s going on. It’s getting late here - I’ll dig into it in the next day or two. Basically at lower frequencies the motion can introduce noise, shake and resonance into the machine and the algorithm slows further to prevent it.
Strange indeed.
I was able to download the latest GRBL from Inventables and edit the config.h file before uploading it via the Arduino IDE. It worked to allow me to slow down the machine, but at the really low speeds (e.g., 5 mm/min) I saw a pulsing of the laser that concerned me. At 10 mm/min it didn’t pulse much at all. It’s probably a workable solution for me.
I tried another approach and switched the X-Controller microstepping from 1/8 to 1/16. I re-flashed with the GRBL from Inventables and got everything going using Lightburn. I changed $100 and $101 values to reflect the new microstepping settings. What I found was that I cut in half the minimum feed rate attainable by the X-Carve. Instead of a minimum being just under 50 mm/min it’s now just under 25 mm/min. However, speed settings below that are off. For example, a move of 10mm at 10mm/min only took 26 seconds to complete. So…this approach is not going to work for me. I may have to see about using a different microcontroller for the X-Carve??? I understand Smoothie works well and doesn’t have issues with low speeds. Maybe there are others???
Have you tried 1/16 microstepping with the ASSM disabled?
Not sure what the issue is with the pulsing but it’s likely a solvable problem. Have you tried this with Constant Power mode disabled? Normally this would get you the opposite of what you want but it’s not clear what’s happening at the low speeds. I’m wondering if PWM frequency is somehow tied to speed. I recall reading something about being able to change PWM in cpu_m.h.
Had a quick look. Not sure but suspect it might be here:
// Prescaled, 8-bit Fast PWM mode.
#define SPINDLE_TCCRA_INIT_MASK ((1<<WGM20) | (1<<WGM21)) // Configures fast PWM mode.
// #define SPINDLE_TCCRB_INIT_MASK (1<<CS20) // Disable prescaler -> 62.5kHz
// #define SPINDLE_TCCRB_INIT_MASK (1<<CS21) // 1/8 prescaler -> 7.8kHz (Used in v0.9)
// #define SPINDLE_TCCRB_INIT_MASK ((1<<CS21) | (1<<CS20)) // 1/32 prescaler -> 1.96kHz
#define SPINDLE_TCCRB_INIT_MASK (1<<CS22) // 1/64 prescaler -> 0.98kHz (J-tech laser)
Might be able to move from 1/64 to 1/32 prescaler. Or even disable? Not sure.
Thanks for the suggestions! I’ll check into them.
Combining the 1/16 microstepping with disabling AMASS showed way less of the pulsing that I’ve observed. I wonder if what I’m seeing is the flashes from new metal being hit by the laser as it moves at a very slow speed??? In any event, I think this combination is a step forward (pun intended). I tried with and without Constant Power Mode and didn’t observe any difference. I think I’m very close! However, I can’t get LB to set a speed of less than 6 mm/min. Any idea of how to get that to go lower?
I also tried editing the cpu_map.h file and it didn’t change anything when going from 1/64 to 1/32. Interestingly, the 1/64 choice is for “J-tech laser”.
Shoot. Well that was just a shot in the dark in case it was related to PWM.
Nice.
I guess nothing is easy at these low speeds.
I just tested this and get the same result. Maybe try setting speed to a very peculiar value… then Saving the Gcode, do a search and replace for all occurrences of that particular F#### value, then try running the Gcode. If that works then perhaps a feature request in order.
Man…I’m learning a lot from how you troubleshoot all this. I created a GCODE file with F33, edited the file and replaced F33 with F5 and am running it now using LaserGRBL. I didn’t know how to open/run a GCODE file in LB, but I will look that up. THANKS!
OK…found the “Run GCode” button…next time!
3 passes at 5 mm/min and I’m just seeing the beginnings of a cut at the bottom of 0.5mm brass. The manufacturer says 1-2 passes, but that’s with a 20mm lens. I’m using a 30mm lens so I think that’s my next change. This is definitely heading in the right direction. Thanks for the help!
there’s a minimum feed rate override and minimum feed rate in Config.h
line 243 #define MIN_FEED_RATE_OVERRIDE 10 // Percent of programmed feed rate (1-100). Usually 50% or 1%
Line 391 #define MINIMUM_FEED_RATE 1.0 // (mm/min)
I’d mess with those next.
Very interesting…thanks!