I created some g-code using Fusion 360 and tried to run it. It starts out OK but then stops after the first depth of the first operation (facing) with the error message shown on the screenshot.
I searched for that message here on the forum and found these:
So I downloaded the latest carbide3d.cps file from https://cam.autodesk.com/hsmposts (It says last change was on 12/3/2019, MD5 I got for that file is 100890b4d1b1ee46fb74efb854c3fbdf). I installed it as a cloud post processor in Fusion 360 and regenerated the g-code. I compared the old and new output file and indeed I see a lot of changes like this:
Try using the latest version of Carbide Motion, there’s a little more conditioning in there to help fix small arc errors. You’re a couple months out of date.
Thanks I’ll try that and report back. I thought I should check that but then I saw the “No Updates Available” message below the version number and thought I was all set.
Unfortunately the result is exactly the same with version 4.0.428.
Is there anything I can tweak in Fusion 360? Or can I hand-edit the .nc file or write a script to fix it up? What exactly is it unhappy about in that command shown in the screenshot?
There’s a line in the post processor, around row 77 that you can change to add an additional decimal point to the output.
Original: var xyzFormat = createFormat({decimals:(unit == MM ? 3 : 4)});
Modified: var xyzFormat = createFormat({decimals:(unit == MM ? 4 : 5)});
You can then upload that to your cloud library or wherever you keep your posts.
You may also want to change the header information so that you can tell which post has been modified when you open it in Fusion. I used:
description = “Carbide 3D (Beta)”;
vendor = “C3D - Beta”;
(lines 13 and 14)
GRBL isn’t happy that the coordinates for the arc move aren’t mathematically perfect. The radius of the starting point from the center needs to be identical to the radius of the end point to the center point, to within the margin of error for floating point numbers. Solution is to export gcode with more precise coordinates.
Unfortunately that also didn’t work. I made the change from 3/4 to 4/5 digits and regenerated the g-code and verified that the output contains an extra digit.
Carbide Motion stops at the exact same point again. In the screenshot below you can see that it’s indeed using 4 digits, where my earlier screenshot shows 3 digits.
BTW thanks a lot for your help Winston, I really appreciate it.
Hmm. This is perplexing. It’s one of those things that works fine 99.99% of the time, but sometimes you just have to shake up the box and pray to the gcode gods that it fixes itself. Can you try changing the size of your lead-ins/outs (if you’re using them) by like 0.001, and also tweak the tolerance by a tiny tiny amount? Sometimes all it takes is nudging your fusion setup/toolpaths by a microscopic amount and the resulting gcode will end up being something completely different.
It worked after I completely disabled the lead-in and lead-out of the facing operation. Fusion 360’s default was 0.3175 mm for the “vertical lead-in radius”. When I changed that to 0.3mm I got the same failure. When I completely disabled both the lead-in and out, it worked.
That’s a small lead in (.3175 mm = .012") , and it’s causing the helix to be uncalculatable at the precision that’s set in the GRBL settings - that’s a really tiny curve, and it’s really short. So short, the straight lines it calculates into are beyond the arc tolerance (a grbl setting) That isn’t usually the default lead in - increase it to something like .125" and it’ll likely work fine. This isn’t a post problem, it’s a bad parameters that might not be obvious, and the realities of approximating curves with small straight lines.
In my understanding, that shouldn’t really matter here.
The error @liyanage is seeing has to do with miscalculated arcs or arcs with too low of a precision that they result in being outside the tolerance for this. Here is the source for that error.
Basically, for that error to occur, the radius of the arc at the start and the radius of the arc at the end would have to differ by .005mm (AND be greater than 1% of the radius). In the original, less precise, version of the file he’s only off by .001mm (which is also less than 1% of the radius).
I wonder if Carbide Motion is doing its own check?
Will note here that you mentioned ‘Nomad’ so there is probably some required reading before swapping to CNCJS or the like as the setup for tool probing is not an out of the box sort of thing.with this. Slightly worried you are looking for a quick and easy solution and changing senders with Nomad is a bit of a journey.
That’s very good to know about the tool length probing, thanks for the heads up.
I did quickly fire up CNCjs and played around with the UI a bit and what I saw so far looked great. I was able to jog the steppers around etc. right away.
