Strooom/GRBL-Post-Processor

arcs and number formats

Opened this issue · 7 comments

swarfer commented

Hi Strooom
This issue
https://forums.autodesk.com/t5/fusion-360-computer-aided/contour-takes-off-on-tangent-g03-but-not-on-similar-pocket/m-p/7641509/highlight/false#M41174
is my fault because you merged my changes some time ago.

I believe I have fixed it in my repo
https://github.com/swarfer/GRBL-Post-Processor
by making every move use an extra digit (no difference between normal moves and arc moves)
and by
restricting arc moves to the G17 (XY) plane. The test file I was using had very small arcs as lead in moves in the ZY or ZX planes and Fusion does not handle them well at all. This is solved by linearizing them to line segments.

The main problem was that when generating arcs it was using N decimal places for the initial position move (a G0 or G1 to the start of the arc) and then N+1 decimal places for the arc move itself.
That roundoff of the initial position is what causes the error 33 from GRBL since for small arcs the % error is large enough to trigger the error.
If it used N+1 places for start point move all would be well but when that move is made we do not know that the next move is an arc. (Maybe there is a way to look ahead?)

I also did this
minimumCircularSweep = toRad(0.1); // was 0.01
which helped to reduce errors in small arc generation.

I may have made other changes that I cannot recall now so maybe you should do a full diff (-:

Strooom commented
Strooom commented

David,
I am doing a new iteration of the Openbuilds postProcessor.
Can you refresh my memory as to what you where missing and why you added xaOutput..
It seems having different formatgroups for arcs and linear is not a good idea, so I want to get rid of them.. Let me know what problems you had with my original version, and I'll try to find a clean solution in the next one. thanks.

swarfer commented

Hiya
short version : you can remove the arc output formats.
long version: all the number outputs should be the same length and have to be longer than you think.

Fusion has this formula for infeed and outfeed arcs that creates very small radii and that is where GRBL chokes UNLESS
a) there is enough precision (4 to 6 digits depending on metric/imperial)
b) all axes are forced to be output before and during the arc command.
c) prevent arcs on planes other than G17.

(b) is a weird one. if you diff against my current code you will see
[code]
xaOutput.reset();
yaOutput.reset();
[/code]
in onCircular() which forces the next output to have all axes in it. While GRBL docs say it does not mind if
X or Y is missing from a G2/3 in practice it fails.

right now I am not sure I have committed the latest version from the Fusion laptop, I will check tonight and get back to you.

Strooom commented
swarfer commented

yes, it was always failing for me when X or Y was omitted if memory serves.
but one failure among many arcs still has the same solution = always output both X and Y which is done by the reset call.

My post always works in its current form. I have a test object (that someone on a forum sent me) that was consistently throwing errors on the small vertical arcs.
Then I drew a small plastic guide block for my friends hot wire cutter and it gave me more errors.
This generates Gcode tuned to run on my Openbuilds OX with a Dremel as the spindle so cuts are shallow. That is when I added those resets I think.

oh, just thought that maybe bCNC is changing the Gcode in some way, though I would not deliberately let it do that. (because UGS filtering lines of Gcode is what causes a lot of forum questions).

Strooom commented
swarfer commented

Hiya
Here are the 2 designs
This one generates faulty arcs along the edges of the ovals
https://a360.co/2LAWq08
This one generates faulty arcs in the small slot
https://a360.co/2NUDVjM