Low feed rates result in incorrect speeds of the moving gantry

I’m using Easel to control an X-Carve with an X-Controller. I’ve noticed that when the speed rate is low (e.g., 10 mm/min) the actual speed of the gantry is off. Here’s what I’ve observed…when I cut a square with 25mm sides (100mm of total cutting distance) and set the cutting feed rate to 100mm/min, it takes 1 minute to finish the cut (1 pass). If I change to a square with 12.5mm sides and set the feed rate to 50mm/min, it takes 1 minute. However, if a try to cut a square with 10mm sides and set the feed rate to 40mm/min, the cut is done in less than a minute (53 seconds). If I go even smaller with a square that has 2.5mm sides and set the feed rate to 10mm/min, the cut finished in 13 seconds. I don’t understand what’s going on here. Can anyone explain? Thanks in advance for any help.

The size of your bit is included in the cut distance. The shorter the cut the greater percent is covered by the diameter of the bit.
That is my guess.

Thanks for the input. I purposely chose a 1/32" bit for these test runs. On a square that’s 5mm/side, I think the diameter of the bit would be a small percentage of the overall length of cut (e.g., 20mm) while the feed rate is <50% of what would be expected (26 sec versus 60 sec).

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.

Essentially if you want to go slower than 45mm/min you need to adjust the microsteping switches within the xcontroller and then adjust the $100 101 accordingly

Yes…I see from the information I posted earlier that I need to “disable AMASS in config.h”. My problem is I don’t if that’s doable with the X-Controller and, if so, I don’t know how to do it. Is there anyone here who can provide some guidance? Thanks, in advance, for any help!

The config.h is part of the basic grbl file that is flashed into your arduino chip.

There are videos on how to flash the grbl, you’d just need to modify the configuration file first…

OR you could alter the dip switches inside the xcontrolle used for microstepping and then use a higher $100, and $101 grbl setting and that is less involved than modifying the config.h file :man_shrugging::man_shrugging:

Another option is to get a gear add on for the steppers to output a smaller amount per turn, like a 5 to 1 or better output…

1 Like

Thanks! I’ve learned that the latest version of GRBL allows for the real-time over ride of feed rates. It involves sending extended ASCII commands to effect the over ride. To decrease the feed rate by 10%, “0x92” Hex or Decimal 146, which is right single quotation mark, has to be sent. Not sure how to send that using Easel???

After a little more thought, I think I’m going to follow the suggestion to modify the X-Controller dip switches and try 1/16 microstepping. If I’ve read the board correctly, that means Switches 1 and 2 are “on” and 3 is off. I hope I don’t destroy my controller doing this.

1 Like

Doing that won’t destroy the board… as long as it’s unplugged during he change :flushed:

Just make sure to adjust the $100, 101 and if your also changing the z $102 . . Accordingly

1 Like

I appreciate the help and encouragement. I’ve changed my mind again and decided to try the edited config.h file approach. I downloaded the most recent fork of GRBL on Github, found the line implementing the AMASS algorithm and commented it out. I will follow Inventables’ instructions on how to flash the X-Controller. I’ve worked with the Arduino IDE before so that should be straight-forward. Just wondering…when I get to the step of adjusting $100, $101 and $102, am I likely to be increasing those values or decreasing them??? Just a reminder…my goal is to slow the feed rate down so I actually get a feed rate that’s 5 mm/min.

Son of a gun…re-flashing GRBL using an edited config.h file (e.g., commenting out the AMASS algorithm in Line #301 of the config.h file) was the solution! I had to increase the X-max and Y-max speeds, but no other machine settings were needed. When I homed my machine it was quite slow, so I may increase the homing speeds, but the machine is running as needed now. I can now get my X-Carve down to 5 mm/min which is what I need for the metal cutting I have planned. Thanks to all here who helped me with this!

Unfortunately, the change in the config.h file somehow messed up how my laser works. Now, it pulses on and off instead of staying at full power. Therefore, not much of a cut.

OK…I tried the other 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. Maybe there’s an alternative to GRBL to control the X-Carve???

Well most people running lasers are not going at half the speed of frozen molasses you could redesign the cnc and use a gear to further reduce the speed of motion…

Yeah…I’ve thought about gear ratios, but I was hoping for some kind of electronic/firmware solution. I may just have to settle for making multiple passes.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.