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.
@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.)
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:
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.
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.