Feedrate meaning and GRBL stops

I don’t know if somebody mentioned this. If I use G21 (mm) mode, the feedrate seem to be expressed in mm per second, not in mm per minute. I did timing on 30 mm slot cutting with feedrate F1 with command:

G1 X30.0 F1

The motion takes exactly 30 seconds, and not at crawling speed of 30 minutes as some might expect. Trying to put feedrate less than F1, e.g. F0.5 results in the same speed of 1 mm/sec.

Am I doing something wrong here?

It was discovered anything slower than F45 results in about F45 feedrate – all the same speed.

Perhaps, there is a limit in GRBL code. It’s very strange, as the header file specifies:
#define MINIMUM_FEED_RATE 1.0 // (mm/min)”

Maybe inventables modified it before compiling and shipping?

There is a minor bug in Grbl that causes it to move no slower than 45mm/min on XCarve with default settings. The explanation of why this occurs is complicated and has to do with AMASS, the 16-bit timer, and the steps/mm setting. I think I wrote explaining this somewhere in the source code. In short, the current fix is to disable Grbl’s AMASS via config.h, if you need to move slower than 45mm/min.

However, with CNC milling, you’ll never be moving this slow. So far, this has only shown up as a problem with super slow motions in certain laser tool paths.

1 Like

So I’ve read about that issue and commented out

//#define ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING

Upon the upload, the slow speeds, down to 1 mm /min, can be specified. However, run into another problem:after executing several commands, GRBL stops responding. It looks like it selects a zero step someplace, then sits in endless loop, doing nothing.

First, is there a particular need for running the machine at 1mm/min? Or are you just testing it out?

Second, there shouldn’t be a locking problem, but I’ll check it out. Can you tell me the steps you take so I can reproduce the problem? Is this only at very slow speeds? And do you have anything non-standard in your system? like a chinese Arduino?