axis: fix Z jog after touch off on unhomed lathe (#3994)

[grandixximo]

Summary

Fixes #3994. Z axis stops jogging after touch off on an unhomed lathe with [TRAJ]NO_FORCE_HOMING = 1.

Cause

touch_off_system() calls set_motion_teleop(1) after the G10 L20 emit, putting motion in TELEOP. ja_from_rbutton() selected the compact "xzabcuvw" letter map whenever the machine was unhomed, which is correct for joint indices on a lathe (no Y joint) but wrong for teleop axis slots (fixed at 0=X, 1=Y, 2=Z, ...). After touch off the Z letter resolved to index 1, hitting the unused Y slot. X worked because index 0 matches in both maps.

Fix

Gate the compact map on jjogmode. Teleop axis jogs always use the full "xyzabcuvw" slot map; joint jogs keep the existing remap and trivkins/historical overrides.

Test plan

• Lathe sim, NO_FORCE_HOMING = 1, do not home
• Touch off X, jog Z+/- (was broken, now moves)
• Touch off Z, jog X+/-, Z+/- (both move)
• Home, touch off, jog all axes (regression check)
• Mill regression check (3-axis trivkins identity)

[grandixximo]

If this is good like this, will do also for 2.9 as #3994 also hits there

[BsAtHome]

Shouldn't the axis-->joint mapping be extracted from the INI-file set in [TRAJ]COORDINATES or the [KINS]KINEMATICS coordinates option? If neither is set, then a default can be used.

Or am I looking at this wrongly?

[grandixximo]

Two different lookups are involved:

Letter to joint index (joint jog): yes, INI-driven. Line 1960 already uses trajcoordinates.index(ja) for trivkins+identity, and the historical branch handles the legacy JOINTS=3 lathe layout.

Letter to teleop axis slot (teleop jog): not INI-driven. Slots 0..8 = XYZABCUVW are a hard-wired LinuxCNC convention. src/emc/motion/axis.c indexes a fixed axis_array[EMCMOT_MAX_AXIS] directly. [TRAJ]COORDINATES only controls which slots are populated, not which slot Z lives in. If a machine has no Y, slot 1 is unused but Z is still slot 2.

Other GUIs all hard-code the same "xyzabcuvw" slot map: gmoccapy.py:1257, qt_action.py:630, touchy/emc_interface.py:150, linuxcnc_util.py:159.

The bug was that "xzabcuvw" (a joint-side compact map) leaked into the teleop path via the unhomed gate. The fix scopes it to joint jog, so teleop falls back to the universal "xyzabcuvw" slot map. No INI semantics change.

[BsAtHome]

But, for example, a XXZZ machine has 4 joints (0=X, 1=X, 2=Z, 3=Z). How does that cope?

[grandixximo]

Duplicate coordinate letters are an existing concern, not new to this PR. The behavior is unchanged either way:

Teleop jog (letter to slot): still 9 fixed slots. "xyzabcuvw".index("z") = 2 returns the Z axis slot. Kinematics distributes the slot's commanded position to joints 2 and 3 (the two Z joints). One slot, two joints, kins handles it. Same on every GUI.

Joint jog by letter: line 1960 uses trajcoordinates.index(ja), which returns the first occurrence (the comment at 1958-1959 already calls this out). For XXZZ: letter X hits joint 0, letter Z hits joint 2. The second X and second Z are reachable via the numeric joint radiobuttons, which take the int(ja) path at line 1945 and bypass the letter map entirely.

Joint jog by letter, lathe unhomed, pre-fix: "xzabcuvw" gave Z=1 which was wrong for trivkins identity, but the trivkins+identity branch at 1957-1960 overrode it with trajcoordinates.index("z")=2. So the only path where the compact map actually reached motion was the non-trivkins-identity fallback (gantrykins etc), which is also where it was needed because those kins layouts are not letter-indexable.

The PR doesn't change any of that. It only stops the compact joint-side map from leaking into the teleop path after set_motion_teleop(1).

[BsAtHome]

Then this fix will confirm the status quo and be a narrow fix. I'm fine with that.

The double/multiple axis name issue will need to be addressed consistently at some stage in all the UIs. Put it on the list ;-)