tinyg interprets G2/G3 code incorrectly

Home › Forums › TinyG › TinyG Support › tinyg interprets G2/G3 code incorrectly

Tagged: , , , , , ,

  • This topic has 35 replies, 8 voices, and was last updated 6 years ago by Vex.
Viewing 15 posts - 1 through 15 (of 36 total)
1 2 3
  • Author
    Posts
  • March 29, 2017 at 8:42 pm #10323
    jf5514
    Member

    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, 8 months ago by jf5514.
    March 29, 2017 at 9:26 pm #10325
    cmcgrath5035
    Moderator

    Welcome 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 #10326
    jf5514
    Member

    I 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 #10327
    cmcgrath5035
    Moderator

    For 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 #10331
    jf5514
    Member

    If 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 #10571
    jamesdjadams
    Member

    I 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 #10572
    cmcgrath5035
    Moderator

    Is there any way to isolate the area of Gcode that misbehaved?

    September 29, 2017 at 5:10 pm #10591
    jooher
    Member

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

    • This reply was modified 7 years, 1 month ago by jooher.
    • This reply was modified 7 years, 1 month ago by jooher.
    September 29, 2017 at 5:31 pm #10594
    jamesdjadams
    Member

    The 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 #10595
    jooher
    Member

    Having 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 #10596
    jooher
    Member

    By 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 #10597
    cmcgrath5035
    Moderator

    jooher – 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 #10598
    jooher
    Member

    Yes, 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 #10614
    jooher
    Member

    UPD: 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 #10615
    cmcgrath5035
    Moderator

    Perhaps, 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.

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 36 total)
1 2 3
  • You must be logged in to reply to this topic.