Unify the way jogging works from HAL, and its interaction with the UI

[rene-dev]

While digging into PR #4613 I discovered what a mess this currently is.
here is what we have now:

Motion

motion has pins for MPG and external offsets for axis, and MPG inputs for joints:
https://linuxcnc.org/docs/html/man/man9/motion.9.html

halui

halui also has mpg inputs for joints and axis, as well as increment/decrement pins, and a single inputs that can be muxed to any one joint/axis.
https://linuxcnc.org/docs/html/man/man1/halui.1.html

Axis

axis outputs the selected axis to hal, meant to be connected to motions jog-enable pin:
https://linuxcnc.org/docs/html/gui/axis.html#sec:axis-axisui-pins

gmoccapy

gmoccapy has increment/decrement pins, and an MPG input:
https://linuxcnc.org/docs/html/gui/gmoccapy.html#_jog_hal_pins

What do the UI pins provide, that motion doesn't offer?
Why do we need a hal jogging interface in every single layer?

having only one interface would clean up the code a lot, and make it much easier to switch UIs.

[c-morley]

Motion has MPG jogging because realtime was needed for precise counts?
All the GUIs have pins of there own to try to interface better with HALUI or to replicate HALUI behavior, while using it's internal idea of selected axis and jograte, or to add some feature: ie hi/low jograte. Users often use a combination of HALUI and GUI pins.
GUI MPG input is for using the MPG in the GUI for say scrolling (not for jogging)
The pins might also interact with keyboard jogging, like the hi/low jog speed pin.

[c-morley]

Some on these pin difference also come from UI paradigm choices.
AXES uses selectable radio buttons for axes selection, which works well with HALUI axis selction.
GMoccapy does not have a selected axis concept in the UI, it has individual jog buttons.

[grandixximo]

One more layer to keep in mind: the multiaxis work in #4374 adds jog frames (jog along the machine axes, the tilted work plane, or the tool). I put the frame selection in motion (EMCMOT_SET_JOG_FRAME, motion.jog-frame out), so every jog source follows it the same way: keyboard and GUI jogs, halui, and the motion MPG inputs (axis.N.jog-counts). halui only adds halui.jog-frame.machine|plane|tool selection pins and .is-* status, and AXIS a View menu entry.

If the jogging interface gets unified, I would keep that split: motion owns the jog state, including the frame, and the upper layers only select. Happy to adjust the pin names in the stack to whatever this discussion settles on.

[rene-dev]

Motion has MPG jogging because realtime was needed for precise counts?

no. it doesn't count, it just adds 2 numbers.

All the GUIs have pins of there own to try to interface better with HALUI or to replicate HALUI behavior, while using it's internal idea of selected axis and jograte, or to add some feature: ie hi/low jograte. Users often use a combination of HALUI and GUI pins.

Why does the UI need to interface with halui?
I get that it makes sense to use the selected axis/jog rate from the UI from hal pins, and that is why I created a branch that moves this to task, so halui and the UI share this number. But Im not sure this is the right approach, they could also share them via a hal pin.

GUI MPG input is for using the MPG in the GUI for say scrolling (not for jogging)

this can be done entirely in hal and the UI by using a mux, and whatever hal pins the UI provides. Does not interfer with halui/task/motion at all.

The pins might also interact with keyboard jogging, like the hi/low jog speed pin.

what do you mean with interact? of course the last one always wins.
the turtle jog is a good question. Im not sure how to solve that.

What I would like to have

• one jogging interface, that is always there, and always works. independent of the UI, even if you have no UI at all.
• MPG interface for each axis
• muxed MPG, where you select an axis to jog. could be done in hal, but convenient to be buildin.
• jog + and - buttons
• something to select increments
• velocity input, for joysticks

Open questions

• does it live in task, or motion (please not both, definitely not in the UI)?
• do we reuse some of the pin names, or do we break everything, and make new pin names?
• how to handle slected axis, jog speed, and turtle jog
• should the muxed MPG share the state with UIs that have a selected axis?
• should jog + and - input pins share increment and speed with the UI?
• which other state needs to be shared with the UI?
• maybe a hardware-jog-inhibit pin?
• how should joints be handled? seperate pins? dependent on mode?
• mpg/joystick mode by changing pos/vel mode for jogging?
• how should the jog plane be handled(@grandixximo s branch.)? can it be switched while paused? should there be hal pins at all for this?

[zz912]

Question:

• do we reuse some of the pin names, or do we break everything, and make new pin names?

IMHO: I have no problems with new pin names. Better than 2 HAL pins with similar function.

[zz912]

I would like to have:

• muxed MPG, where you select an axis to jog. could be done in hal, but convenient to be buildin.

Regarding the muxed MPG, it’s worth keeping in mind that some lathes have two separate rotary handwheels, one for the Z axis and one for the X axis. The design should account for this setup as well.

[rene-dev]

yes, just like there is now, each axis also has one dedicated wheel. the common one would also be used when jogging in a jog frame.

[rene-dev]

Ah, no. The frame has multiple axis. So all of them would map to the jog frame.