Option to adjust length of jog commands sent when clicking and holding

[lllars]

Feature request

Add a configuration option to change the length of jog commands sent when clicking and holding on the jog buttons.

I think the move length might be currently hardcoded to 1/500th of the feed rate? I like the idea of it being a ratio of the feed rate, but it would be nice to be able to change the ratio. The 1/500 ratio seems to be too high for my machine, resulting in move lengths that are too short. This causes my machine to start and stop a few times before moving continuously.

Specifications

Version

UGS Platform 2.0 - Nightly Build Apr 25, 2020

Operating system

Arch Linux

Platform

g2core -- edge-preview branch

[breiler]

Thank you for a good post!

The code for determine the jog step length is defined here:
https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-core/src/com/willwinder/universalgcodesender/utils/ContinuousJogWorker.java#L109

The best way I found was this formula:
(maxFeedRate / 60.0) * (JOG_COMMAND_INTERVAL / 1000.0) * 1.2;

The max feed rate in seconds multiplied with the interval to send jog commands in seconds and add 20% to compensate for latency etc.

I figured that this would generate enough job to keep the controller planner buffer busy.

Another way is to check the controller planner buffer size and send commands until its filled with enough commands. But this requires a bit more work...

We could experiment with the 20%, making it customizable instead.

[lllars]

Ok, thanks for showing me where the relevant part of the code is. I have been testing out some changes.

The first thing I tried was to sneak in an extra move right at the beginning of the sequence (with no delay afterwards), and then continue as normal. The idea being to load up the queue a bit so it doesn't run dry.

    private void sendContinuousJogCommands() {
        try {
            isRunning = true;
            final double stepSize = calculateStepSize();
            
            // I only added this line:
            jogService.adjustManualLocation(1.0 * x * stepSize, 1.0 * y * stepSize, 1.0 * z * stepSize);
            
            while (isRunning) {
                // Ensure that we only send one command at the time, waiting for it to complete
                if (!isWaitingForCommandComplete) {
                    isWaitingForCommandComplete = true;
                    jogService.adjustManualLocation(x * stepSize, y * stepSize, z * stepSize);
                } else {
                    Thread.sleep(JOG_COMMAND_INTERVAL);
                }
            }

            waitForCommandToComplete();
        } catch...

That worked OK. Definitely better. I would get a nice smooth jog about half the time. The other half of the time, it would start and stop once before smoothly jogging. Next I tried making that first move bigger, changing the 1.0 multiplier to 2.0 or 5.0. That did not help, the behavior was about the same, except that the initial stutter was longer (obviously). I did also notice an occasional stutter after stopping the move when the multiplier was 5.0

Another thing I noticed while running this test was that G1 commands were sometimes being sent much faster than every 100ms. A short (~1sec) click might result in ~5 G1 commands or ~20, seemingly at random. I suspect this is a bug that is independent of my modifications.

The second thing I tried was to just send one big command, and then no more.

    private void sendContinuousJogCommands() {
        try {
            isRunning = true;
            final double stepSize = calculateStepSize();
            
            //try one big move
            isWaitingForCommandComplete = true;
            jogService.adjustManualLocation(50.0 * x * stepSize, 50.0 * y * stepSize, 50.0 * z * stepSize);
            while (isRunning) {
				Thread.sleep(JOG_COMMAND_INTERVAL);
			}

            waitForCommandToComplete();
        } catch...

That worked really well. Smooth jogs every time. Of course it does have some major issues, like it stops at the end of 50 * stepSize even if you are still holding down the button. It also triggers soft limits if you are anywhere near them.

So, here is what I would propose: We implement the one big move strategy. If soft limits are enabled, we calculate how far away they are and set the move size just shy of that distance. If soft limits are not enabled, we could still use the same calculation, but that might frustrate users trying to jog their machine before it is homed. So in that case we could set the move size equal to the full range of the axis (like Xmax - Xmin).

What do you think? Does UGS have the info it would need to calculate the move size (soft limit enable and axis limits)? Is there too much risk of crashing machines if a feedhold fails to send or something else goes wrong?

[breiler]

Sorry for my delayed response.

I don't think larger step sizes would work that great when using controls such as gamepads. If I hold an analog control and change the direction slightly It would try to move the complete distance (50 in whatever units) before changing the direction.

As a short term solution we could make the step size customizable, the user could choose to set it to 50.0 if they would like. We could even try to check the soft limits, even though I think this will become messy. My head still hurts for when trying to implement the soft limits in the visualizer. And I'm not sure how this is handled between controllers... =(
I remember trying to take this path before but there could have been other problems at that moment.

According to this we should do everything right except for checking the planner buffer (I think it's the same behaviour on g2core): https://github.com/gnea/grbl/wiki/Grbl-v1.1-Jogging#joystick-implementation
I'm a bit more interested in giving that a try.

[lllars]

Understood. In the meantime, I've come up with a couple other things to try here. I will update when I have some more results. I'm also thinking the best solution would really be to have native jogging commands built in to the controllers. It doesn't sound like GRBL will do that, but maybe it could be done in g2: synthetos/g2#473

[mojorisin1967]

Good day gentlemen,

I've been trying to troubleshoot a problem with jogging. I'm using DM542T drivers with NEMA23 motors. Everything seems to work flawlessly except jogging in .001" (or < approximately .005" actually). What i suspect is happening is that steps are lost during wakeup time. The problem is gone if i leave motor current on all the time. I was hoping to find a way of delaying slightly the step/dir pulses after the enable signal. Any thoughts?

I appreciate any help. Thanks!

[breiler]

@mojorisin1967 this can not be done from UGS and needs to be done in the controller firmware.
If you are using GRBL there is a paragraph about missing steps when using the idle delay:

https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration#1---step-idle-delay-milliseconds
Also, keep in mind that some stepper drivers don't remember which micro step they stopped on, so when you re-enable, you may witness some 'lost' steps due to this. In this case, just keep your steppers enabled via $1=255.