Polar kinematic. Feedrate and go to G0 X0 Y0 after program executing

[Melkiyby]

Hi, Terjeio! After much testing, I discovered three bugs:

1. If, when executing a CNC program, the rotary axis made many revolutions in one direction, then when executing G00 X0.0 Y0.0 F3000, the rotary axis rotates in that direction the number of revolutions it made when executing the program, and if there were a lot of revolutions, it will not always return to its original position.
2. There is not enough feedrate scaling to maintain the correct cutting mode depending on the position of the X axis from the center of the rotary axis. At the moment, the closer the X axis is to the center, the slower the movements occur.
3. And the feedrate does not correspond to the feedrate specified in the grbl settings, for example, in my settings F3000 for XY, in the program for each movement F3000 is indicated, but only half the speed is visible, when turning G00 X0 Y0 F3000 the feedrate increases.

In the first video, the program makes 20 revolutions and when the axes return to 0, the turntable rotates the same 20 revolutions. You can also observe a problem with the feed rate. 20 revolutions
In the second video, I manually move the X axis by 1mm and the turntable again rotates 20 revolutions in the same direction, and when the x axis subsequently returns to 0, the turntable again rotates in the same direction. Moving after return to zero

[terjeio]

1. What is "many revolutions"? grblHAL uses single precision floating point math and may run into issues if movements are very long.
2. Is this with G0 movements? G0 does not use the programmed feedrate and no scaling is performed during motion - the feedrate is set to max as configured by settings. G1 behaves the same?
3. See above.

First video: what do you expect the motion to be?
Second video: Sorry, I do not understand this. It may help if you post the gcode.

[Melkiyby]

Here is my gcode
blinnew.txt
And video

[terjeio]

The feedrate issue is hopefully fixed.
The 20 revolutions issue is a harder one - and I have given up on that for now. The problem is that when crossing the 0 degree angle the step count, planner position and the position known by the kinematics code should (?) be reset to either 0 or 360 depending on the direction. This is not easy to do since these does not change in sync.
If someone else that is better at math than me is willing to look into how to tackle this issue then go ahead!