Invalid g-code ID:33 in gSender

[JdotPo]

I’m not 100% sure this is a gSender bug, but I wanted to post just in case.

I’m using Vectric VCarve Desktop to do some horizontal vcarving for a sign I’m making; The gcode I’m having an issue with is for a 3/16 Downcut bit used as a clearance tool. I have a MK2 Longmill 48x30 with the standard Longboard running the latest gSender Edge, but I encountered the same error using the latest stable release.

While running the job with gSender, it was cutting as expected but then encountered an error, cut an unexpected path, and then stopped. The error was:
Error 33 on line 521 - Invalid g-code ID:33

I don’t typically run a validation in gSender because I’ve haven’t had an issue with VCarve generated code until now, but once I did it encountered an additional error:
Error 33 on line 1368 - Invalid g-code ID:33

I ended up swapping the bit for a 1/4" and 1/8" bit for clearance with no issues for the validation or carve and completed the sign. Using the 3/16" for a different sign gave no validation error, although that sign was vertical as it is shorter.

VCarve didn’t give any errors, so I ran the gcode through NC viewer (https://ncviewer.com/) which also didn’t give any errors. I’ve never tried to analyze any “bad” gcode before so I’m not sure what they actually do (if anything). Both errors seem to be around an arc.

Here are a few screenshots around the line numbers in NC Viewer:

You can see that line 520 seems to have been the actual error as it just skipped the arc and cut to the next endpoint (top “N”):

G-code file:
T1_3-16DC Test.gcode (36.1 KB)

I’m happy with someone telling me I missed something or that I need to follow-up with Vectric. I haven’t tried to use UGS (assuming it has a validator), but I’ll certainly give that a shot for comparison if it helps.

Please let me know if you need any other info.

Thanks!

-Jon

[gwilki]

@JdotPo What post processor are you using in VCarve?

[JdotPo]

Grbl (inch):

[_Michael]

This topic is a little out of my wheelhouse but I did do a little research to see what the error is. ‘The motion command has an invalid target.’ is the error. Searching that phrase led me to some articles that say that error can be caused by G2/G3 arc moves that have a rounding error due to the numerical precision used etc.

So knowing that a distance measured in mm will take less decimal places than the same distance measured in inches, I would try using the grbl mm post processor. I’m fairly certain that you can still design in inches with Vectric and save using the mm post processor. It’s easy to try anyway and maybe it will work.

The other thing I ran across that could cause this would be EMI causing problems with the USB connection. But if you test the code in gSender and the error/s are always there on the same line/s then it’s not EMI.

[NeilFerreri]

Yup…use metric.
This is an arc calculation issue due, most likely, to rounding errors.
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).
Here’s a nerdy spreadsheet I made a while ago when these errors were popping up for many on other forums. I just input your data, and looks like it’s just off.

If you post process in mm, this won’t happen.
If you REALLY want inches, try my post processor here.

[JdotPo]

Thanks for the input everyone! I used the mm post-processor and everything verified nicely.
I imagine the 3/16 bit just happened to hit the “sweet spot” for calculation errors vs the 1/4 and 1/8. I’ll just stick with generating mm files since it has no impact on what I’m doing for jobs.

Sorry for the noise in the topic, but I appreciate the assistance.

-Jon

[gwilki]

@JdotPo I see that @NeilFerreri resolved your issue, Jon. As such, I am closing your topic.

Get back to having fun.