Invalid gcode errors

[NicoPy]

With some files (png or svg), I get errors Invalid gcode ID:xx.
Are these errors generated by LaserGRBL or by the connected device ?

Hardware and software configuration :

• Windows 10 (21H2)
• Engraver : Atomstack P7 40
• Grbl version : ?
• LaserGRBL version : V4.6.2

[arkypita]

Are these errors generated by LaserGRBL or by the connected device ?

by the device

https://lasergrbl.com/faq#issues

[NicoPy]

Thanks for the link.
I had a closer look at the problem.
The error I am concerned about is Invalid gcode ID:33. In file error_codes.csv, one can read what it means : Motion command target is invalid.
The problematic commands are G3.
Here is a screenshot :

Here, all G3 (arc) commands are faulty. Except the full circle.

In the code, the following 2 lines give a delta X of 8.12mm (49.97 - 41.85) :

G1X41.85F600
G3X49.97Y8.15I0J8.11

Delta Y is also 8.12mm (8.15 - 0.03).

I replaced all arc center offsets (8.11) with 8.12. Now, the engraver does not report errors anymore.

So, the problem comes from LaserGrbl, not the engraver. Right ?

Note : Grbl version given when connection is established is 1.12930h
The file used for my tests :
Marque pages Marie - découpe.zip

[svenhb]

The problem is: you use just two digits

[arkypita]

So, the problem comes from LaserGrbl, not the engraver. Right ?

Right, I can reproduce it too.

The problem is: you use just two digits

@svenhb do you mean is a rounding error?

[arkypita]

@svenhb thanks for your hint! I changed DecimalPlaces from 2 to 3 and the issue disappear.
Fix in the next version.

[svenhb]

Yes rounding error. Since I've often fallen into this trap, I check the code after generation in my GRBL-Plotter:

[NicoPy]

Yes rounding error. Since I've often fallen into this trap, I check the code after generation in my GRBL-Plotter:

Do you mean your engraver has a check functionality ?

[svenhb]

Yes, it checks the radii before and after the G2 / G3 command, if the difference is > than allowed by grbl it shows the error.

[NicoPy]

I tried gvalidate.exe from grbl-sim repository. One can find an old version here, in drop.zip (second post).
It works but is almost useless since it only tells if file (lines) is (are) OK or not. No details.

[NicoPy]

Yes, it checks the radii before and after the G2 / G3 command, if the difference is > than allowed by grbl it shows the error.

In case of error, my engraver reports an error and skip the command. If LaserGrbl is not configured to stop on error, the result is... surprising.

[arkypita]

grbl firmware can check gcode for you, no need of external app: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands#c---check-gcode-mode

[NicoPy]

grbl firmware can check gcode for you, no need of external app: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands#c---check-gcode-mode

Ha, that's useful information. Thanks.

Thanks for the quick fix. 😃

[arthurlutz]

On version v4.8.4 with an Ortur2 I seem to be getting the same error :

Has this been switch back to 3 decimal rounding ? Or is it an option ? Or my laser doesn't support G3-CIRCLE ?

[arkypita]

Could you please zip and upload the original .svg file and the gcode generated by LaserGRBL (menu file -> quick save)?

[arthurlutz]

svg: https://cdn.thingiverse.com/assets/6d/30/46/40/34/holders.svg

gcode : holders.zip

Thanks for such a prompt response !

[arkypita]

Your GCode is wrong, but not because of rounding.... the data of the parameter J is missing!

But if I load the svg file to my LaserGRBL I have a different code.

Also LaserGRBL does not write "CIRCLE" in the code.
Are you sure of the source you got LaserGRBL from? It would seem an unofficial version.

[arthurlutz]

I'm pretty sure I installed from the installer from github. Maybe the source of the problem is that I'm running it in Linux (Ubuntu jammy) in PlayWithLinux/wine emulation. Should I open a separate issue to track this ?

Happy to help debug.

As a workaround, I'll try to search/replace in the generated gcode and reload it into LaserGRBL to run the correct GCODE.