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.
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.
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.
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
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
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.
This topic is from the original forum (October 2018). Your reply starts a new discussion linked to it.