I just upgraded CM to latest build (428) to get ready to install my bitsetter and now when I use CM’s rapids I’m crashing into my X limits.
Edit/Add: I am running CM on OSX, and my machine is a SO3 with an HDZ (cc @Luke)
I tried re-sending config data and it looks like CM, when set to Shapeoko 3, is sending the wrong configs:
(2264270): <- ok
(2264269): -> $132=150
(2264268): <- ok
(2264267): -> $131=850 <-- should be 430 for SO3
(2264266): <- ok
(2264265): -> $130=845 <-- should be 420 for SO3
Anyone else having this issue?
Edit/Add: I have tried using an old image of the 417 build, and have tried fresh installing 428 on another machine (that has never run CM before) and am having the same issue. When I view the logs, CM is still sending SO_XXL value for params 130 and 131. (cc @luc.onthego)
Look at the actual table size and not what is shown in the drop down menu.
Its confusing because the drop down menu selection for the type of Shapeoko you have is NOT a direct correlation to what is actually selected in the ACTUAL SIZE of table dimension.
The drop down selection menu will always default to Shapeoko 3 regardless of Shapeoko model
I’m not sure I understand your suggestion: I am not basing my conclusion that it’s sending the wrong config data off of the displayed table size, I’m looking at the actual values it’s sending to the Shapeoko via the log.
Here’s what I’ve tried:
Open Carbide Motion, connect and initialize
Select “Settings”
Select “Setup Shapeoko”, "select “Shapeoko 3” (here it shows the correct table dimensions: 420 x 430)
Select “Send Config Data”
Select “Open Log” to see what was sent.
At this point, I see that Carbide Motion has sent:
(232): <- ok
(231): -> $131=850
(230): <- ok
(229): -> $130=845
(These are the dimensions of a Shapeoko XL)
I can override these settings via the MDI, but it seems like a big problem that Carbide Motion is sending the wrong config data for a Shapeoko 3.
Has anyone else encountered this issue? Does anyone know where I can download previous builds of CM? I could try to see which build introduced this bug.
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.
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.
I think that’s what I’ll have to do to limp along, but there are a couple things wrong with this:
Requiring customers to fix their setup via MDI is pretty janky.
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.
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)
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.
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.
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?
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?
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.
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 )
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.
)