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 - 16 through 30 (of 36 total)
1 2 3
  • Author
    Posts
  • October 18, 2017 at 11:20 am #10631
    jamesdjadams
    Member

    The modified .cps file is working well for me.

    Has anyone modified it so that it will lift the z-axis to a safe distance before seeking to the start position?

    Thanks,
    -James

    October 21, 2017 at 5:13 pm #10650
    colinsk
    Member

    I have had this problem as well. I am running Firmware .97 and build 440.20. I use Fusion 360 with the stock processor and run in inch mode. I hav found the large circle problem to be intermittent. I have tried going after heat and RF problems with limited success. Yesterday I was able to find a short piece of code the back simulates correctly and fails 100% of the time. It is two holes and the first one just plunges and the second one cuts correctly.

    (BRIDGE PINS TEST 3)
    (18 STRAIGHT)
    (T1 D=0.125 CR=0. – ZMIN=-0.42 – FLAT END MILL)
    G0 G90 G94 G17
    G20
    G53 Z0.
    (BIDGE PIN HOLES)
    M5
    M9
    T1
    M3 S5000
    G54
    M8
    G0 X1.4957 Y-1.6119
    Z0.6
    Z0.0187
    G1 Z-0.0613 F10.
    X1.4988 Y-1.6065
    G3 X1.4741 Y-1.65 Z-0.081 I-0.0124 J-0.0217 F20.
    X1.4988 Y-1.6065 Z-0.1007 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.1204 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.1401 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.1598 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.1794 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.1991 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.2188 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.2385 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.2582 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.2779 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.2976 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.3172 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.3369 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.3566 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.3763 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.396 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.4157 I0.0124 J0.0217
    X1.4821 Y-1.6036 Z-0.42 I-0.0124 J-0.0217
    X1.4908 Y-1.6528 I0.0043 J-0.0246
    X1.4821 Y-1.6036 I-0.0043 J0.0246
    G1 X1.4832 Y-1.6098 F10.
    G0 Z0.2
    X1.925 Y-1.535
    Z0.0246
    G1 Z-0.0554 F10.
    X1.9312
    G3 X1.8812 Z-0.0751 I-0.025 J0. F20.
    X1.9312 Z-0.0947 I0.025 J0.
    X1.8812 Z-0.1144 I-0.025 J0.
    X1.9312 Z-0.1341 I0.025 J0.
    X1.8812 Z-0.1538 I-0.025 J0.
    X1.9312 Z-0.1735 I0.025 J0.
    X1.8812 Z-0.1932 I-0.025 J0.
    X1.9312 Z-0.2129 I0.025 J0.
    X1.8812 Z-0.2325 I-0.025 J0.
    X1.9312 Z-0.2522 I0.025 J0.
    X1.8812 Z-0.2719 I-0.025 J0.
    X1.9312 Z-0.2916 I0.025 J0.
    X1.8812 Z-0.3113 I-0.025 J0.
    X1.9312 Z-0.331 I0.025 J0.
    X1.8812 Z-0.3507 I-0.025 J0.
    X1.9312 Z-0.3703 I0.025 J0.
    X1.8812 Z-0.39 I-0.025 J0.
    X1.9312 Z-0.4097 I0.025 J0.
    X1.9044 Y-1.5101 Z-0.42 I-0.025 J0.
    X1.908 Y-1.5599 I0.0018 J-0.0249
    X1.9044 Y-1.5101 I-0.0018 J0.0249
    G1 X1.9049 Y-1.5163 F10.
    G0 Z0.2

    October 21, 2017 at 5:39 pm #10651
    colinsk
    Member

    I just tried the modified post processor linked earlier in this thread ad for this problem it made no difference.

    October 21, 2017 at 5:48 pm #10652
    colinsk
    Member

    I have also tried switching the cut from climb o conventional to force the G2 code with no luck: (The first hole is a plunge and the second hole is a helix.)

    (TRAVEL GUITAR 18)
    (18 STRAIGHT)
    (T1 D=0.125 CR=0. – ZMIN=-0.42 – FLAT END MILL)
    G0 G90 G94 G17
    G20
    G53 Z0.

    (BIDGE PIN HOLES)
    M5
    M9
    T1
    M3 S5000
    G54
    M8
    G0 X1.4725 Y-1.6275
    Z0.6
    Z0.0187
    G1 Z-0.0488 F10.
    X1.4726 Y-1.6272 Z-0.0516
    X1.4731 Y-1.6264 Z-0.0543
    X1.4738 Y-1.6251 Z-0.0566
    X1.4748 Y-1.6234 Z-0.0586
    X1.476 Y-1.6213 Z-0.0601
    X1.4773 Y-1.619 Z-0.061
    X1.4787 Y-1.6166 Z-0.0613
    X1.4817 Y-1.6112
    G2 X1.4988 Y-1.6065 I0.0109 J-0.0062
    X1.4741 Y-1.65 Z-0.081 I-0.0124 J-0.0217 F20.
    X1.4988 Y-1.6065 Z-0.1007 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.1204 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.1401 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.1598 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.1794 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.1991 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.2188 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.2385 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.2582 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.2779 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.2976 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.3172 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.3369 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.3566 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.3763 I0.0124 J0.0217
    X1.4741 Y-1.65 Z-0.396 I-0.0124 J-0.0217
    X1.4988 Y-1.6065 Z-0.4157 I0.0124 J0.0217
    X1.5098 Y-1.6194 Z-0.42 I-0.0124 J-0.0217
    X1.4631 Y-1.6371 I-0.0234 J-0.0089
    X1.5098 Y-1.6194 I0.0234 J0.0089
    X1.5026 Y-1.6355 I-0.0117 J-0.0044 F10.
    G1 X1.4967 Y-1.6377
    X1.4941 Y-1.6387 Z-0.4197
    X1.4916 Y-1.6396 Z-0.4188
    X1.4894 Y-1.6405 Z-0.4173
    X1.4876 Y-1.6412 Z-0.4153
    X1.4862 Y-1.6417 Z-0.4129
    X1.4853 Y-1.642 Z-0.4103
    X1.485 Y-1.6421 Z-0.4075
    G0 Z0.2
    X1.9 Y-1.5225
    Z0.0246
    G1 Z-0.0429 F10.
    G18 G3 X1.9125 Z-0.0554 I0.0125 K0.
    G1 X1.9187
    G17 G2 X1.9312 Y-1.535 I0. J-0.0125
    X1.8812 Z-0.0751 I-0.025 J0. F20.
    X1.9312 Z-0.0947 I0.025 J0.
    X1.8812 Z-0.1144 I-0.025 J0.
    X1.9312 Z-0.1341 I0.025 J0.
    X1.8812 Z-0.1538 I-0.025 J0.
    X1.9312 Z-0.1735 I0.025 J0.
    X1.8812 Z-0.1932 I-0.025 J0.
    X1.9312 Z-0.2129 I0.025 J0.
    X1.8812 Z-0.2325 I-0.025 J0.
    X1.9312 Z-0.2522 I0.025 J0.
    X1.8812 Z-0.2719 I-0.025 J0.
    X1.9312 Z-0.2916 I0.025 J0.
    X1.8812 Z-0.3113 I-0.025 J0.
    X1.9312 Z-0.331 I0.025 J0.
    X1.8812 Z-0.3507 I-0.025 J0.
    X1.9312 Z-0.3703 I0.025 J0.
    X1.8812 Z-0.39 I-0.025 J0.
    X1.9312 Z-0.4097 I0.025 J0.
    X1.9044 Y-1.5599 Z-0.42 I-0.025 J0.
    X1.908 Y-1.5101 I0.0018 J0.0249
    X1.9044 Y-1.5599 I-0.0018 J-0.0249
    X1.8928 Y-1.5466 I0.0009 J0.0125 F10.
    G1 X1.8933 Y-1.5403
    X1.8935 Y-1.5376 Z-0.4197
    X1.8937 Y-1.5349 Z-0.4188
    X1.8939 Y-1.5326 Z-0.4173
    X1.894 Y-1.5306 Z-0.4153
    X1.8941 Y-1.5291 Z-0.4129
    X1.8942 Y-1.5282 Z-0.4103
    Y-1.5279 Z-0.4075
    G0 Z0.2
    X2.3197 Y-1.4293
    Z0.0245

    October 21, 2017 at 6:36 pm #10653
    cmcgrath5035
    Moderator

    Try mm mode, or a PP that will generate all G1 moves (no arcs)

    October 21, 2017 at 7:28 pm #10654
    colinsk
    Member

    My problem seems to be in the 4 digits of precision in the j parameter. I edited the code to be only 3 digits and it is boring the holes correctly. I think it will resolve issue 181:

    https://github.com/synthetos/TinyG/issues/181

    Changing the post processor code in Fusion 360 to:

    var xyzFormat = createFormat({decimals:3, forceDecimal:true});
    var rFormat = xyzFormat; // radius
    var abcFormat = createFormat({decimals:3, forceDecimal:true, scale:DEG});
    var feedFormat = createFormat({decimals:(unit == MM ? 0 : 1), forceDecimal:true});

    October 22, 2017 at 8:18 am #10655
    cmcgrath5035
    Moderator

    Thanks for updating Issue 181 as well.
    Sending Gcode in mm might have the same effect, in some cases.
    The root cause is buried in the computation of the end point of one move and the start point of the next. Reducing loss of precision by eliminating inch to mm conversion math helps.

    October 27, 2018 at 11:42 am #11181
    AlexEichenberger
    Member

    The solution is to change the tinyg postprocessor. In fusion 360, here are the modifications that I did:

    replace the following line

    allowedCircularPlanes = 1 << PLANE_XY;

    by this line:

    allowedCircularPlanes = (0 << PLANE_XY) | (0 << PLANE_ZX) | (0 << PLANE_YZ);

    It will fix your problems.

    October 27, 2018 at 12:37 pm #11182
    cmcgrath5035
    Moderator

    Can you describe what this does to your Gcode file?

    My guess is that with “allowedCircularPlanes = 1 << PLANE_XY;" early in the Gcode file is a G17 command, which sets XY as the arc plane. So then, does "allowedCircularPlanes = (0 << PLANE_XY) | (0 << PLANE_ZX) | (0 << PLANE_YZ);" result in a Gcode file with all G1 moves, no G2 or G3?

    October 27, 2018 at 12:50 pm #11183
    AlexEichenberger
    Member

    The TinyG post files simply define the value of this variable and never uses it, so I assume that it is used by the overall g-code processor to change its behavior.

    In practice, I have compared gcode files; with this change, it generates a very long list of straight lines. Without the change, it issues a simple G2 or G3 command.

    I did not come up with the solution (obviously!), read it elsewhere. The issue was described as the Arduino does not have sufficient processing power to compute the arcs on time, thus mangling the path occasionally. From my experience, the “defect” where very reproducible (e.g. the 6th and 7th pockets in a long list). Never had any issues after.

    Note that in Fusion 360, they updates the post from time to time. You will have to reapply this patch occasionally to their latest TinyG version.

    October 27, 2018 at 1:06 pm #11184
    cmcgrath5035
    Moderator

    Thanks, as I expected.

    I am not a F360 user, so now I know how one shuts off arc (G2, G3) generation, you do it by setting in the post processor “allowedCircularPlanes = (0 << PLANE_XY) | (0 << PLANE_ZX) | (0 << PLANE_YZ);" Not using arcs is a valid solution, but in many cases the resulting Gcode file is enormous.

    October 27, 2018 at 1:47 pm #11185
    colinsk
    Member

    I had Fusion update their post processor. It is now the default to not post arcs. I have a few post processors that I use. The new stock one, the old stock one and an old one the only uses mm. I find the problem is arcs in inches but I can’t prove it.

    October 27, 2018 at 2:00 pm #11186
    cmcgrath5035
    Moderator

    The underlying issue appears to be the precision of math done on the path.
    mmArcs are always more precise than inchArcs because tinyG does all it’s work in mm internally, so inch mode Gcode goes thru additional conversion math.

    mmArcs frequently resolve issues, but not always

    8 bit math (microcontroller hardware) is also a contributor

    November 1, 2018 at 10:47 pm #11188
    Vex
    Member

    Is there enough memory to split the math into parts to remedy the rounding errors? Or is that just asking too much of the tinyG?

    Just Spitballing:
    There is an expansion ‘slot’ set aside for an additional TinyG connection–and I know that it’s impossible to time the drivers to accurately do 6-axis machining, but could we utilize a ‘driverless’ TinyG to help with the math? Maybe a pre-processor to offload some of the work and let the downstream TinyG do the actual driving with the the first pass?

    • This reply was modified 6 years ago by Vex.
    November 3, 2018 at 6:44 am #11190
    cmcgrath5035
    Moderator

    I believe the answer would be that memory and more importantly compute time (CPU cycles) are nearly exhausted by the current firmware. Thus overall performance (speed of movement) would likely degrade if such changes were attempted.
    I am not a dev, have asked them to comment when they have a chance.

    Your previous post, about reducing the precision of the Gcode generated, is likely to produce more reliable results in the near term as well.

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