JOG Hotkey problem.

[CzRobotics]

Version

2.1.5

Hardware / Firmware

GRBL 1.1

What happened

There was a problem that occurred after upgrading to a higher version. In version 2.0.11 everything worked correctly,

It's about controlling the JOG using the Classic PC keyboard and the external programmable USB keyboard...

Unfortunately, in version 2.1.3, pressing CTRL + RIGHT at the same time causes the machine to go right uncontrollably and cannot be stopped. With version 2.1.5 it is similar, It also starts smoothly, but the machine can be stopped by pressing any key.

I find that the problem occurs if the Control + RIGHT keys are pressed at the same time (this is true for all other directions as well) If I press the Control key a small amount of time before pressing the RIGHT key, the machine will move correctly for a set distance (10, 1, 0.1 mm) and stop.

I also noticed that if (in version 2.1.5) Control + RIGHT are pressed at the same time, the UGS starts sending an infinite series of $J=G21G91X0.25F1500 commands until any key is pressed... This command is sent for any value of Step size... Whereas if I press the Control key and the RIGHT key with some delay the code $J=G21G91X1F1500 is correctly sent only once ...

The problem is that when I use the programmable keyboard (where I have defined other frequently used functions) I can't set the delay between pressing Control and RIGHT and so these functions are unusable...

I have simultaneously installed the versions I tested on
2.0.11 - everything works as it should
2.1.3 - When pressed at the same time it starts uncontrollably and cannot be stopped
2.1.5 - When pressed simultaneously the machine starts but can be stopped with any key...

How to reproduce

No response

Operating System

No response

Anything else

No response

[breiler]

I can not reproduce this on Windows 11 or on Ubuntu Linux using UGS 2.1.5.

Do you have other keybindings bound (search in shortcuts)?

Since you didn't specifiy which operating system I will make a guess that you are running Windows.
Can you paste the contents from the file (open in notepad):
C:\Users\[username]\AppData\Roaming\ugsplatform\config\Keymaps\NetBeans\D-RIGHT.shadow

[CzRobotics]

contents from the file D-Right.shadow

nbfs://nbhost/SystemFileSystem/Actions/Machine/com.willwinder.ugs.nbp.core.services.JogActionService.xPlus.instance

[CzRobotics]

I'm running Windows 10 Pro, ver. 22H2

If I press the CTRL key in advance and then the RIGHT key (or left, up, down) everything works correctly.

The problem occurs if I press CTRL + RIGHT (or left, up, down) at the same time. Then the UGS Platform starts sending an endless series of instructions $J=G21G91X0.25F1500 even if the step size is set to 1 mm

Take a look at the screenshot

[breiler]

No matter how I try I can't reproduce this on 2.1.5 on Windows or Linux.

There was an old similar issue that got fixed in 2.1.4: #2390

What type of keyboard are you using, do you have another to test with?

[CzRobotics]

And I've tried a total of three types of keyboards

The first type, which I use just for positioning and zero-pointing, is a programmable keyboard of this type:
https://www.amazon.com/dp/B0BBS3D3JV/ref=sbl_dpx_pc-accessories-keyboards_B09CGZJGSH_0?th=1
With this keyboard the problem manifested itself when switching from version 2.0.11 (everything worked 100%) to version 2.1.13 and higher (the error manifests itself every time) .

I also use a Logitech USB keyboard... For that one, the problem manifests itself If I press the cursor arrow along with the controls key at the same time, similar to a pianist playing a chord. Interestingly, there is a small pause of an estimated half a second between this press and the start of sustained movement of the machine (caused by repeatedly sending the above G code command to the machine). To correctly trigger this error, it is necessary to try individual test double-strikes at least one second apart.

Next, I tried on a different type of Logitech wireless keyboard. This keyboard also had the problem, but was much harder to recall. I attribute this to the fact that wireless communication may be responsible for the time lag between the Control key and cursor arrow information being sent.

From the above, I think the problem arises with a short time delay (I'm talking tens of milliseconds) between the Control key press and the corresponding cursor arrow. Version 2.0.11 worked perfectly reliably for a long time with the same hardware and settings as the current version...

[CzRobotics]

https://photos.app.goo.gl/bFWmTJQ7L1VyztQS9

[breiler]

Thanks for the video, I'll do some more experimenting.

With this keyboard the problem manifested itself when switching from version 2.0.11 (everything worked 100%) to version 2.1.13 and higher (the error manifests itself every time) .

In 2.0.11 we were using the key repeat interval to send new jog commands in UGS. This would lead to choppy movement and even hangs since we would fill the controllers command buffer. As of version 2.0.15 we are using a continous jog worker that listens to a key-press and key-release events instead. Somehow this long press is triggered but not released for you.

Interestingly, there is a small pause of an estimated half a second between this press and the start of sustained movement of the machine (caused by repeatedly sending the above G code command to the machine).

Yes that is the wait interval (500ms) used for detecting a "long press" and activate continous jogging. It should however only be triggered if the buttons are pressed for that interval:
https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-platform/ugs-platform-ugscore/src/main/java/com/willwinder/ugs/nbp/core/services/ContinuousActionShortcutListener.java#L63

[CzRobotics]

The continuous jog worker is definitely a very great idea :-) it improves the quality and utility of the software and will surely be appreciated by users.

But so far it is triggered not only if the interval is more than half a second, but also if the interval between the Control keys and the cursor arrow keys is too short As you can see in the video... I also tried using another key combination Ctrl + Shft + F12, and the result was still the same.

I'd like to go back to using a programmable keyboard with only function keys, because I can comfortably put this one on the machine's workbench, follow the spindle with my eyes, and run to the material in small increments. Unfortunately this keyboard always sends out a key combination (Ctrl + whatever ) in close succession and the UGS responds by triggering the Continuous jog worker function.

[breiler]

I was finally able to reproduce the problem which is the first step to fixing it. I've been diving into the code and I might found what is causing this. It was really hard to reproduce this on my machine which only occurs on about 1 of 10 tries, but it is reproducable on both Windows and Linux.

Thanks for the patience describing the problem.

[breiler]

Sorry it got auto closed when I merged the code changes. Please try the latest nightly build:
https://github.com/winder/Universal-G-Code-Sender?tab=readme-ov-file#downloads

I had a hard time reproducing it before, but after this fix I can no longer reproduce it.

[CzRobotics]

Thank you very much for your work :-) I will test this one this weekend, I will give you feedback on the results...

[breiler]

Closing as we did not get any replies from user.