That just sets your grbl settings.
This is a Carbide Motion thing. It obviously works for many, but I gave up years ago and have never found a reason to look back.
I have a suspicion that CM is sending that M56 and they must have that enabled in their “updater” version.
If you want to use Motion, use Carbide 3D’s updater or a hex they released.
I would, however then I can’ t use it with the SuperPID, which needs the changes compiled into the firmware. I have a support ticket in to Carbide3d, so once I get it resolved I will post the fix here.
Thanks for the help guys!
Maybe time to move on from Motion.
@WillAdams Do to you know if Carbide3D has their modified grbl source published somewhere?
We don’t modify the source except for commits which we share back.
My understanding is that it’s simply a matter of setting the compile defaults in the header to match the comments for Carbide 3D — if folks have difficulty with this please check in w/ the Grbl devs and support@carbide3d.com and we’ll try to help sort it out.
Grbl 1.1 from the updater and the hex linked above both allow M56.
Default Grbl does not. Setting the defaults in the config.h only affect the $$ settings as far as I can tell.
Even when I did enable parking in config.h (for the M56 command)…it still didn’t avoid the error message.
This is the M56 part, but you’ll need parking enabled too.
#define ENABLE_PARKING_OVERRIDE_CONTROL
Thank you, I’ll try that. In other news, Carbide 3d has decided via email they “don’t support this” – whatever that means. They don’t care, or pretend to know anything about SuperPID…but I do know it means this is my last Carbide3d product. I have a Nomad and a Shapeoko, but that’s all I’m going to buy. Extremely disappointed with this response.
I’m afraid that we’re a small, self-funded startup — we can’t afford to purchase one of everything, or work up the engineering effort to make everything work.
That said, this should “just work” — we use the same board for the Nomad and the Shapeoko, so the spindle control circuitry is all there, and is all used by our software — it should just be a matter of using the same pins / signaling as the Nomad does. The community has some notes on this sort of thing at: https://wiki.shapeoko.com/index.php/Spindle_Control
When you go down the road of any customization beyond OEM, i.e. custom compiled firmware, attaching third-party modifications (SuperPID) typically with any company, official support stops there.
This community, Reddit, etc is the next resort for support, with experienced members and Carbide3D employees with unofficial help.
Like I say, when I used a custom compiled Grbl firmware for my SuperPID (and other modifications) I also changed g-code senders as to me, I was going past the capabilities of the Motion software, and limiting my workflow and further customization.
Gotta ask yourself, is it worth to keep flipping compilation flags to try to get Motion to work, or take it as an opportunity to use another g-code sender. Not saying it isn’t going to be a bumpy ride still (learning curve).
This is your solution. You’ll be better off anyway.
Why do you believe you need a recompiled version for superpid? Plenty of people are using it unmodified with one.
Only recompiling to get PWM and Spindle on/off control using gcode…isn’t it necessary to recompile to turn those options on? If not, I would like to kick myself in the head for not realizing it.
If not, does someone have a Mac-compatible suggestion for a nicely featured gcode sender? Seems like most are Windows or Java-based.
bCNC is Python and should work well.
Neilferreri, thanks! This is the last switch that I changed, and now there is no error when I start Carbide3D! Thank you to you and everyone else that replied with their suggestions. I really appreciate it!
The PWM should had already functioned, but think I had to recompile for the enable to work, originally mapped as DIR (also to invert it, as low is on for SuperPID). Also did the PWM vs RPM tuning steps.
I think you can switch the DIR high to low with an option… $3=0 Direction port invert, mask
The spindle enable is actually not totally necessary either. If you connect the pwm output to the enable as well (a 10uf cap to ground wouldn’t be a bad idea…but it’ll probably work just fine without), there’s your enable.
I’ve been using UGS for quite some time now, it works well. I don’t like that it’s Java, but it does work well.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.