Jogging Keeps On Going and Going!

[CrookedWoodTex]

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.

[saskia]

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

[CrookedWoodTex]

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

It’s going to take some intense logic analysis.

[KGN]

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

[CrookedWoodTex]

@KGN

Contrary to your post “anecdotes” are useful

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.

[saskia]

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

[saskia]

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

G38.2 followed by runaway jog problem

gSender 1.02; not exclusive to this version: Sometimes (perhaps 10% of the time) after using G38.2 in the console with the touch plate to locate an edge of a workpiece, the jog (using the GUI) away from the touch doesn’t stop and has to be aborted by pressing the Longmill controller button. *** Example log extract with +Y axis test *** feeder $J=G21G91 X5 F3000 ok feeder $J=G21G91 X5 F3000 ok client G38.2 Y225 F30 [PRB:121.835,-40.010,-44.730:1] ok feeder $J=G21G91 Y-1000 F3000 ok fe…

[benji]

I’m new to LongMill Mk2 ownership and very new to this forum. I’ve joined now just to comment on this post. I want to add my anecdote to help the dev team hunt down and resolve this bug.

I’ve been experiencing the same issue with my Mk2 running gSender 1.07 (and perhaps an earlier version of gSender) for a few months. For me, when the mill gets stuck in an infinite jog, it seems to be happening when I intend to single click any one of the axes (+/- XYZ). It might be that I am holding the single click a fraction of a second too long, but it honestly happens so quickly and sporadically that I can’t recall the nature of the mouse click. In any case, I think it is always from an intended single-move jog mouse click.

One other nugget. I’ve copied the console output below that captures the most recent accidental infinite jog event. It happened shortly after a job was completed, so I’ve included the console output from the end of the job. Note that the accidental long job event happens when a “client ok” is NOT reported.

[MSG:Pgm End] < End of job
ok
ok
client $J=G21G91 X-1000 F1000 < Moving the router to various places without issue
ok
client \x85
client $J=G21G91 Y-1000 F1000
ok
client \x85
client $J=G21G91 Z-1000 F800.000
ok
client \x85
feeder $J=G21G91 Z-0.1 F1000
ok
feeder $J=G21G91 Z-0.1 F1000
ok
client $J=G21G91 Z-1000 F800.000
ok
client \x85
client $J=G21G91 Z-1000 F800.000
ok
client \x85
client $J=G21G91 Z-1000 F800.000
ok
client \x85
feeder $J=G21G91 Z-0.1 F1000
ok
client $J=G21G91 Z-1000 F800.000
ok
client \x85
client $J=G21G91 Z1000 F800.000 < this triggered accidental infinite jog
client \x85
ok
feeder $J=G21G91 Z-0.1 F1000 < unsuccessfully tried to stop jog with Z- click
ok
feeder $J=G21G91 Z0.1 F1000 < unsuccessfully tried to stop jog with Z+ click
ok
client \x85 < successfully stopped jog with cancel movement button

[_Michael]

First off welcome to the forum Benji. I was just reading your post and noticed that the gSender version you are using is outdated. If I remember right, I don’t believe it will ask you to update from inside gSender for that version. Anyway you can get the latest version here.

Maybe the latest version will work better for you!

Again, welcome to the forum,
Michael

[Swinly]

I can’t believe I missed this thread. This sounds just like the issue I’ve had recently and in the past. It is nice knowing others have experienced it too