I added a momentary feed hold button wired into the Carbide motion board (v2.4e), which does a nice controlled stop on button activation, then resumes motion after pressing and releasing again. During a job today I needed to feed hold to reattach my dust collection, and the Z raised and router turned off after a few seconds. Clicking the button didn’t resume, so I went back to Carbide Motion and clicked the Pause/Start buttons.
The Z started to plunge but never started the router again, so I had to abort. Is this supported behavior?
Really ? The behavior I get (and we collectively documented in that thread) is that a first push on FH button will stop the movement, retract the router, then stop the router (via BitRunner), and a second push…only re-enables the start button in CM. Only when you click Start again in CM does it plunge back (router still OFF), then halt for a moment, starts the router (via BitRunner), and completes the plunge back to the depth is was paused at.
My BitRunner works as you would expect during FH/resume (restarting the spindle), just tested it 5min ago (for an…ahum…emergency), but it was with CNCjs not CM.
Let me be brave and test it again on a new spot - perhaps I got nervous and stopped it too early during the plunge? I didn’t want it to crash. Any particular reason to move Z before starting the router again via BitRunner?
The behavior is all in GRBL, CM or the FH button is only telling it to “park”, it retracts 5mm, stops the router, and retracts to the top of the Z minus 5mm. Upon Resume, it does the opposite, plunge from the top down to 5mm above where it was paused, stop movement, restart the router, and proceed to plunge the remaining 5mm. Scary indeed
That how GRBL implements it, I guess it is safer to only turn on the router when it’s very close to the stock (imagine turning the router on automatically when it’s at the top of the Z…potentially VERY unsafe for you, if e.g. you hit Resume by mistake or something)
You could change the grbl config to have the spindle start higher. I never liked the idea of plunging into the work and then starting the spindle.
It’d be nice to have that as a $$ setting option, so you wouldn’t have to recompile the source and flash the controller.
I posed this a few weeks ago. When you pause the router stops (BitRunner) and retracts. When you hit start the router plunges and at the last minute, seems like, the router starts. When you start a job after BitSetter the router comes to the front center and the router starts and then moves to start the job. I am not a fan of the pause method of restarting the router.
That’s how it works for me, too - but it took me a little while to work out what was happening!
I wonder if it might be better (if it’s achievable) for the FH workflow to start on either using ‘Pause’ or the hard-wired button, and ‘Resume’ or the button to, erm, resume, so they kind of work in parallel? Clearly, using the hard-wired button would need to activate the pop-up window on the computer, as does the Pause button.
The current workflow does seem to have a few too many steps.
@Julien Confirmed your behavior is repeatable here. I agree with the other posters that it may be more intuitive not to plunge before starting the router, but now I know.
Achievable yes, but where this stands in the queue of ideas for CM development, I could not tell you. You would have to ask @robgrz. My gut feeling is that while it would make things more consistent between the UI and the physical button, there is only one extra click involved (having to click “Start” after pushing the FH button to resume, and before the confirmation pop-up), also the physical FH button is kind of not officially supported yet, so it may not rank high in the priority list…
now I know.