Alternate UI for Jog control

[rschell]

I have been playing with a alternate method of controlling the jog step size and I am wishing the gauge the interest/feedback whether to submit a PR. The current UI requires at least two mouse clicks and mouse movement to select a new step size ( I tend not to use a keyboard for this). For reference is my unmodified bCNC panel:

Below are two screen shots using my alternate UI based on two slider controls:

I like this version better since all I have to do to change the jog step size is drag the slider control to its new value and its ready to go. The select-able values come from the steplist in the config file. To keep the control compact, the control uses a logarithmic scale. if one wants more steps in the slider, its a simple edit of the config file. One possible change could be to make the slider label, an editable input field.

I have not implemented any keyboard bindings or locking mechanization between the two sliders but would certainly possible. Right now the UI is select-able via a boolean variable flag control frame but that too could be stored in the config file. Not sure how easy switching between the two UIs during the same session would be.

Thoughts/interest?

[Harvie]

I've already crashed my machine just by looking at your screenshots :-D

To be honest, i think that we actualy need proper GRBL jogging implementation. The joystick one that jogs continuously at specified speed until you release the button. (Currently it jogs based on step size rather than speed/joystick)

[rschell]

If there are no performance issues with python, I could see a entry in the steplist that would convert the direction controls to a continuous jog motion. Just concerned about the lag between a button release and the motion stopping.

[Harvie]

Just concerned about the lag between a button release and the motion stopping.

That would be improved. Currently when you release the keyboard, the GRBL has to finish the step. And when the step is too long, you might crash. Also keypresses are treated as "letters" now, so they repeat and multiple "letters" can be in buffer, so it does not stop sending steps after release.

New GRBL API allows for realtime control of jogging to stop immediately upon release. But we have to slightly modify keyboard handling in bCNC to get just press/release events rather than autorepeating.

[rschell]

My preliminary testing suggests that binding keystrokes to a continuous jog is going to be problematic due to keystroke repeats of the hardware.system software. I haven't been able to get those keystroke repeats to work yet, I have tried several "internet solutions" with varying degrees of success (some don't work on my hardware to what would be a jerky continuous jog).

Using a mouse button, however, I have had good results and will continue to pursue how to integrate the feature with supporting and non-supporting controllers.

[rschell]

Making a fair amount of progress. Currently, the jog limit is the remaining distance (less 0.1 mm) to the axis soft limit, so if the machine is at 30mm on a 100mm axis, a continuous jog will be permitted to 99.9mm or 0.1mm (using machine coordinates). The Z axis down limit is the current WPos position, so all continuous jogging should be relatively safe. The continuous jog rate is used for all three axis with the upper Bound on the jog rate slider being the highest maximum feed rate for the machine.

No keyboard binding at this point, but mouse button works well on my Raspberry Pi 4 with no lag issues. One issue I'm still working on is since the remaining distance is different for the x and Y axis, the travel for the diagonal jog buttons is not at 45 degrees but is relative to the distance to reach the longer axis. Could shorten the longer distance to maintain 45 degree diagonal. edit Changed the jog distance so that the diagonal jogs are at 45 degrees. Which would be what the user likely expects.

[rschell]

See revised PR #1749

[Harvie]

#1749 looks better, i'll take a look. in the meantime am closing this.