GRBL 1.1g update causing issues with Shapeoko 3 and Carbide Motion board 2.4e


(Matt B Hoover) #1

Updated my Shapeoko 3 XXL to GRBL 1.1g, now I get an “unsupported g code in block” error when connecting in Carbide Motion. I have the default settings set to Shapeoko 3 in config.h, but has anyone else received this error? Tried searching around the net but came up empty handed.

Any tips are well appreciated. Thanks in advance!


(William Adams) #2

It’s my understanding that Carbide Motion wants certain reporting options turned on when compiling, but it’s supposed to work without them.

Do you get past the error?

Could you post the compile options you used?

Have you tried recompiling with the Carbide 3D defaults?


(Neil Ferreri) #3

It happens when you connect? Can you home the machine?
Have you tried with another sender or serial communication program?
Can you post your $$ values?

For what it’s worth, 1.1g is not an official release.


(Matt B Hoover) #4

No, I still have the error but it’s not specific. The only options I added were the defaults for Shapeoko and I uncommented a few things about the Spindle Direction and activation pins, in config.h

Otherwise it’s stock GRBL 1.1g.

I’m not sure how to compile using the Carbide 3D defaults. I’m using the Arduino IDE and trying to set up my Shapeoko 3 with SuperPID. I’ve got the SuperPID ready and the firmware update for GRBL is the last step. I also know the firmware update is successfuly because it reads the correct version in the setup tab in Carbide Motion.

Has anyone else sucessfully updated their 2.4e boards to GRBL 1.1g?

Thanks for any help!


(Matt B Hoover) #5

I can connect fine, and it homes. Haven’t tried using another sender.

When I go to the setup tab, that’s when I see the error in a red box. But it’s very cryptic. I thought maybe it was something to do with parking or the startup pause for safety. But no luck yet.

Didn’t realize 1.1g wasn’t official…it was the latest from the Github repository.


(Neil Ferreri) #6

I doubt that’s causing any issues.
Can you get the output of the “log”?


(Matt B Hoover) #7

I’ve posted the log file below…the idle report after line 65 just sort of repeats after that.

A question about the new $ values for spindle max/min RPM – how is that implemented? I could not find a mention of it in config.h. I did see settings for RPM values in the defaults.h file. Is there somewhere else to set that?

thanks!

