arcs and number formats #15
Comments
|
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 <
[email protected]>
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
<#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>*
|
|
David, |
|
Hiya Fusion has this formula for infeed and outfeed arcs that creates very small radii and that is where GRBL chokes UNLESS (b) is a weird one. if you diff against my current code you will see 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. |
|
ok - take a look at my suggestions at the end of this thread
#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 <
[email protected]>:
… 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
<#15 (comment)>,
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>*
|
|
yes, it was always failing for me when X or Y was omitted if memory serves. 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. 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). |
|
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 <
[email protected]>
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
<#15 (comment)>,
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>*
|
|
Hiya |
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 (-:
The text was updated successfully, but these errors were encountered: