Jogging Keeps On Going and Going!

gSender 🐛 Bug
#1

I’m getting frustrated that every iteration of gSender is NOT FIXING the bug with jogging endlessly.

You folks obviously don’t know what is causing it. It has been random happening in every axis for me. Sometimes it doesn’t cause any damage, but that can’t be said for the Z axis movement. At least, it stops before it gets to China, but only because I don’t have that big of a machine.

Whether one holds the keyboard combo down or uses the on-screen buttons holding it down just a little too long will set it off until one can hit STOP on-screen.

I’m getting tired of it ruining wood.

2 Likes
#2

As with a couple of other bugs, I wonder if this is a gSender problem or an Arduino problem. I have experienced it again recently. When it happens, copy the last few commands showing in the console in case it gives useful data

#3

I don’t believe this problem is going to be solved from user anecdotes.

It’s going to take some intense logic analysis.

#4

Hey folks,

Obviously this is frustrating to you. It’s not a highly recreatable or even highly reported issue, but it’s something we’ve kept an eye on.

We’ll have some fixes aimed at this in the next build, specifically for the UI buttons but also some changes to key mapping functionality.

There is no concept of “long presses” in Javascript, so we have to be creative to simulate the difference between a single click and and holding the button down. Any time you “click” the button, an event fire that starts a timeout. If the button is released before that timeout occurs, the timeout is cleared and a single jog command is issued. If the timeout is not cleared, a continuous jog command is sent, and when the button is released a jog cancel realtime command is sent. This is the same for the UI buttons and keybindings, although there’s a bit more logic for the UI buttons since other mouse events need to be accounted for (like moving off the button needs to cancel as well since a button mouse-up event won’t fire if the mouse isn’t on the button).

Changes we’ve made in the next build are

  • Slightly longer “timeout” between single jog and continuous jog to account for different hardware capabilities. This will also reduce situations where multiple “continuous jog” timeouts are started. It should still feel responsive but maybe won’t be quite as touchy.
  • Rewrite of jog button component to make it more responsive
  • Modifications to the hook logic we’re using on UI buttons to prevent situations where the jog cancel wouldn’t send.
  • Jog cancel and continuous jog sent directly using write over using feeder to reduce situations where the continuous jog command might be sent AFTER the jog cancel.
  • Jog cancel key-up uses leading throttle similar to physical buttons.

If you continue to experience this issue in the next release, let us know. Contrary to your post “anecdotes” are useful - if you can tell us specifically which situations it happens in (like, “I was clicking multiple times and it ran away”, “I hold the button and it never stops”, “my keybind is (shift-x) and letting go of shift and not X caused it to not stop”). Console output is also useful, for finding situations where the realtime jog cancel wasn’t sent. Even just knowing what your keybinds are is useful.

Cheers,
Kevin

1 Like
#5

Of course they’re useful, but apparently not in this case. For me, when it happens its usually while I’m in the middle of a job. I have little idea why it did it. I’m just trying to sneak my way to a Z-zero location, when WHAM! happens. In another case, I was able to catch a “run-away” bit by using the cancel button in the middle of the screen jog buttons before it struck something.

I’m sure your jogging controls are working the way you programmed them.

#6

Jog fail on 1.0.5, Mac OSX
I was using G38.2 commands to check how square the mill was:
Approaching touch plate in +Y direction to get a Y value, jogging -Y a bit, moving sideways in X direction, getting another value for Y.
One of the -Y jogs had to be aborted. Console log follows. End of log is the abort.

Note the line
client $J=G21G91 Y-1000 F1000
instead of
client $J=G21G91 Y-0.5 F1000


 LOG 

client G0Z3
ok
feeder G10 L20 P1 Y0
ok
feeder G10 L20 P1 X0
ok
client G38.2Y30F40
[PRB:107.525,316.190,-78.905:1]
ok
client G38.2Y20F20
[PRB:107.525,322.355,-78.905:1]
ok
feeder G10 L20 P1 Y0
ok
feeder $J=G21G91 Y-0.5 F1000
ok
feeder $J=G21G91 Y-0.5 F1000
ok
client $J=G21G91 X1000 F1000
ok
client \x85
client G38.2Y10F20
[PRB:269.875,322.335,-78.905:1]
ok
feeder $J=G21G91 Y-0.5 F1000
ok
feeder $J=G21G91 Y-0.5 F1000
ok
client G0X0
ok
client G38.2 Y10F20
[PRB:107.525,322.280,-78.905:1]
ok
client $J=G21G91 Y-1000 F1000
client \x85
ok
client \x18
ALARM:3 (Abort during cycle)
Grbl 1.1h [’$’ for help] LongMill MK1 build Feb 7, 2022
[MSG:’$H’|’$X’ to unlock]
client $X
[MSG:Caution: Unlocked]
ok

#7

The problem hadn’t happened in a long time, UNTIL I was using G38.2 commands again yesterday!
Earlier report with log


1 Like