Skip to content
Sonny Jeon edited this page Oct 14, 2013 · 17 revisions

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 make a thunk sound at the end of an acceleration, right before cruising. Usually when going fast: **

  • This is caused by a computation delay within the stepper algorithm itself in v0.8 or prior. A simple divide to compute the new timer ticks takes about 40 usec, which unfortunately means that when traveling at step frequencies higher than 20kHz or so, that delay can mean a step not firing on time. This can lead to position drifts as well. However, this problem has been rectified in v0.9, as the stepper algorithm has been completely rewritten to avoid any process that takes more than 20-25 usec. Meaning that grbl can support the 30kHz step frequency as advertised.

  • 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 and current development efforts have shown very significant promise and should soon solve this problem once and for all. 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.