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.
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.)
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:
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.
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.
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.
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.
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
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?
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.
I second the problem with 440.20. I did comment on issue (#174 on github.
I don't necessarily use Fusion 360 to generate my gcode. I do use other tools like makercam or pcbgcode for eagle as well.
G2/G3 moves should be working to have a reliable machine :-/
I read about the issue on separate sources but didn't find the answer for the question: Did the problem with G2/G3 ever got solved and if so, which firmware version shall i use?
Maybe someone can clear things up. I guess i'm not the only person on the planet who got this issue.
This topic is from the original forum (November 2018). Your reply starts a new discussion linked to it.