Carbide Motion (428) sending wrong config data for x/y size? (grbl params 130, 131)

Software Carbide Motion
8

@Luke, I know you’re a GRBL setting guru – does this make sense to you?

9

The plot thickens… I just dug my 417 build out of the trash, and re-ran “Send config data”, with Shapeoko 3 selected, and it’s sending the same (wrong) values; so this isn’t specific to the 428 build…

...
(445): <- ok
(444): -> $132=80
(443): <- ok
(442): -> $131=850
(441): <- ok
(440): -> $130=845
...

Update/Add: I have also tried fresh installing the 428 build on a different OSX laptop that has never run CM – I still get the same issue: console shows CM sending the wrong values for params 130, 131.

(Updated original post to add this detail)

10

Maybe if you de-install your Carbide Motion, remove the defaults and settings in the Windows program files on your computer then reinstall. I know at some point there was an issue with CM or CC settings and default not clearing during an install but maybe you want to wait for support to respond.

11

Can you confirm if you are using a HDZ?

1 Like
12

Can you confirm if you are using a HDZ?

Thanks for the reply, @Luke! Yes I am—and selected HDZ in settings.

(Updated original post to add this detail)

1 Like
13

@geoff, why don’t you just send the correct values through the MDI?

14

I think that’s what I’ll have to do to limp along, but there are a couple things wrong with this:

  1. Requiring customers to fix their setup via MDI is pretty janky.
  2. If there’s a bug, the Carbide team should know about it – this is the main reason I’m bringing it up. It’s very unlikely I am the only one impacted.
  3. I have no idea how this may impact setup of the Bit Setter I just bought (given the importance of a correct coordinate system), so this purchase, for now, is wasted. (I am confident there will be a fix, given what an awesome team Carbide 3D has)
  4. Not knowing how my coordinate system is going to change is a big pain as I’m in the process of milling a new work table for my SO3, and need its features to be lined up relative to the system’s hard programmed center point.
1 Like
15

Agree with everything you said, but I don’t want you to get stuck waiting for an update or reinstalls.
The BitSetter is located based on your input of machine position… Shouldn’t be impacted.

I’d use machine positions for this as well. You don’t want a design to fail because of an issue with your UI. Those grbl settings are stored on the controller, and they shouldn’t change unless you want them to.

Of course. But it’s Sunday night and you might want to use your machine.

1 Like
16

Please see this:

1 Like
17

Thanks, @Luke — will give it a try!

Two questions:

  1. What order should I do these steps relative to Bitsetter setup? Should I install bitsetter and position over it, initialize with Bitsetter but without HDZ, then send the commands you showed?
  2. I’d love your two cents on why CM is sending XXL values for 130, 131 — is this a non-issue? Am I crazy for worrying?
18

Setup the machine with the HDZ first then setup BitSetter.

There might be an issue with the config data being sent over - that said I don’t think it will cause a problem as it’s just the soft machine limits which as standard are not enabled.

1 Like
19

Sorry for being slow—the instructions you linked to say

Setup Shapeoko - select your machine Do not select “Use Shapeoko HDZ”

Your last message says

Setup the machine with the HDZ first then setup BitSetter.

Is the current guidance for HDZ + Suckit users to select HDZ? Or leave unselected and manually send the MDI commands from the linked article? I just want to make sure I’m doing this right…

(And I’m assuming that the bitsetter initialization won’t over-write the previous manually sent MDI commands :crossed_fingers:)

1 Like
20

If you have a HDZ and suckit you DO NOT CHECK"enable HDZ"

You will need to setup the HDZ first BY manually sending the settings.

When happy you have the correct travel go back to settings and enable the BitSetter, but DO NOT click the send config data again. I think that should work as there are no GRBL settings that directly relate to the bit setter that are stored on the machine.

1 Like
21

Fantastic — thanks, @Luke!

Especially appreciate the clarification that Bitsetter setup is CM only and isn’t sending/overwriting GRBL settings :pray:

22

@Luke Does Motion use the GRBL machine limits ($130 & $131) to calculate its rapid positions?

23

@neilferreri I don’t believe so.

@geoff - keep us posted.

1 Like
24

First: thanks for all the help!

Second: I think your advice steps mostly worked. By deselecting HDZ and manually changing the recommended params (3, 102, 112,122, 132):

  • Good: I can again use the rapid positions without crashing into the X-stops
  • Bad: I can no longer jog through the full Z range offered by the HDZ in the Jog pane; I can only jog down 99 millimeters from the top of the HDZ

I’m guessing this is because CM jog controls ignore param 132 and instead just look at whether you have HDZ enabled in settings.

I can live with this for now, but would love others suggestions if you have them!

Best bet may be to remove my Suckit ears and try to find a different solution for dust collection. Given the popularity of the Suckit product, this feels like something to fix in a future version of CM: right now if you have an HDZ, as I understand it you need to choose between using a Suckit, or being able to jog through your full Z-range.

(Why is it a problem not being able to jog through the full z-range? well if I can’t jog to the spoil board, I can’t set it as my Z=0 to surface it)

1 Like
25

We “might” have something to share in the next few weeks.

5 Likes
26

I was hoping something like that might be in the works :crossed_fingers:

2 Likes
27

You sure know how to tease :+1:

1 Like