I use python scripts to generate much of the g-code I use; I’m fairly confident it is valid to GLBL 1.1. However, the Carbide Motion software throws errors (usually around arcs). Is it possible to disable the g-code verification step in Carbide Motion and just pass the g-code through?
(I could use a 3rd party GRBL controller, of course, but I’m otherwise happy with Carbide Motion and don’t really want to set up another tool.)
Usually the arc error is from Grbl — if you find an arc which is valid to Grbl but which CM rejects, please let the devs know. If you find an arc which is valid G-Code in LinuxCNC, but which Grbl rejects, please let @chamnit know on github.
FWIW, if you like Python you’d probably enjoy bCNC.
You can check for the errors by using Grbl’s $C check mode.
What error are you receiving?
@WillAdams thanks for the heads up - I’ll check it out.
@neilferreri “Arc Endpoint Error” which there are many cases of here on the forum. Also the radius form of the arc command comes back as “unsupported”, which I’m pretty sure isn’t correct. (Although I’m not sure of course - I like the idea of sending it to the GRBL controller in debug mode; I didn’t know about that.)
Can you post your grbl settings?
I’ll search for an issue to post, but this reproduces the bug. Using UGS it successfully send the gcode and the Nomad navigates a capsule. Using Carbide Motion 4, it throws: ‘error in line 6: arc endpoint error’ and refuses to run. Frustrating. The gcode:
G91 ;relative
F400
G1 X-5.500000
G1 Y3.937500
G17 ;XY plane
G3 X0.000000 Y-7.875000 I0.000000 J-3.937500
G1 X11.000000 Z0.000000
G17 ;XY plane
G3 X0.000000 Y7.875000 I0.000000 J3.937500
G1 X-11.000000 Z0.000000
Cannot with CM. CM interprets some gcode itself (tool changes, in particular) and you can’t disable its preprocessing.
That said, more than 3 digits past the decimal point is probably a bit unnecessary. Try dropping a few digits off the end and see if CM will take it.
G3 X0.000 Y-7.875 I0.000 J-3.937
If that fixes it, please report it to the carbide support email, and hopefully they’ll fix it quickly.
We’ve been meaning to get some checking done on arc errors. We’ll try your code tomorrow and see what’s going on.
Ok- Here’s what we found:
The way that CM parses gcode assumes that the code will have a G90 move prior to the G91 moves to establish a starting position. We added (in the internal development version to push out soon) an error message to make this more clear.
Second, there was a bug in how incremental arcs are handled in the parser so that’s being fixed right now.
-Rob
YAY! Thank you…the arc bug has been driving me crazy. Thanks for following up.
And good to know about the G90 move; easy to work around, but wasn’t aware of it.
Check out the Carbide Motion beta that got uploaded today. Let me know if it works better for you.
Tested! Working beautifully. Removed linear approximations and went back to proper g2/g3 arcs and it looks great.