Unexpected long linear motion when programming arcs with large radius

[raoullector]

Hi everyone,

I'm using GrblHAL on an SKR3 (STM32H723) and I'm running into a strange and dangerous behavior when programming certain arcs (G02 / G03). Specifically, when the arc center is extremely far from the origin, but the arc covers only a short distance, GrblHAL seems to go haywire and moves in a straight line until it hits a physical limit.

Here are two actual examples that caused this:

1) G00 X832.882 Y653.896  
   G03 X834.943 Y646.164 I8187140.303 J2183231.203

2) G00 X142.235 Y832.114  
   G02 X146.294 Y813.174 I-39806104.512 J-8529899.349

In both cases, the expected travel distance was under 20mm, yet the machine traveled over 500mm in a straight line, crashing into the physical limits.

I understand that programming circular interpolation with such huge radius values may be overkill (a G01 would likely be sufficient), but mathematically the arcs are valid and should be correctly handled.

I found two related issues that seem to match this behavior: #161 and #547.

My questions:

• What is the root cause of this behavior?
• Is there a known numerical limit or precision issue with very large arc centers?
• What kind of rule or heuristic could I implement in my post-processor to catch and prevent this kind of motion?

Thanks in advance for any clarification!

[terjeio]

Your first example runs fine for me, the second causes error 33. Which version (build date) of grblHAL are you running?

What is the root cause of this behavior?

Limited resolution of floats. See this.

Is there a known numerical limit or precision issue with very large arc centers?

Yes.

What kind of rule or heuristic could I implement in my post-processor to catch and prevent this kind of motion?

Output line segments instead of arcs?

[raoullector]

Hi @terjeio ,

Which version (build date) of grblHAL are you running?

I run the Build 20250311.
More importantly, my machine operates at a high step rate (180000 steps / s) which translates physically to high speeds (>40000 mm/minute), with strong accelerations (1500 mm/s2) and high jerk values (300000 mm/s3).

Output line segments instead of arcs?

Yes, that’s exactly what my post-processor does when it detects that a given arc might cause this kind of issue.
For now, the detection is done empirically: any arc with a central angle below 0.004 radians is considered indistinguishable from a straight line segment. This threshold is derived from the overall precision of my machine.

But my current precautionary approach bothers me, because I want to make full use of grblHAL’s capabilities.
What calculation can be done ahead of time to reliably — and non-arbitrarily as I do — determine whether a given arc will trigger the float resolution issue you mentioned in grblHAL?