Known Bugs

This wiki is intended to provide information on known bugs. Please feel free to contribute more known bugs and their work arounds as they are discovered. When a bug is fixed, they will be removed from this list.

• Grbl seems to be taking extra steps before it comes to a stop:

• Grbl is actually taking extra steps to get to the final intended position. This has been a hard to diagnose problem, but it most likely attributed to Grbl very very slightly undershooting the deceleration curve, so it arrives at the destination too early. If it does, it'll move at a set minimum step rate to finally get there, which is about 10 steps per second or so. This seems to only occur on certain setups, but the number of extra steps doesn't seem like more than a handful when noticed. If you are experiencing more than just a handful or it's gotten to beyond annoying, please let us know and we'll try into figure out what's going on. A lot of work has already been done to minimize this, but it seems like it might be inherent to how the planner and stepper module was designed. Grbl v0.9 will be re-writing this code to install feedrate overrides. It's intended to try to nail down and solve this problem at that point.

• **Grbl make a thunk sound at the end of an acceleration, right before cruising. Usually when going fast: **

• This is the same issue as one above, except dealing with the acceleration curve being slightly inaccurate and reaching the planner-computed cruising stage before it's suppose to. This can lead to an audible sound and sometimes can lead to lost steps. This usually occurs and is noticeable when running at very high step rates (20kHz+) because stepper motor torques drop and is more susceptible to lost steps. This is planned to be fixed in Grbl v0.9. The current solutions are to simply run at slow step rates, to increase the stepper driver voltage, and/or lower the microstepping or perform full steps.

• When manually entering moves, like for jogging, Grbl sometimes skips steps:

• This is caused by entering a move right before the previous move completes. Grbl's planner computes when to end an acceleration and when to start a deceleration for each new motion block it receives. If when you enter a new move, the planner will recompute the buffer. Right now, there isn't an internal lock to prevent the planner to re-write the plan for the block being executed. So there can be instances where this new plan can effect the currently executing move, especially when decelerating. But, this was originally done to ensure when streaming that first block will be planned with the rest of the program correctly. Anyhow, this is slated to be fixed in v0.9. If your machine is particularly susceptible to this error, just wait until a move completes before entering a new one or enter them when you know there is more than one move in the buffer already.