UGS doesn't stop streaming commands when GRBL is reset via Reset/Abort pin

[dvsingletary]

When GRBL is reset via the reset/abort pin, it may or may not go into an ALARM state (this is dependent upon whether or not the machine is in motion at the time of the reset/abort). The alarm state is meant to indicate that the machine has likely lost it's position due to an abrupt stop.

There are certain cases where UGS is running a program but the machine is not actively in motion. The easiest to demonstrate is a program that contains a G4 dwell command. During the dwell, if the reset/abort is triggered on grbl, it resets the controller state but does not alarm. UGS continues to send the program even though the controller state has been reset. This can be bad! In the case where I found this bug, I was cutting a program in inches (G20) and a little into the program I saw I had forgotten to add my dust shoe, so I hit the button on my controller which is connected to reset/abort on grbl and it stopped the router but then made a rapid move to a position near the WCS home. Turns out the reset put grbl back into mm (G21) and UGS was still dumping the program to GRBL in inches.

Expected behavior: When GRBL is reset via the reset/abort pin, UGS should STOP streaming no matter what. I think the way to determine this is via the "Grbl 1.1h ['$' for help]" message grbl sends as soon as it comes up out of reset. If UGS sees this message while it's streaming gcode, it should stop.

I've been digging into the grbl code to understand this more, and I don't think this is specifically a problem with the grbl firmware (although an easy fix is to make grbl always go into ALARM if the reset/abort pin is triggered), because at least when it's in ALARM it won't respond to any additional commands from UGS.

I'm interested in learning how to set up a development environment for UGS so I can take a crack at fixing this myself but I wanted to see whether I'm missing something obvious about how UGS/grbl should behave first.

[winder]

There is some documentation about getting started with UGS development. Take a look and ask questions: http://winder.github.io/ugs_website/dev/getting_started/

I think you're right that you can determine that GRBL was reset by looking for the version string. You should be able to add some logic here:

https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-core/src/com/willwinder/universalgcodesender/GrblController.java#L197

[dvsingletary]

I've got a fix for this but it also requires a small fix for grbl to be more robust. I need to talk with the lead developer for grbl to understand if the fix I'm proposing there is the right way to go about it. In short, my resolution to this is:

1. UGS - needs to stop streaming commands when it receives the "Grbl..." version string. Currently it resets the buffers but doesn't stop streaming commands unless there is an ALARM from Grbl, and this only happens if Grbl is in motion at the time the stop/abort is initiated. There are some cases where this is not the case that can lead to a machine crash.
2. grbl - in order to prevent the two ships passing issue where grbl sends "ok" for a command, and is immediately reset/abort and sends the "Grbl..." version string at the same time UGS sends the next command string (and grbl interprets this command after the rest (bad)), a short delay needs to be added in grbl after receiving the reset/abort before recycling in the main loop. This delay will give time for UGS to send the next command and it will get dumped out of the serial buffer when the main loop cycles preventing it from being seen after reset.