I don’t know if it is a bug or not,
I’m running the latest version from a day or two ago.
When I engrave a circle or an arc with the use of the rotary A-axis, it seems as if the A-axis feedrate is calculated on the feedrate of the X-axis.
So when the X-axis moves fast, the A-axis moves fast.
When the X-axis almost comes to a stop, the A-axis almost comes to a stop.
So I’m burning through in the middle sections of the circle, while on the top and bottom I’m missing something. Like ( )
Is this by design?
Does anybody know how to solve this? Maybe a setting I’m missing?
[Grbl_Esp32 Issue#502] Slow circles and arc cutting with rotary A-axis
-
![[gnea/grbl-Mega Issue#1] $ command extentions](https://www.grblhal.com/wp-content/themes/gitphp/timthumb.php?src=https://www.grblhal.com/wp-content/themes/gitphp/assets/img/pic/8.jpg&h=110&w=185&q=90&zc=1&ct=1)
[gnea/grbl-Mega Issue#1] $ command extentions -
[gnea/grbl-Mega Issue#2] Better interrupt priorities -
[gnea/grbl-Mega Issue#3] ATMega16U2 virtual com port on ATMega2560 -
![[gnea/grbl-Mega Issue#4] Real-time adjustable feedrates](https://www.grblhal.com/wp-content/themes/gitphp/timthumb.php?src=https://www.grblhal.com/wp-content/themes/gitphp/assets/img/pic/10.jpg&h=110&w=185&q=90&zc=1&ct=1)
[gnea/grbl-Mega Issue#4] Real-time adjustable feedrates
- [gnea/grbl-Mega Issue#1] $ command extentions
- [gnea/grbl-Mega Issue#2] Better interrupt priorities
- [gnea/grbl-Mega Issue#3] ATMega16U2 virtual com port on ATMega2560
- [gnea/grbl-Mega Issue#4] Real-time adjustable feedrates
- [gnea/grbl-Mega Issue#5] question about the download zip contents
- [gnea/grbl-Mega Issue#6] Adding outputs for external state signals
- [gnea/grbl-Mega Issue#7] which g-code sender is being used in grbl-Mega testing?
- [gnea/grbl-Mega Issue#8] Frecuencia y velocidad de avance.
#1 – joedirium 于 2020-08-27
As a test you might try to use G01 command sequences instead of G02/G03 commands to see if the problem is part of the arc implementation or generally related to speed management.