I have a Carbide 4 XL with a router on BitRunner and a Carbide 5 Pro 2x4 with a spindle.
When I use the pause button on the 4XL (bitrunner), the router stops moving, stops spinning and lifts up. It was nice because I could do what I needed for the pause and then continue the job from the stopping point.
When I use the pause button on the 5Pro (spindle), the router stops moving, but continues spinning and does not lift up. I know some are saying “normal operation”, but this is very annoying and seems like a safety issue. I pause jobs most often when something isn’t right, and I can clear the problem without having to start the job over from scratch.
It is possible the 4XL is running and older version of Carbide Motion, I’m not sure.
How can I change the 5 Pro to stop spinning and lift up on a Pause Button command?
Also, it would be nice if the job saved where it was on a non-emergency stop so I could call it back and continue a longer job when needed. Thanks for any help or input!
Both machines are running the same Grbl — it’s just that the SO5 Pro had dual Y-axis homing added, which meant something had to come out, namely lift on pause.
For a discussion of how memory-constrained Grbl is, see:
Wow, I did not realize the code was that tight. Seems like it’s time it got an update/upgrade/forked version for more capable hardware with extended feature-set.
Can someone explain (in simple terms) why dual Y-axis homing makes it where you can’t do something on the Z axis, and why the spindle has to keep spinning.
As a Shapeoko 3 owner, I use the pause option A LOT. This is basically a deal killer for me to upgrade, really hope this gets revaluated with future versions of the Shapeoko. Holding out hope that the Shapeoko 6 brings this feature back.
The Carbide Motion Machine Control Board which runs our machines has an Arduino for performing calculations and translating G-code into the signals to move the machine.
The Arduino uses an inexpensive chip which has extremely limited memory — it is frankly amazing that any significant functionality fits into it, let alone an implementation of a language specification:
which is well over 100 pages (though it is worth noting that there are no loops, variable, or branching codes supported).
At this time, there are more features coded into the Grbl source than will fit into the memory of the Arduino, necessitating that when compiling from the source:
one must pick and choose which features will be included and which will be excluded.
For the SO5 Pro, in order to support dual Y-axis homing, it was necessary to make room for it by removing something — lift-on-pause was commented out when compiling for an SO5 Pro.
Thanks Will. I appreciate the explanation. I do understand that software solutions are sometimes constrained by system variables and so choices have to be made.
The behaviour of the Shapeoko 5 Pro is consistent with how all industrial machines behave. It’s intended to freeze the machine, give you a chance to assess the situation, and resume immediately when ready. Additionally, the machine has a physical pause and power button that can be placed away from the machine. And in Carbide Motion, as soon as you hit “Pause”, you can then hit “Stop” rather than waiting for the machine to retract for a bit, then decide to shut off the spindle after several seconds. It arguably provides both faster and safer options to halt the machine if something is going wrong.
A macro would not take effect until the current buffer of instructions was exhausted — a single line can cause the machine to move from one corner to another, far too long for an attempt at intervention by a user.
Ughh! And the feed-hold prevents any further input.
And there is no other feature of GRBL that can be sacrificed other than spindle stop & lift on feed-hold?
I agree ColdCoffee. this is super important to me. I have a Shapoko pro and knowing this i’m so glad i didn’t get the 5 pro. because i use this pause so much. It’s my understanding that it isn’t dual Y-axis homing that is stopping the ability to pause. it’s the length of code. They had to remove the code the handles the pausing to add the code for dual Y-Axis homing. I have not yet taking a look at any controller code but I am a developer and this right away strikes me as crazy. There should be no real reason for this. i’m sure there is a reason. I just know it’s a reason that does have a way around it. They way around might be to costly to implement idk.
If you take a look at the link to the Grbl site, you will see that the limitation is the working memory of the Arduino platform it was developed to work on - 2kb. An impressive feat I would have to say. But certainly not conducive to future developments & feature add-ons.
I’m sure you have your reasons. But I find Arduino to be expensive and like you say very very small. I use Teensy boards for my microcontrollers. They are cheap, awesome, and have tons of memory. You certainly can afford to add a pause function if Teensy worked otherwise. I’m pretty sure everything you can do on Arduino you can do with Teensy. To me, it’s just physically smaller, easier to use, Arduino code will run on it. It’s just better. IMHO.
I understand where you’re coming from as it was an adjustment for me on a Shapeoko as well having had one since the original Shapeoko 3 with the “Pause” having the spindle stop and retract behavior.
I ran industrial CNCs in aerospace for almost 10 years. Pause on a Shapeoko is akin to “Feed Hold” on an industrial machine, so the S5Pro behavior is actually more standardized to the rest of the industry. It is intended to pause the machine where it’s at so that you can make sure it’s where you intend it to be. You can look on the screen and see if your relative position is correct for instance. You can’t do that if it has retracted. At that point on industrial machines you have two options, either stop/reset the program, or resume. You are locked out of controlling the machine in any other way. It is not intended to stop the program so that you can do other things. If that is needed, then after the pause, you need to hit the stop button on the screen.
The EStop is supposed to be used in an “OH CRAP!!!” scenario. It shuts power off to the motion system completely and I only use that in cases like something coming loose, or other scenarios where safety is at risk.
A further look at the Grbl GitHub brings a link to a version of Grbl for Arduino Mega2560. This provides a way for upgraded controller hardware that has more memory in future hardware iterations.
I appreciate the comparison to industrial machines, but this is not an industrial machine and more appropriately some of us are not industrial operators.
Industrial vehicles don’t have cup-holders, heated seats, backup cameras, etc. Yet I wouldn’t trade in my current car and give up any of those features. It’s really difficult to give up a really nice feature once you get use to it.
I use the “pause” feature when I need to redirect my attention elsewhere. Or fix one of my own mistakes, like adjusting clamps, dust boot height, clean up chips, lol and sometime I need to just stop and let me think about what just happened.
I understand the memory footprint decision, but suspect the decision makers may not have understood how important that feature was to the non-expert home user.
Hopefully the Shapeoko 6 will have something with enough memory to not only give us all the features we had, but also all the future features we don’t know we need yet.
Would an automated tool changing fall into this same (memory footprint) category? How about a “frame” feature like lightburn has to demonstate the area-bounds of the job before you start?
ATC is quite different — it is expensive and requires a dedicated compressor, as well as sacrificing some working area to a tool holder, and arguably for safety purposes, an enclosure.
The frame feature may be something which could be added to Carbide Motion, or perhaps it’s better for Carbide Create — we’ll have to see.