Home › Forums › TinyG › TinyG Support › tinyg interprets G2/G3 code incorrectly
- This topic has 35 replies, 8 voices, and was last updated 5 years, 11 months ago by Vex.
-
AuthorPosts
-
March 29, 2017 at 8:42 pm #10323jf5514Member
I’m using Chilipeppr and Fusion 360 to generate gcode with a tinyg v8 with fm 440.20.
The issue I am having seems to be related to the g2/g3 command. Sometimes it will be cutting fine and then instead of cutting an arc it will cut an entire circle ruining the workpiece. After this circle is complete it will continue to cut correctly and not losing its position.
One interesting thing I have found is that even though the line is displayed correctly on the Chilipeppr GUI the cutting tool indicator in chilipeppr follows the incorrect movement.
If I rerun the same gcode the same movement occurs. The toolpath is visually correct in chilipeppr and fusion.
I have seen this issue several times with different gcode and it seems to be happening more and more frequently.
I have successfully run the code with the “use radius” option in fusion. That really isn’t a solution though, more of a workaround. Any help would be appreciated. Thanks.
One of the lines from below seems to be the cause.
X-51.632 Y29.758 I0.89 J-0.507
G2 X-51.651 Y29.234 I-7.36 J0.003
G3 X-51.758 Y26.233 I41.556 J-2.979
X-51.583 Y23.235 I26.014 J0.014
X-51.452 Y22.228 I39.618 J4.619
X-51.182 Y21.437 I2.211 J0.315
G2 X-50.682 Y19.48 I-3.316 J-1.889
G3 X-49.277 Y18.027 I1.427 J-0.025- This topic was modified 7 years, 7 months ago by jf5514.
March 29, 2017 at 9:26 pm #10325cmcgrath5035ModeratorWelcome to the world of ambiguity.
There are long standing issues with arcs, how they are to be interpreted and implemented, based in G code ‘standards’.
More importantly to this discussion, there are implied ‘rules’on arc implementations that are often bypassed (IGNORED) by interpreters such as the 3D viewer in Chilipeppr.
TinyG implements/enforces some precision rules that some Gcode generators don’t implement.For best results with tinyG, use mm mode Gcode, rather than inch. Inch to mm conversion, internal to tinyG, can break some of these rules.
March 29, 2017 at 9:36 pm #10326jf5514MemberI switched to mm mode from inches about a month ago and it seemed to help some of the previous occurrences but with this one, I was using mm.
What have others done to mitigate the chances of ruining a potentially expensive workpiece? On shorter cuts I run a test piece first but this is not always possible due to time constraints.
Also, it seems (I could be wrong in this) that it happens more frequently when doing helix motions. I tried using plunges and in the one particular file I tried this for it seemed to help. Using a plunge operation is not always possible but just one thing I tried…
One more question…has this issue come up when using radii instead of the i and j command? This seems to have helped me in the past but I don’t want to build a false confidence.
Thanks for your help.
April 1, 2017 at 5:45 am #10327cmcgrath5035ModeratorFor some, transitioning away from G2/G3 to all linear moves has helped. On very complex jobs, the Gcode file sizes get very large, often hitting the limits that Chilipeppr can handle. Some Gcode generators have a ‘no arcs’ option, I am not sure about Fusion360.
Try a Google search on ‘tinyG helix’, you see several recent threads and discussion of Fusion360 post-processor tweaks.
I have no first hand experience with helix motion, but would say that logically, complex motion (arc moves) in 3D (x-y-z) would be more likely to find bugs than would just 2D (x-y) motion.
If you do find a ‘cure’ that works for you, please report back and share it. We have had several threads of this type that just go silent.
April 4, 2017 at 7:50 am #10331jf5514MemberIf I come up with something that works I’ll get it posted and update this thread. The “use radius” option in Fusion 360 so far has been the best solution I’ve come up with but will continue to try new things as I encounter this issue in the future.
September 23, 2017 at 5:14 pm #10571jamesdjadamsMemberI just experienced the same problem. After 12 1/2 hours of milling a beautiful piece of red oak… a “random” perfect circle. How frustrating.
September 24, 2017 at 10:17 am #10572cmcgrath5035ModeratorIs there any way to isolate the area of Gcode that misbehaved?
September 29, 2017 at 5:10 pm #10591jooherMemberThe problem seems to be with clockwise misinterpretation. I tried to add this line
clockwise=!clockwise
as first line to onCircular and the wrong arcs came to their exact right shape. But other arcs, respectively, broke up.
September 29, 2017 at 5:31 pm #10594jamesdjadamsMemberThe same thing happened again to me last night. I was able to avoid the problem on a second attempt by using jf5514’s work around using the “use radius” option in Fusion 360. Of course by using this option the milling process takes much longer… I like the TinyG V8 and all that you guys are doing but I don’t like this.. Ugg.
September 30, 2017 at 4:16 am #10595jooherMemberHaving noticed, that clockwise is only misinterpreted for arcs in ZX plane, i made a small dirty hack to the post processor, that seems to work: in two places of the tinyg.cps i changed
gMotionModal.format(clockwise ? 2 : 3) ==> gMotionModal.format(!clockwise ? 2 : 3)IMPORTANT: make sure to only make this change for case PLANE_ZX: that is, in lines 715 and 729
Or, get updated tinyg.cps here: https://yadi.sk/d/DVg4cdUc3NLm8h
September 30, 2017 at 4:27 am #10596jooherMemberBy the way, “use radius” actually was NOT a solution for this problem – it does NOT make the arc “correct” – it only makes it “less obviously wrong”: it is not a weird circle anymore, but its direction is still wrong – concave instead of convex and vice versa. My fix from previous post solves this.
September 30, 2017 at 6:03 am #10597cmcgrath5035Moderatorjooher – Just for clarification for other viewers, your post at https://yadi.sk/d/DVg4cdUc3NLm8h is a fork of the tinyG Post Processor for Fusion360 with changes you implemented per the above description, correct?
Thanks for documenting
September 30, 2017 at 6:09 am #10598jooherMemberYes, it is a stock tinyg.cps from Fusion360 with two upfated lines of code, as described in my previous post
October 6, 2017 at 3:34 pm #10614jooherMemberUPD: I just got my DUE card, programmed it in Chilipeppr, and launched simulation. Tool tracking shows that the tool goes not along lines in Chilipeppr’s preview!!! The DUE’s program interprets G2 / G3 exactly as intended in the stock post-processor. So the bug was NOT in tinyG.cps, but in Chilipepper 3dpreview widget. Arrgh…
October 8, 2017 at 7:32 am #10615cmcgrath5035ModeratorPerhaps, but do be aware that at any point in time tinyG and G2core may or may not be the same code/algorithms.
There is a chance that in G2core $fb=100.26, the most recent builds, some additional tweaks to the ‘gCode to motion’ code have been made.
This is a long standing issue, with roots in interpretation of gCode implementation ‘rules’ used by the generators (e.g. Fusion) and the interpreters, e.g. tinyG or G2. Compute accuracy may also have a play here (8bit vs 16 bit).
But good to see you are making progress. -
AuthorPosts
- You must be logged in to reply to this topic.