[Grbl_Esp32 Issue#91] Jog cancel/Feed hold issue

I have encountered a problem with cancelling jog and also using feed hold. I have only encountered this on the GrblESP version and have not been able to duplicate the problem on the AVR version. I downloaded the current GrblESP WebUI version and flashed it to 2 different ESP32’s and used different USB cables and ports on my computer to try to eliminate that part of the hardware. What I flashed was a totally unmodified version except for turning line echo on as an attempt to debug it. I tried it without echos and the problem still was there. So here is what it is doing in each mode:

When a jog is issued the jog starts fine, but occasionally after issuing the jog-cancel realtime command the jog slows to a slower than programmed feed rate and the actual feedrate from timing isn’t even close, but it doesn’t stop. While this is going on status reports are still being sent and the machine state remains in “Jog”, the position is updated, and the buffer state shows one planner block used (14) and the entire serial buffer available (128). If I send another jog cancel command the planner buffer remains 14 but the serial buffer updates to 127 indicating that it was sent. Here are some status reports and echoes:

(G20 was active with $13=0 so the equivalent programmed rate was 2540mm/min)
[echo: $J=G90G53F100X1000]
ok


……. (left out a bunch of status reports but another jog-cancel command was sent here)

When it gets into this state the timed feedrate from status report updates is about 3mm/min (0.1in/min) even though the status report says it is going 600mm/min. This is typical when I reproduce it using jog.

I will mention that I also investigated my GUI to see if there was something there that would cause this and found nothing, but I will explain how my jog buttons work. I have X+, X-, Y+, etc buttons that when pressed fire the MouseDown event. This event simply assembles the string to send for the jog command based on current user selections and then sends it using a SerialPort.write command. I have a flag so this event only fires once per press with no repeating when holding down. Very simple. If the user selected “continuous” jogging, then the event just sends a large value, which I set to 1000 “current units” (G20/G21)for now. When the button is released or the cursor moves outside of the button bounds, either the MouseUp or MouseLeave event fires, which simply sends the cancel-jog realtime character to the serial port. These don’t have a flag of any kind to prevent sending the jog cancel command. I went a step further and added a button that when pressed sends the cancel-jog command so that I could see if sending another one would stop the errant behavior. It didn’t work as shown by the last status report above. If I keep pushing the extra button the serial buffer keeps decreasing by one for each press.

Now on to feed hold which I would think is related. I decided that I would just not use $J= jog commands and would just use G-code commands so I modified my routines, which didn’t entail much. Now the MouseDown fires and sends something like a G90G53G1F100X1000 to the serial port. The MouseUp and MouseLeave events do the following: Issue a feed-hold, wait for the status report to show “Hold:0” to indicate the motion has stopped, and then issue a soft-reset command to flush the buffer. When doing the same as the above jog description, the Echo from the mouse down is as expected, and usually you see a “Hold:1” then “Hold:0” then the reset, but occasionally the machine will again go into a Hold:1, slow down , but never stop and never get to Hold:0 When this happens, issuing feed-hold, or cycle start commands doesn’t do anything but show up in the reported serial buffer bytes available. Here is what this one looks like when it works:

[echo: G90G53G1F98.42X1000]
ok












(Feed-hold sent)



Grbl 1.1f [‘$’ for help]

and below when it doesn’t work. Note this time it actually stopped, but never went to Hold:0 and hence my GUI never sent the reset command.

[echo: G90G53G1F98.42X1000]
ok










(Feed-hold sent)

I have only investigated with $13=0, but in G20 and in G21, and it seems like I can duplicate the problem easier when in G20, but it has done it in both G20 and G21. Also I have tried fast click and release and slow click and slow release on my buttons and when it does it is very random. It doesn’t seem like click-release-click-release is any different than click – wait – release – click – wait – release. Somethines it will do it right on the first click/release, and sometimes it takes 20-50 click/release cycles before it will do it.

Sorry I can’t give more insight other than what it is doing because I don’t have good C/C++ coding skills.