stop and hold issues and first live run on an actual machine about iosender

[terjeio]

Stop: I have added a stop real time command to grblHAL, obviously that does not work with vanilla grbl. Sending one line at a time (not stuffing the input buffer) solved that, but then maybe not dependent on how you perceive Stop. Stop sending or stop machining? Stop sending is how it is implemented. To stop machining immediately use the red Reset button.

Hold: works with both grbl and grblHAL for me except one scenario, Hold followed by Stop and Rewind, then Start again. Will look into that.

[terjeio]

Latest release just out should behave better.

[jschoch]

maybe call it slow stop and keep it as an option. I've noticed that UGS at least sometimes throws an alarm and loses position when stop is hit. a "slow stop" would be nice although when you machine is about to crash you tend to panic and you already have 3 options so maybe 4 isn't better.

I hope to test your grblHAL port fairly soon, my rebuild still has a lot of things to do though so the backlog is long.

[jschoch]

If you are in a "hold" state you can't stop the program. This is available in other senders. Is there a workaround and/or is this intended behavior?

[terjeio]

Not intended, I will fix it in the next release.

[terjeio]

Fixed now.

[jschoch]

this seems to be misbehaving again in .18. If I mid job and hit "hold" I can no longer issue a "stop". I can only "start" or "reset"

[terjeio]

It works as it should for me with grblHAL firmware, but not with grbl. So I guess you are testing with grbl?

The Stop button behaves differently with grbl, unlike for grblHAL it should pause sending and let the the motions currently buffered in the controller finish. For grbl I have added the following fixes:

• In Hold mode, Stop issues a reset command.
• When sending, Stop pauses sending and waits for controller going Idle before Cycle Start is reenabled. This is currently not working and is a regression.
• When waiting for controller going Idleafter a Stop another Stop issues a reset command.

[jschoch]

yup, this is with bart's grbl.

[jschoch]

maybe should re-open. This morning I tried to just plain stop with Bart's fork and it seemed like the GUI was in some sort of mode that wouldn't accept the button press. I had to mash it quickly to get the stop to go through. I did not attempt to enter "hold" mode first this time.

[terjeio]

Grbl: Stop does only stop sending lines, if a move is in progress (and lines are already buffered) it (they) will complete first and then idle state will be entered. This is how many other senders does it and is really pausing transmission only. I have to say I do not like it this way.

grblHAL: Stop is more like an eStop button, it cancels the current running program and rewinds it. It is not as "hard" as a reset but nearly so. I have added a new realtime command for it.

I see there are still some interlock issues between modes of operation and available functionality. I got my lathe and MPG up and running again today and a couple of new ones appeared... So I guess I need to spend more time using my machines, not only programming for them.