CarbideMotion throwing error after upgrade to grbl 1.1

1

I just upgraded my Shapeoko 3 from grbl 0.9 to 1.1h using the Arduino IDE and the stock config.h file - I didn’t use the Carbide updater. I then corrected the grbl defaults to match the Shapeoko ones. When I open the latest CarbideMotion 4 I get this error:

ERROR (1): GRBL ERROR: Unsupported or invalid g-code command found in block

I can still connect, home, jog, and probe. Haven’t tried executing a code file yet. Here are my grbl defaults:

$0 = 10 (Step pulse time, microseconds)
$1 = 255 (Step idle delay, milliseconds)
$2 = 0 (Step pulse invert, mask)
$3 = 6 (Step direction invert, mask)
$4 = 0 (Invert step enable pin, boolean)
$5 = 0 (Invert limit pins, boolean)
$6 = 0 (Invert probe pin, boolean)
$10 = 255 (Status report options, mask)
$11 = 0.020 (Junction deviation, millimeters)
$12 = 0.010 (Arc tolerance, millimeters)
$13 = 0 (Report in inches, boolean)
$20 = 1 (Soft limits enable, boolean)
$21 = 1 (Hard limits enable, boolean)
$22 = 1 (Homing cycle enable, boolean)
$23 = 0 (Homing direction invert, mask)
$24 = 100.000 (Homing locate feed rate, mm/min)
$25 = 1000.000 (Homing search seek rate, mm/min)
$26 = 25 (Homing switch debounce delay, milliseconds)
$27 = 5.000 (Homing switch pull-off distance, millimeters)
$30 = 1000 (Maximum spindle speed, RPM)
$31 = 0 (Minimum spindle speed, RPM)
$32 = 0 (Laser-mode enable, boolean)
$100 = 40.000 (X-axis travel resolution, step/mm)
$101 = 40.000 (Y-axis travel resolution, step/mm)
$102 = 40.000 (Z-axis travel resolution, step/mm)
$110 = 5000.000 (X-axis maximum rate, mm/min)
$111 = 5000.000 (Y-axis maximum rate, mm/min)
$112 = 5000.000 (Z-axis maximum rate, mm/min)
$120 = 400.000 (X-axis acceleration, mm/sec^2)
$121 = 400.000 (Y-axis acceleration, mm/sec^2)
$122 = 400.000 (Z-axis acceleration, mm/sec^2)
$130 = 425.000 (X-axis maximum travel, millimeters)
$131 = 465.000 (Y-axis maximum travel, millimeters)
$132 = 80.000 (Z-axis maximum travel, millimeters)

How do I get rid of this error? Do I have to modify the config.h file and refresh? If so, are the changes needed in the config.h file documented somewhere? Thanks!

2

Are you sure it was actually upgraded to 1.1?

3

Yep. I can check using (as I recall) $I and it returns the version. 1.1h.

4

Carbide Motion assumes a non-default version of grbl which has parking override enabled. CM sends M56 commands which, in the stock / default version of grbl, is disabled.
You can ignore the warning (annoying), use Carbide3D’s version of grbl (not posted anywhere?), modify your version, or use a different sender.

EDIT: Link to grbl config section.

2 Likes
5

Please see:

which has a link to:

http://carbide3d.com/dl/v4/grbl.hex

6

Thanks for the feedback and the suggestions!

I did try altering the stock grbl config.h to uncomment-out the PARKING lines, and then recompiled using the Arduino IDE and refreshed the Shapeoko. Unfortunately, I still got the same Carbide Motion error. So I did a diff between the standard grbl config.h file and the Carbide version, and there are more differences than just the PARKING lines.

I’ll try flashing with the Carbide Motion package if I can find the library. I really want that probe capability!

My only concern is if I go for the Carbide grbl update to make my system work with Carbide Motion, will it cause trouble for other code senders such as UGS and bCNC, which I also use?

7

Ok, now after reading more in links supplied by Neil and Will, I see a comment by Rob Grzesek, who says: We don’t modify anything but the config file…

Presumably then, if I stop trying to micromanage it and just use the Carbide config.h and recompile and refresh, the Carbide Motion error should go away.

Reminder to self – check all the referenced material before commenting!

8

Nope, many people use other senders (UGS and CNCjs in my case, bCNC has been mentioned too) with Grbl1.1 compiled for the Shapeoko and that works fine.

My understanding is that the only Shapeoko-specific thing in the GRBL hex delivered with Shapeokos is that it was compiled with DEFAULTS_SHAPEOKO_3 parameter

3 Likes
9

Where’d you find a Carbide version? I’ve never seen it posted.

You’ll need to uncomment #define PARKING_ENABLE and #define ENABLE_PARKING_OVERRIDE_CONTROL in the config.

Edit: I knew this seemed familiar.

1 Like
10

The M56 that Motion sends is not enabled by default. It’s not a “Shapeoko specific” thing, though… Just a compile time option.

2 Likes
11

Julien: Thanks for the info about the other senders. Haven’t tried CNCjs yet. Mostly wanted CarbideMotion so I could start using the probe capability.

The Carbide version of config.h that I found does not include DEFAULTS_SHAPEOKO_3
anywhere. Maybe I have an older version?

Neil: I found the Carbide version of config.h here:

GRBL 1.1 changes from stock?

The link is from 2/17 though. Don’t know if the file itself is that old or not. Again, when I did a diff between the link config.h and the standard 1.1 version, I saw a bunch of differences; not just the PARKING lines.

Thanks for the link to the other Forum thread; it looks like the same problem.

So this time I replaced the original config.h file with the Carbide one from the link, recompiled the sketch in the Arduino IDE, and flashed the EPROMs. Now when I open Carbide Motion I no longer see the error. :smiley:

So the answer is to use the correct (Carbide) config.h file and all is sunshine and unicorns.

Thanks for all the help!

4 Likes
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.