The other day @gmack asked about documenting the specifics of the Feedhold signal, and while there are already many posts on that topic, they are a bit scattered in various threads, so I figured I would try and tell the full Feedhold story here in case anyone is interested (and since I have been playing with this, so I might as well dump my notes)
- Let me steal a pic from another thread to illustrate where Feedhold signal pins are on a v2.4 controller:
- the corresponding female connector is a .100" pitch 2-pin header from the Molex KK-series
- As far as I know, this Feedhold pin header exists on all revisions of the Shapeoko controller (at least on 2.3, 2.4d, 2.4e which I guess covers 99% of the Shapeokos in use)
EDIT Aug2020: some folks now have a PCB riser board, for them the feedhold pins are the two OUTER pins of the “F” connector (left pin is signal, right pin is ground, and the middle pin is 5V so make sure to not use it or short it to the left/right pins):
- Just like other switches, this is a NO (Normally Open) input, and shorting the two pins triggers the input. So one would typically wire a momentary switch to it.
- Feedhold is a built-in functionality in GRBL: it is triggered either from activating a physical input (those pins on the Shapeoko controller in our case), or when sending the “!” character to GRBL
- When feedhold is triggered, during a run, by default it would (only) stop motion.
- The current Shapeoko firmware in the controller uses the vanilla GRBL 1.1 code (available here),
- HOWEVER, a long time ago, Rob posted the GRBL configuration file used to build the Shapeoko firmware, and if one makes a comparison between GRBL 1.1 stock parameters and this Shapeoko specific config.h file, among a few other changes there are two lines that impact feedhold behavior:
// This option causes the feed hold input to act as a safety door switch. A safety door, when triggered, // immediately forces a feed hold and then safely de-energizes the machine. Resuming is blocked until // the safety door is re-engaged. When it is, Grbl will re-energize the machine and then resume on the // previous tool path, as if nothing happened. #define ENABLE_SAFETY_DOOR_INPUT_PIN // Enables and configures parking motion methods upon a safety door state. Primarily for OEMs // that desire this feature for their integrated machines. At the moment, Grbl assumes that // the parking motion only involves one axis, although the parking implementation was written // to be easily refactored for any number of motions on different axes by altering the parking // source code. At this time, Grbl only supports parking one axis (typically the Z-axis) that // moves in the positive direction upon retracting and negative direction upon restoring position. // The motion executes with a slow pull-out retraction motion, power-down, and a fast park. // Restoring to the resume position follows these set motions in reverse: fast restore to // pull-out position, power-up with a time-out, and plunge back to the original position at the // slower pull-out rate. #define PARKING_ENABLE // Enables a special set of M-code commands that enables and disables the parking motion. // These are controlled by `M56`, `M56 P1`, or `M56 Px` to enable and `M56 P0` to disable. #define ENABLE_PARKING_OVERRIDE_CONTROL // Default disabled. Uncomment to enable
If you did not feel like reading that, here’s the TLDR: upon detecting feedhold, the controller will stop motion, memorize its current position, retract slowly, then stop the spindle (and now the router, if you have a BitRunner. It basically does an M5), then retract faster, almost up to the top of the Z axis (top - 5mm, just like when one starts a G-code file generated from Carbide Create)
This is a very long-winded way to explain what…Carbide Motion has been doing for ever: the “Pause” button trigs a feedhold.
After a feedhold is executed, GRBL waits for a special command to resume where it left. That’s part of the “safety” side of it (imagine if the machine could resume motion as soon as the feedhold is released…that would be both inconvenient and dangerous)
There is no dedicated physical signal available on the controller to do a “hardwired” resume. It is doable to reassign one of the existing signals to act as a feedhold resume, but it means rebuilding the GRBL source code, not for the faint of heart. @neilferreri also dropped a good tip recently if you consider doing that based on a 2.3 board: DON’T use the E-stop signal because of this
(EDITED) So what Carbide Motion does when you click “Start” after “Pause” is (most probably) sending the GRBL command character “~” to the controller to resume.
Upon receiving a Resume command, GRBL will reverse the feedhold sequence: it will move away from the parking position (Ztop-5mm), plunge back towards the material at a relatively fast rate, then when it gets near the Z position where feedhold happened, it will stop, turn the spindle back on (or router via BitRunner), and proceed to plunge slowly back to the original depth where it left of, and then it will continue the execution of the toolpath. Which is quite a nice feature!
(EDITED) If you are using Carbide Motion, there is therefore not much added value to wire the Feedhold input: the “Pause” and “Start” buttons are already managing that for you.
- You may still want to have a robust backup/alternate way to tell the controller to halt: the wired Feedhold signal goes directly to GRBL, so it will work even in the event of a loss of USB communication between Carbide Motion and the controller, or if your PC freezes, or if your mouse is not within immediate reach, or anything of that sort.
- If you do use a hardware feedhold switch, you will need to activate it a second time after the parking movement, for CM to re-enable the “Start” button, which can then be used for resuming the job (assuming the USB connection to the machine is still alive)
If you are using another G-code sender, you can resume by typing “~” in the G-code console.
Feedhold is arguably a weak safety feature : it relies on software to execute correctly to stop things, and unless you have a spindle or router+BitRunner, it will not remove power from the router. This has been debated multiples times here, but as far as I am concerned:
- Feedhold is for the “wait, that does not look right, let me pause this job and think” moments.
- An actual E-stop killswitch which removes power from EVERYTHING is for the OH S*** moments, when you need to act now and think later, and so be it if you mess up the current job.
Feel free to comment, provide additional info, point out my mistakes, and I’ll edit this post.