Hello,
I have recently been getting these errors when machining. It is very annoying that it happens partway through my programs and then I have to restart. Any idea on what is causing this and how to fix it?
I am using Fusion360 with the carbide3d Post configuration.
Error image:
Gcode is too large to upload to this site so I have the link to google drive download if anyone needs it.
https://drive.google.com/open?id=0B_h6uhnwT_0Nc0V0bUZpX3dRNzg
Any help would be appreciated. Thank you.
This has come up a few times previously: Shapeoko CNC Router, Rigid, Accurate, Reliable, and Affordable
if using AutoDesk Fusion 360) is inaccurate conversion from Imperial to metric — convert project to metric, then do CAM in metric, then send a metric G-code file to Grbl.
wow, that seems like it should be a really easy fix. I hope they get around to adjusting that so I do not have to remember to convert every time.
Thank you for the help though. I tried changing it to mm and it is running so far.
Actually, it seems to be a subtle problem in how Autodesk Fusion 360 calculates curves, and how Grbl interprets them — if you could send your file to @chamnit hopefully it would help to shed some light on this and perhaps help to work out a solution.
I never really bothered trying to track down the cause of this problem. Given that this gcode error only comes from Autodesk Fusion 360, not any other CAM package, this is a problem on Autodesk’s end.
Grbl follows the G2 and G3 arc LinuxCNC definitions almost exactly. The error-checking protocol for these two g-codes are actually pretty relaxed, meaning that the arc would have be really screwed up to not pass.
I would ping AutoDesk support about this issue. They are clearly screwing something up in the mm to inch conversion.
I experienced the same error on a project created by VCarve Desktop. It happened the same place on 3 different attempts. I was able to determine the line code where it was happening and edited that out and was able to complete the project. Sure would be nice if CM would capture the line number where the error occurred and display the line number in the error notice. I don’t know if the error processing is a GRBL or CM function.
Please send any such problem file to support for Grbl or Carbide 3D.
Grbl has a simulation version which will run through an entire program — agree it would be nice to have a checkbox in the file dialog box which would default to checked for new files to ask if they should be simulated, and off for filenames which have previously been seen (and whose internally recorded checksum hasn’t changed).
@robgrz — could we add this as a feature?
I will if it happens in the future. I modified the file and no longer have the original file for that project… thanks for the quick response and all you do for the Shapeoko community.
Thanks!
It’s a weird problem, and I think we’re going to all have to collaborate to get it fixed.
@robgrz — could we add the simulate on open checkbox as a feature?
I ran into this with VCarve Desktop 8.5 on my recently-acquired Nomad Pro, using the post-processor from the wiki. I made a small repeat-by; this zip archive contains all the files necessary. Carbide Motion generates the error after line 124 of id33-inch.nc, but runs id33-mm.nc perfectly.
Since I switched to the MM version of the post-processor, I haven’t had any problems.
What was I making? A bunch of clamps for my threaded table; I wasn’t confident about the feeds/speeds for my .25-inch endmill at the time, so I was generating minimal surfacing paths around each part for the .125 endmill, using VCarve’s offset tool.
-j
FYI, myself and others just looked into the Fusion360 problem with G2 and G3 arcs.
It turned out that this is indeed a bug in the Fusion360 source and/or a post processing file a lot of people use. Namely the Strooom/OpenBuilds version of the Grbl post that increases the precision of the arc values. From our limited testing, it looks like Fusion360’s default grbl post doesn’t produce G2 or G3 errors anymore. This may have been a recent development with Fusion360 ongoing updates.
In addition, we also narrowed Fusion360’s problems down to G18 and G19 arc planes, but not the typical G17 (XY) arc plane. When you actually look at the arc command, they are way off. The radius and the targets are not even close to lining up on the same arc, which indicates value precision has nothing to do with Fusion360’s problems. We suspect that it more has to do with their minimumChord and minimumRadius settings and how they are handled internally.
From what I can tell, arc error in Grbl occur when the arcs produced by a CAM program at very small and/or very short. The G2 and G3 arc g-code standard doesn’t really account for this very well and makes it easy to create a poor arc. While I can check for these situations inside Grbl and apply an internal fix, this only patches the overall problem and can lead to situations where Grbl isn’t sure how to trace the programmed arc. For example, the CAM program could have meant to program a full circle, but the arc is so poorly generated that the closest arc solution is a small arc. Another example is, if both the starting position and target positions don’t lie on the same arc, which do you choose to trace from or to? You end up with a step in the traced arc, not a smooth arc.
@jgreely : I just met some of the Vectric folks at MakerFaire a few months back. I’ll take a look at what is causing the problem and notify the right people at Vectric to see if they can fix the problem.
I ran your nc files in your posted zip file. Neither produced an arc error when I streamed them directly to Grbl via the Grbl Python streaming script. No CarbideMotion involved. This would suggest that there may be a problem how CarbideMotion handles a gcode file before sending it to Grbl. But it’s impossible to say definitely at this point without more tests.
