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.
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
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.
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.
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
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
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!
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
I am still having this problem. Happened again yesterday on the Z axis. I clicked the Z jog a couple of times so I could move the router out of the way to see the carve and it kept going up. I am using version 1.2.2