GRBL Error ID: 33

So last night I kept getting invalid g code errors ID: 33 while using UGS Console to send gCode created with VCarve Pro.

It was having issues with the ARC command.

After doing a bit of research It looks like the problem may be not enough decimal places on the ARC command variables I and J?

A while back I reduced the number of decimal places on the gCode output. I did this to reduce file size and to try to get as close to single step values for better theoretical accuracy vs precision.
However, I reduced it on the ARC variables as well. I probably have not seen the error come up before because ARC commands are so rarely used by vCarve.

So I am going to set the I and J variables back to 5 decimal places and see if that fixes the problem.

I will update as I go.

VAR ARC_CENTRE_I_INC_POSITION = [I|A|I|**1.5**]
VAR ARC_CENTRE_J_INC_POSITION = [J|A|J|1.5]

For reference here is my post processor code:

+================================================
+

  • Vectric machine output configuration file

+================================================
+

  • History
  • Who When What
  • ======== ========== ===========================
  • Tait L. 05/07/2015 Written
  • L2Hench 08/17/2015 Added G90 (Absolute Addressing) to header
  • L2Hench 08/19/2015 Added M05 (Spindle Stop) to footer
  • L2Hench 08/18/2015 Added M09 (Coolant Stop) to footer
  • L2Hench 03/02/2016 Removed T1M6 (Tool Change) from header
  • L2Hench 03/28/2016 Added M07 (Coolant On, Mist) to header
  • L2Hench 07/12/2016 Modified decimal place value of X axis from 4 to 2 (single step accuracy of 0.04mm per step for 8mm ACME rod)
  • L2Hench 07/12/2016 Modified decimal place value of Y axis from 4 to 2 (single step accuracy of 0.30mm per step for 3mm belt)
  • L2Hench 07/12/2016 Modified decimal place value of Z axis from 4 to 2 (single step accuracy of 0.04mm per step for 8mm ACME rod)
  • L2Hench 08/15/2017 Restored ARC Variable to 5 decmial places to fix GRBL invalid g code Error ID: 33
    +================================================

POST_NAME = “Kaiju Carve (mm) (*.gcode)”

UNITS = “MM”

FILE_EXTENSION = “gcode”

±-----------------------------------------------

  • Line terminating characters
    ±-----------------------------------------------

LINE_ENDING = “[13][10]”

±-----------------------------------------------

  • Block numbering
    ±-----------------------------------------------

LINE_NUMBER_START = 0
LINE_NUMBER_INCREMENT = 10
LINE_NUMBER_MAXIMUM = 999999

+================================================
+

  • Formating for variables

+================================================

VAR LINE_NUMBER = [N|A|N|1.0]
VAR SPINDLE_SPEED = [S|A|S|1.0]
VAR FEED_RATE = [F|C|F|1.1]
VAR X_POSITION = [X|C|X|1.2]
VAR Y_POSITION = [Y|C|Y|1.2]
VAR Z_POSITION = [Z|C|Z|1.2]
VAR ARC_CENTRE_I_INC_POSITION = [I|A|I|1.5]
VAR ARC_CENTRE_J_INC_POSITION = [J|A|J|1.5]
VAR X_HOME_POSITION = [XH|A|X|1.2]
VAR Y_HOME_POSITION = [YH|A|Y|1.2]
VAR Z_HOME_POSITION = [ZH|A|Z|1.2]

+================================================
+

  • Block definitions for toolpath output

+================================================

±--------------------------------------------------

  • Commands output at the start of the file
    ±--------------------------------------------------

begin HEADER

“G17”

  • XY Plane selection +

“G21”

  • Programming in millmeters (mm) +

“G90”

  • Absolute Programing +

“G0 [ZH]”

  • Rapid Move Z axis to Start Position +

“M07”

  • Coolant ON (mist) +

“G0 [XH] [YH] [S] M3”

  • Rapid Move X axis to Start Position, Move Y axis to Start Position, Speed (RPM), Spindle ON +

±--------------------------------------------------

  • Commands output for rapid moves
    ±--------------------------------------------------

begin RAPID_MOVE

“G0 [X] [Y] [Z]”

±--------------------------------------------------

  • Commands output for the first feed rate move
    ±--------------------------------------------------

begin FIRST_FEED_MOVE

“G1 [X] [Y] [Z] [F]”

±--------------------------------------------------

  • Commands output for feed rate moves
    ±--------------------------------------------------

begin FEED_MOVE

“G1 [X] [Y] [Z]”

±--------------------------------------------------

  • Commands output for the first clockwise arc move
    ±--------------------------------------------------

begin FIRST_CW_ARC_MOVE

“G2 [X] [Y] [I] [J] [F]”

±--------------------------------------------------

  • Commands output for clockwise arc move
    ±--------------------------------------------------

begin CW_ARC_MOVE

“G2 [X] [Y] [I] [J]”

±--------------------------------------------------

  • Commands output for the first counterclockwise arc move
    ±--------------------------------------------------

begin FIRST_CCW_ARC_MOVE

“G3 [X] [Y] [I] [J] [F]”

±--------------------------------------------------

  • Commands output for counterclockwise arc move
    ±--------------------------------------------------

begin CCW_ARC_MOVE

“G3 [X] [Y] [I] [J]”

±--------------------------------------------------

  • Commands output at the end of the file
    ±--------------------------------------------------

begin FOOTER

“G0 [ZH]”

  • Rapid Move Z axis to Start Position +

“G0 [XH] [YH]”

  • Rapid Move X and Y axis to Start Position +

“M05”

  • Spindle Stop +

“M09”

  • Coolant OFF +

“M30”

  • End of program +

Well that didn’t work.

I tried removing all the ARC commands completely from the post processor and was able to run the code without any ARC commands, so no errors.

I would file a report with Vectric. I have used arcs successfully with Vcarve PRO 8.5 and grbl 1.0c.

It isn’t erroring on all arc curves in the file, just some specific ones.
I have tried to research it, but there isn’t too much info available.

It seems to only occur on very small arcs. The theory is that is it is some kind of math or rounding error occurring when GRBL checks to see if the ARC is a valid geometry?

I found comments that the GRBL development people were talking with Ventric a while back to try to figure out what exactly is going on.

But so few of my projects even use “arc curves”, almost all of them use “smooth curves” which do not generate ARC commands, so this is a low priority bug for me. (and I suspect for the GRBL team for the same reasons)

At least I found a easy work around. :slight_smile:

But I will keep poking at it as time allows. :wink:

Try playing with the arc tolerance setting to see if it makes any difference. ($12).

I did a little experiment with it.

Check this thread:

2 Likes