[grbl Issue#1026] Motion continues after Feed Hold and then Cancel

#1 – winder 于 2016-06-27

@DasWookie What gcode sender are you using? This doesn’t sound like a GRBL bug.

#2 – DasWookie 于 2016-06-27

I’m using bCNC, but I’m hitting the hold/cancel buttons for the connections to grbl. I’m using 9j of GRBL, with variable spindle disabled (connected to a relay to turn the DeWalt DWP611 on/off) but otherwise everything else is bone stock settings in GRBL.

#3 – chamnit 于 2016-06-27

@DasWookie : This definitely sounds like a GUI problem. You’ll need to see how the button key bindings are set in bCNC. Particularly, whether or not the Cancel button tries to set the system back into IDLE when canceling.

#4 – DasWookie 于 2016-06-27

Hmmmm. Interesting. As far as I can tell, when Cancel is issued to GRBL, via the cancel button (set pin to ground) then what I’m seeing happen on the bCNC UI tends to be something along the lines of commands being issued (maybe just the buffer’s worth) but ignored by GRBL. Eventually the UI “catches up” with the cancel command, and recognizes that the run was aborted. I suppose as a diagnostic test I could hit feed hold, yank the USB, and then hit cancel. That would tell me if the UI was somehow involved vs if it’s GRBL trying to coast down.

The observed behavior differs between when I just hit Cancel straight up, where everything Just Stops vs when I hit Feed Hold, and THEN hit Cancel.

#5 – gerritv 于 2016-06-27

You need to control Grbl from the gui only, not some combination of hw buttons and gui. When you press a hw button the gui has no way of knowing what you did or intend.
Does bCnc not have buttons on its ui to accomplish this?

#6 – DasWookie 于 2016-06-27

@gerritv: Yes, bCNC has a pause button / feed hold. I have to ask tho, then what’s the point of having feed hold, cycle start, and cancel button pins, attached to interrupts, on GRBL if you espouse never using them and only using a UI?

#7 – gerritv 于 2016-06-27

The issue is that there is no direct feedback to the GUI. Unless it is programmed to see the status response and do something appropriate, then you get this uncoordinated result.
There are many use cases for Grbl, for some those external pins are useful, for others not.

I’m not sure how GrblPanel would react to this scenario, I will try it out before the next update. bCnc apparently is not happy with the confusion caused.

#8 – DasWookie 于 2016-06-27

My expectation is that on cancel, any further commands from the UI, and for the current buffer, would be ignored. I’m heading into the shop shortly and will try and test the issue of what GRBL does on Cancel when the UI is disconnected to see if this is indeed a UI issue, or a GRBL.

#9 – gerritv 于 2016-06-27

Just to clarify, you are running a gcode file from bCnc, you press a physical Feed Hold. the machine stops in its tracks. Where do you press Cancel? There is a Reset pin, no Cancel.

Chances are high that bCnc keeps sending lines until it recognizes the Hold status. There might already be some in the queue inside Grbl. You could Reset on the Gui (doing this on a pin of course relates no knowledge to the gui in time for it to not send more data), which kills you run or you could use Resume to continue of from where you were. I assume that when you are taking your measurement you are not moving the position? Because if you are all bets are off, the machine and the Gui’s idea of where things are is no longer related.

You might want instead to look at making use of the Door Open feature instead.

#10 – Endlesshunt 于 2016-06-27

GRBL on the Arduino might know to ignore any further commands from the GUI on a Feed Hold. But the GUI might see it as that the previous command was not executed and try to resend it on the Cancel/resume. This is if the commands are not fed back to the GUI as Gerrit said above.

If the GUI is programmed to listen to the Arduino for button presses then the GUI should react properly.

If it is not programmed to listen then it would not know that the Feed Hold was pressed and could only believe that the previous command was not executed and resend it the moment the Cancel/Resume button is pressed and GRBL starts to listen for commands again

#11 – winder 于 2016-06-27

When the soft reset button (called cancel here) is pressed, GRBL sends its startup messages. At this point the GUI should reset everything but the machine location (or reset everything, and re-apply the current location from the next ? query). This is how UGS handles an external reset.

#12 – gerritv 于 2016-06-27

thanks Will, does that include cancelling the gcode file? Cancel would seem to mean precluding a Resume.

#13 – gerritv 于 2016-06-27

I confirmed how GrblPanel reacts.
On Feedhold (physical press) the gui goes into Hold mode (i.e. the Resume button is lit.)
Pressing Reset (physical press) at that stage causes Err: on the waiting gcode line and stops sending more. You can’t at this point continue the gcode send, you have to rewind and in essence start over.

I will clean this up a bit in the next release of GrblPanel to avoid the “Err: Missing Feedrate” and just stop.

@DasWookie Can I assume that you are pressing the Cancel/Reset button if what you measure is not happy result, otherwise you would use Resume to go on with the job?

#14 – vlachoudis 于 2016-06-27

If you do press the hardware feed hold from grbl, bCNC will detect and report that is on hold state. However if you press the hardware reset, then it will report Idle and bCNC will continue streaming.
If you want to stop the streaming after pressing the hardware feed hold you can press the software “Stop” in bCNC which will make a soft-reset and stop streaming.

@winder proposed a nice idea, when it detects the welcome message from grbl to stop any streaming

#15 – vlachoudis 于 2016-06-28

I’ve added in bCNC the detection of the welcome message of grbl and stop any run that is going on

#16 – lalo-uy 于 2016-06-29

Great

2016-06-28 15:32 GMT-03:00 Vasilis Vlachoudis notifications@github.com:

> I’ve added in bCNC the detection of the welcome message of grbl and stop
> any run that is going on
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> https://github.com/grbl/grbl/issues/1026#issuecomment-229140407, or mute
> the thread
> https://github.com/notifications/unsubscribe/AK4bcQ-fqOFvVfdR39GIOHkMqBDKCdNcks5qQWi4gaJpZM4I_H1x
> .

#17 – juliolarab 于 2016-07-01

Yesterday while I was programin my oun GUI I found exactly the same, as i’m in the development stage in the progam i print to the consoie constantly to track it. what i found is that when a hold command is send, GRBL goes to a controlled stop , but it seems it does on the movement it is already doing and so the buffer is not completly processed. When you send a resume there is no problem at all, but if you try to cancel ( in my case via sofware there is no grbl command in real time like Hold itself ot ? to bypass the remainder in the buffer, so if you send a reset ctrl-x, first what was left in the buffer is execcuted beforre the reset. I also try to use the serial.flushOutput() to see i it was posibble to get rid of that remainder, but with no luck. What I dont really know if that remainder is left in the serial buffer, it is strange that serial.flushOutput() seems to do nothing when it supposed to do exactly what is needed, or the remainder is inside catched in the memory. But what is true is( as far as I can see ) is that if yor send a Hold, inmiediatly suspend any other commamd, to be sure that the last thing you send was the hold, ant then sends a resume there are from one to three commands sended before the feed hold that are executed

#18 – juliolarab 于 2016-07-01

!onhold

!canceled

AS you can se this time, three commads where pending

#19 – chamnit 于 2016-07-01

@juliolarab : You are incorrect. First, Grbl always flushes the planner buffer and serial buffers upon a soft-reset (ctrl-x). This includes anything it has been sent and is pending parsing any execution. Grbl absolutely does not wait before resetting or allow anything to execute. It resets the system in real-time. Second, if the reset doesn’t throw an alarm, which it will if Grbl is in motion at that instant, it’ll start to accept commands immediately. Problems like you have described are likely bugs in your custom GUI and a general mismatch on how Grbl expects the data and how you GUI expects it.

As for serial flushing, Grbl does not allow an explicit command for this intentionally. This is to prevent novice GUI writers from restarting/resuming jobs without resetting the g-code modes. If you don’t reset the modes, instead of restarting the way you’d expect the first time you run it, your job can crash. This is standard behavior for CNC machines to always require a soft-reset to bring the machine back to defaults.

#20 – juliolarab 于 2016-07-02

Let me explain what i’n doing. the algorithm reads and as sonn as detects an ‘ok’ write lines from file until 124 bytes, this reserve is one for ? commans and 3 for appendeng a $G in case line is like to change any G, When the Hold is requested the part that writes is inhibited, so it continues reading and sendinf de polled ? (.125 sec). So as seen in the first screen the Hold state is confirmed fon GRBL, and as the ? arent stooped the data on the DROS must be true. as I say earlier if you resume no problem, but if you send a ‘~’ to exit from the Hold state (in the algorithm also breaks) I’m 100% sure nothing else is writen, and the system moves as you see fron the change in the DROS where those commands come from.?

#21 – juliolarab 于 2016-07-02

Thanks for your time,

#22 – juliolarab 于 2016-07-02

In resume I’m doing

User request pause = send ‘!’

if user request resume = send ‘~’
if user request cancel
option 1 = send ‘~’
option 2 = send ‘~’ + send ‘^X’ i’m using (b’\030′)

I beleive the option 1 shoulb be enought , I can see a real reason for resetes the system if already has been processed.
In both cases ofter the ‘~’ the system moves, and in the secon the system enters in alarm becuase choose that option when compile

#23 – chamnit 于 2016-07-02

@juliolarab :
– Please read the “Interfacing with Grbl” Wiki carefully. I’ve outlined there how to communicate with Grbl and how it works. It’s fairly complete. Try not to invent your own comm algorithm. A lot of your questions can be answered there with careful study.
– If you reset Grbl while its running, it’ll throw an alarm because it was stopped while in motion and can’t guarantee position due to a non-controlled deceleration. Don’t resume Grbl during a feed hold, if you intend to maintain position and avoid an alarm.
– Realtime commands do not enter the serial buffer. They are picked-off from the serial interrupt directly. So don’t count them.
– I highly suggest that you sit down and directly interact with Grbl to understand what Grbl is doing before posting more questions. Or since you obviously know how to program, look at the source code, where everything is well commented and laid out. This is generally a misunderstanding how Grbl actually works, as evidenced by dozens of GUIs that control Grbl out there with no issues.