search

terjeio / ioSender

A GCode Sender for Grbl and grblHAL written in C# (Windows only).
BSD 3-Clause "New" or "Revised" License
219 stars 66 forks source link

stop and hold issues and first live run on an actual machine #7

Closed jschoch closed 4 years ago

jschoch commented 4 years ago

stop doesn't seem to be immediate, hold is though. If you are in a hold state and you stop it get stuck in a hold state and you have to reset.

In the other senders I believe stop will be immediate canceling the job and halting. I ran an adaptive clearing job which had a long 180 mm cut and a short 20mm return. I issued stop at the beginning of the 180mm move but it did not stop until after the 20mm return move. Not what I was expecting.

other than that it worked great

terjeio commented 4 years ago

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 commented 4 years ago

Latest release just out should behave better.

jschoch commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

terjeio commented 4 years ago

Fixed now.

jschoch commented 4 years ago

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 commented 4 years ago

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:

jschoch commented 4 years ago

yup, this is with bart's grbl.

jschoch commented 4 years ago

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 commented 4 years ago

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.