TinyG not following simulated toolpath (G2/G3 issue?)

Home › Forums › TinyG › TinyG Support › TinyG not following simulated toolpath (G2/G3 issue?)

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • October 15, 2018 at 12:08 pm #11168
    Gcodeman
    Member

    Hello all

    I am running a Shapeoko with TinyG FW 440.20

    Please see my reddit post here for pictures and background: https://www.reddit.com/r/hobbycnc/comments/9o5e09/cnc_making_errant_cut_at_end_of_job_not_matching

    With the help of some others on Reddit I’ve learned that the G2/G3 codes being produced by Fusion360 are being interpreted by TinyG differently than what I am seeing in toolpath simulation software. I’ve simulated my code in Fusion360, Camotics, an online simulator on GitHub, and Chilipeppr and none of these programs show a large arc being cut but my workpieces are being ruined.

    Can anyone help me understand why TinyG is doing this? Does it have something to do with my post-processing?

    When I read the last ~100 lines of code I see a number of small helical plunge moves but there are one or two lines with I and J codes with large numbers and I suspect this will happen again if I attempt to re-do the job.

    Here are the last few lines in the code:
    X126.794 Y109.926 Z-10.977
    X126.857 Y110.137 Z-10.985
    X126.905 Y110.351 Z-10.992
    X126.937 Y110.568 Z-11.
    G3 X125.323 Y112.614 I-1.846 J0.203
    G1 X121.951 Y113.039
    G3 X120.007 Y110.476 I-0.232 J-1.843
    X123.199 Y110.074 I1.712 J0.72
    X123.559 Y110.94 I-1.48 J1.122
    G2 X123.988 Y112.657 I8.206 J-1.141 F1400.
    G3 X123.015 Y113.824 I-0.824 J0.303
    X122.768 Y113.743 I0.15 J-0.865
    G2 X121.9 Y113.354 I-4.471 J8.838
    X121.008 Y113.022 I-11.065 J28.338
    G3 X120.179 Y109.998 I0.639 J-1.801
    G2 X120.708 Y109.246 I-4.337 J-3.61
    X121.125 Y108.426 I-6.603 J-3.878
    G3 X121.336 Y108.111 I0.969 J0.422
    G2 X122.024 Y107.305 I-5.781 J-5.626
    G3 X123.36 Y107.456 I0.624 J0.461
    X123.424 Y107.765 I-0.712 J0.31
    G2 X123.491 Y110.236 I48.365 J-0.078 <—-this looks to be the problematic spot
    X123.559 Y110.94 I8.273 J-0.437
    X125.947 Y112.694 I2.047 J-0.285
    G3 X127.694 Y114.816 I0.261 J1.565
    X127.45 Y115.248 I-1.486 J-0.556
    G1 X126.429 Y116.53
    X126.245 Y116.75
    X124.861 Y118.177
    G3 X120.577 Y116.438 I14.768 J-42.546
    G2 X117.441 Y115.304 I-10.751 J24.811
    G3 X114.356 Y114.307 I57.499 J-183.135
    G2 X115.333 Y112.186 I-7.753 J-4.853
    G3 X116.4 Y110.134 I4.912 J1.251
    X118.03 Y107.289 I7.048 J2.15
    X119.242 Y105.444 I4.489 J1.628
    X121.088 Y103.205 I8.754 J5.339
    X122.341 Y101.376 I4.078 J1.449
    G2 X124.19 Y99.709 I-7.107 J-9.739
    G3 X127.029 Y98.472 I2.836 J2.635
    G1 X127.147 Y98.436
    X127.262 Y98.393
    X127.504 Y98.294
    X127.586 Y98.258
    X127.667 Y98.218
    X127.746 Y98.174
    X127.847 Y98.116
    X128.059 Y98.077
    X128.146 Y98.059
    X128.231 Y98.037
    X128.316 Y98.011
    X128.78 Y98.008
    X128.87 Y98.005
    X128.96 Y97.998
    X129.05 Y97.987
    X129.314 Y97.948
    X129.404 Y97.932
    X129.492 Y97.913
    X129.58 Y97.89
    X129.69 Y97.857
    X130.01 Y97.858
    G2 X127.162 Y104.542 I13.859 J9.853
    X127.667 Y113.301 I15.638 J3.493
    G1 X127.918 Y114.309
    X127.933 Y114.366
    X127.982 Y114.537
    X127.518 Y115.162
    X127.45 Y115.248
    X127.403 Y115.3 Z-10.992 F1200.
    X127.35 Y115.347 Z-10.984
    X127.296 Y115.387 Z-10.961
    X127.237 Y115.42 Z-10.937
    X127.182 Y115.444 Z-10.899
    X127.125 Y115.463 Z-10.861
    X127.027 Y115.483 Z-10.761
    X126.951 Y115.487 Z-10.641
    X126.904 Y115.485 Z-10.506
    X126.889 Y115.484 Z-10.365
    G0 Z15.

    M9
    Z15.
    M30

    October 15, 2018 at 12:09 pm #11169
    Gcodeman
    Member

    I should add – this problem occurs at the end of a 1.5 hr job with a lot of other helical plunge moves all using G2 / G3. This particular code snippet is at the end of 27000 lines of code that cut with no issues.

    October 15, 2018 at 6:33 pm #11170
    cmcgrath5035
    Moderator

    Large I or J can be problematic, as you suspect.

    Jobs run in metric (mm) do best ( compared to inch), but I surmise this is already mm.
    A work around can be to turn off arcs and replace them with short G1 moves.
    But your job sounds to be already quite large, replacing G2 and G3 with G1 will likely be a huge Gcode file.

    You could post your post-processor settings here, someone might stop by and be able to comment, I am no help as have not used Fusion.

    You could try Fw 449.01, found here, http://synthetos.github.io/binaries/tinyg-edge-449.01.hex
    No promises,there has been significant work a while back and a universal solution has been elusive.

    It is likely revealing the limits of doing a lot of 8 bit complex math

    October 17, 2018 at 11:43 am #11171
    Gcodeman
    Member

    Thank you for replying. I’ve found a few other forum posts here of people complaining about the same type of thing in regards to G2/G3 moves.

    I’m hesitant to upgrade to the Edge firmware unless I know it’s stable & reliable enough for daily use. I don’t want to introduce other strange issues until I resolve my current issues 🙂

    It seems like a lot of the occurrences about this issue happen under a combination of the same circumstances:

    G2/G3 moves
    Helical plunging
    number rounding errors
    large I & J values

    I may have to try a combination of a few different fixes to see what works. I’ve only run into this issue on one of the projects I’ve cut out of a few dozen, but it’s frustrating that this is not a problem that I can proactively prevent from happening (save for the FW upgrade, perhaps).

    I have compiled a list of strategies found in other threads on this form to maybe avoid this in the future:

    Changes to toolpath generation:
    -always stick with mm rather than Inches
    -avoid helical-type plunges
    -reduce use of toolpath smoothing in Fusion360 so G2/G3 moves are not created if not necessary.

    Changes to post-processing:
    -Force Fusion to create G1 codes in place of G2/G3. cut segments rather than curves
    -modify the post-processor to not create counter-clockwise curves
    -change post-process to always generate 3 decimal points on code
    -Fusion has a setting for “USE RADIUS” which will generage G2/G3 lines with R values rather than I and J values.

    hopefully this is useful to someone else having this issue

    October 18, 2018 at 3:26 pm #11172
    cmcgrath5035
    Moderator

    Good lists as a summary.

    I assume you realize that may of the items listing are really different ways to say the same thing. Helical plunging is a special case of G2/G3 moves, in three dimensions, Slight arcs result in large I,J values.

    Manipulating large numbers will result in the loss of fine precision

    October 20, 2018 at 7:33 am #11173
    cmcgrath5035
    Moderator

    I looked over your code snippet again and see, I think, the Z motion boring is using G1 moves, not G2/G3. tinyG does Arcs in only two dimensions (Xy,Xz or Yz), so this is likely how the post-processor compensates.

    Can you post the entire Gcode to a cloud drive for a look?

    We typically use Camotics as a toolpath simulator, as you did.
    They do not simulate the motion control algorithms and likely run at native (e.g. 64bit) precision.

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