65): <- <Idle|MPos:0.000,0.000,0.000|Bf:15,128|FS:0,0>
(64): <- <Idle|MPos:0.000,0.000,0.000|Bf:15,128|FS:0,0>
(63): <- <Idle|MPos:0.000,0.000,0.000|Bf:15,128|FS:0,0>
(62): <- error:20
(61): -> M56P1
(60): -> gc_probe
(59): <- <Idle|MPos:0.000,0.000,0.000|Bf:15,128|FS:0,0|WCO:0.000,0.000,0.000>
(58): -> gc_sync
(57): <- ok
(56): -> N0 G4P0.005
(55): -> gc_wait_for_idle
(54): <- ok
(53): <- [PRB:0.000,0.000,0.000:0]
(52): <- [TLO:0.000]
(51): <- [G92:0.000,0.000,0.000]
(50): <- [G30:0.000,0.000,0.000]
(49): <- [G28:0.000,0.000,0.000]
(48): <- [G59:0.000,0.000,0.000]
(47): <- [G58:0.000,0.000,0.000]
(46): <- [G57:0.000,0.000,0.000]
(45): <- [G56:0.000,0.000,0.000]
(44): <- [G55:0.000,0.000,0.000]
(43): <- [G54:0.000,0.000,0.000]
(42): -> $#
(41): -> gc_get_offsets
(40): <- ok
(39): <- [GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
(38): -> $G
(37): -> gc_parser_state
(36): <- ok
(35): -> G90
(34): -> gc_not_motion
(33): <- ok
(32): -> G49
(31): -> gc_not_motion
(30): <- ok
(29): -> G21
(28): -> gc_not_motion
(27): <- ok
(26): -> G10L2P1X0Y0Z0
(25): -> gc_not_motion
(24): <- ok
(23): -> G54
(22): -> gc_not_motion
(21): <- ok
(20): -> G92.1
(19): -> gc_not_motion
(18): <- ok
(17): -> M05
(16): -> gc_spindle
(15): <- ok
(14): -> N0 G4P0.005
(13): -> gc_wait_for_idle
(12): <- <Idle|MPos:0.000,0.000,0.000|Bf:15,128|FS:0,0>
(11): <- <Idle|MPos:0.000,0.000,0.000|Bf:15,128|FS:0,0|Ov:100,100,100>
(10): -> gc_wait_for_status_updates
(9): <- <Idle|MPos:0.000,0.000,0.000|Bf:15,128|FS:0,0|WCO:0.000,0.000,0.000>
(8): <- ok
(7): <- [MSG:Caution: Unlocked]
(6): -> $X
(5): <- [MSG:’$H’|’$X’ to unlock]
(4): <- Grbl 1.1g [’$’ for help]
(3): STATE: SET MACHINE STATE: INIT
(2): -> GRBL_RESET
(1): STATE: SET MACHINE STATE: NOTCONNECTED


(Neil Ferreri) #8

Looks like it’s the M56.
That’s a compile time option dealing with parking override. Any reason you enabled that?
I’m not sure, but I’m guessing CM doesn’t like that.


(Matt B Hoover) #9

I don’t think I enabled parking, perhaps it was on by default…at any rate I will check that, thank you!


(Neil Ferreri) #10

Parking can be enabled without issue.
Parking override commands don’t need to be.
I’m not sure this is the issue, but do you have this enabled?
ENABLE_PARKING_OVERRIDE_CONTROL


(Matt B Hoover) #11

No, that’s not enabled, and neither was #define PARKING_ENABLE .

So still stuck at the same point. It gives me the error right after connecting, and right after homing.


(Neil Ferreri) #12

Does the Log still show M56?


(Daniel Story) #13

A question about the new $ values for spindle max/min RPM – how is that implemented? I could not find a mention of it in config.h. I did see settings for RPM values in the defaults.h file. Is there somewhere else to set that?


You should set spindle min ($31) to 0, and spindle max ($30) to 30000 (SuperPID will run at it’s min RPM of 5000RPM through the whole 1-5000 range)

I never tried to get Carbide Motion to work after encountering that same error when using a custom build of Grbl. I just moved on to a different G-Code sender.


(Matt B Hoover) #14

Well I’m also using the Carbide Touch Probe, so having it all work in Carbide Motion would be best for me. Unless there is an easy way to use it in another app.


(Matt B Hoover) #15

It does, isn’t that strange? Where could that come from?


(Daniel Story) #16

Understandable, Motion makes things easy… when it works.

You just need to know the probe’s offsets (distance from probe to stock, width of edge finder, etc.) to write up a G-Code macro/script for other G-Code senders, think @neilferreri himself has done this for CNCjs. I probably wouldn’t throw this into the mix yet though, just a last resort.

I’m sure it is just some misconfigured flag/setting causing the incompatible with Carbide Motion.


(Matt B Hoover) #17

I just tried 1.1f, with no changes at all to config.g or any other firmware files. And still get the error when connecting. Any other ideas, anyone? Thanks!


(Neil Ferreri) #18

That’s coming from Motion. Hindsight, that has always been coming from Motion and probably throwing an error because you DON’T have that stuff enabled.
This is a Shapeoko, right? I don’t use Motion, but does it “think” you have a Nomad?


(Neil Ferreri) #19

Macro with CNCjs:


(Matt B Hoover) #20

I don’t think it does, as I’ve now entered the defaults as DEFAULTS_SHAPEOKO_3.

But still no joy.