arcs and number formats

[swarfer]

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]

Ok, tnx for your msg. I'll do a review and correct/improve if possible.

P

Op do 21 dec. 2017 om 19:32 schreef David the Swarfer < notifications@github.com>

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 (-:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Strooom/GRBL-Post-Processor/issues/15, or mute the thread https://github.com/notifications/unsubscribe-auth/APqnZWud2ysfic82RF5_0IYWoB77OndGks5tCqRAgaJpZM4RKMX1 .

-- Met vriendelijke groeten

Pascal Roobrouck

---

Instructables https://www.instructables.com/member/strooom/ | Github https://github.com/Strooom | Twitter https://twitter.com/strooom

[Strooom]

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]

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]

ok - take a look at my suggestions at the end of this thread https://github.com/Strooom/GRBL-Post-Processor/issues/17

While GRBL docs say it does not mind if X or Y is missing from a G2/3 in practice it fails.

do you mean it always fails, or sporadic ? I have plenty of examples where it works without X and Y both being present... I see that the initial G2 G3 has both axis, but subsequent arcs (not repeating the G2 G3) are omitting X or Y (and I or J) and they do work.. Do you have more links towards this X or Y missing in G2 G3 issue ?

thanks

Op wo 25 jul. 2018 om 13:07 schreef David the Swarfer < notifications@github.com>:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Strooom/GRBL-Post-Processor/issues/15#issuecomment-407718113, or mute the thread https://github.com/notifications/unsubscribe-auth/APqnZZ3qQVDogaLatU5RvmPSrlfwQu7-ks5uKFFsgaJpZM4RKMX1 .

-- Met vriendelijke groeten

Pascal Roobrouck

---

Instructables https://www.instructables.com/member/strooom/ | Github https://github.com/Strooom | Twitter https://twitter.com/strooom

[swarfer]

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]

Could you share the fusion designs which consistently throw the error? It's easy to make a G/G3 always output all axis and offsets, but I think the error originates somewhere else and I'd rather cure it at the root cause.

P

Op zo 29 jul. 2018 om 14:03 schreef David the Swarfer < notifications@github.com>

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).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Strooom/GRBL-Post-Processor/issues/15#issuecomment-408671675, or mute the thread https://github.com/notifications/unsubscribe-auth/APqnZStKyYz8yG0cmk6K5iom3BDVt2kaks5uLaR5gaJpZM4RKMX1 .

-- Met vriendelijke groeten

Pascal Roobrouck

---

Instructables https://www.instructables.com/member/strooom/ | Github https://github.com/Strooom | Twitter https://twitter.com/strooom

[swarfer]

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