whb.axis.X.jog-counts increments but axis does not move (Teleop mode, LinuxCNC 2.9.10)

[rimoneeng-creator]

LinuxCNC version: 2.9.10 (built from 2.9 branch)
Component: xhc-whb04b-6 HAL component
Hardware: Mesa 7i92 (hm2_eth), pendant is a Centroid WMPG-6 (XHC-WHB04B-6 hardware clone, VID/PID 10ce:eb91 — patched locally to match, unrelated to the core issue below)

Summary

Using the built-in xhc-whb04b-6 HAL component with a WHB04B-6-family pendant:
buttons, axis-select rotary, and the feed/step rotary all work correctly and are
verified via xhc-whb04b-6 -ue debug output. The wheel itself is also confirmed
working: pndnt wheel total counts increments/decrements correctly when turning
the dial with an axis selected.

All prerequisite HAL pins are confirmed correct via halcmd show pin/sig:

• machine-is-on = TRUE
• axis-select-x = TRUE (correct axis selected)
• pdnt.axis.x.jog-enable = TRUE
• pdnt.axis.x.jog-scale = 0.1 (correct, non-zero)
• pdnt.mode.is-teleop = TRUE (all joints homed, teleop mode confirmed active and stable)

However, axis.x.jog-counts (and whb.axis.x.jog-counts) remain at 0 when
sampled via halcmd, and axis.x.pos-cmd never changes when turning the wheel.
No motion occurs, even though every prerequisite condition documented in the
component's man page is satisfied.

Steps to reproduce

1. Build LinuxCNC 2.9 branch from source, load xhc-whb04b-6 via
   loadusr -W xhc-whb04b-6 -HBue (interactive/debug flags for observation)
2. Wire whb.axis.X.jog-* to axis.X.jog-* and halui.axis.X.select per
   example-configuration.md
3. Home all joints, confirm Teleop mode is active (halui.mode.is-teleop = TRUE)
4. Select an axis on the pendant, turn the jog wheel
5. Observe: pndnt wheel total counts increments in the terminal debug output,
   but halcmd show sig | grep axis.x.jog-counts always reads 0, and
   axis.x.pos-cmd never changes

What I've already checked/ruled out

• Not a mode-request timeout issue: I increased ModeRequest.modeCheckLoops/
  modeCheckLoopTimeoutMs in hal.h (Profiles::halRequestSlowProfile) from
  60×5ms to 600×10ms — mode.is-teleop stays stable TRUE across repeated
  checks, but jog still does not move the axis.
• Not mIsLeadModeFeed/mIsLeadModeSpindle gating — the dispatchFeedValueToHal
  code path that calls setJogCounts() only depends on feedButton.stepMode()
  being STEP or CON, which is confirmed true.
• Not homing — all joints are homed and Teleop is confirmed active.
• Similar reports found on the forum with genuine (non-clone) XHC-WHB04B-6
  hardware and different Mesa cards (7i92, 7i96s), suggesting this may not be
  hardware-specific:
  https://forum.linuxcnc.org/9-installing-linuxcnc/50661-xhc-whb04b-6-and-linuxcnc-2-9-1
  https://forum.linuxcnc.org/38-general-linuxcnc-questions/35913-xhc-whb04b-6-linuxcnc-not-working

Question

Is there a known additional condition (beyond jog-enable, jog-scale, teleop mode,
and homing) required for setJogCounts()'s output to actually reach motion?
Happy to provide full .hal files, halcmd show sig/pin dumps, or test patches
if that would help narrow this down.

Thanks

[rimoneeng-creator]

Update — root cause found, fix confirmed working.

Found it. The debug output printed stepMode=0x02, which I had
assumed meant CON (Continuous), but checking the actual enum in
pendant-types.h:

enum class Mode : uint8_t { CON = 0, STEP = 1, MPG = 2 };

0x02 is actually MPG mode — the pendant's default/idle mode
whenever the physical mode-switch button combo (Fn + macro-15/16)
has never been pressed (many WHB04B-6 clones, e.g. rebranded units,
don't wire that combo to any physical button at all).

The bug: Pendant::onJogDialEvent() only calls setJogCounts() when
stepMode() == CON || STEP:

else if (!counters.isLeadCounterActive() &&
         (feedButton.stepMode() == HandwheelStepmodes::Mode::CON ||
          feedButton.stepMode() == HandwheelStepmodes::Mode::STEP))
{ mHal.setJogCounts(counters); }

MPG mode is never included, so setJogCounts() is simply never
called while the pendant reports MPG — which is the out-of-the-box
state for any unit that can't reach the mode-switch combo. This
explains every prior report in this thread of "wheel events increment
in the terminal but jog-counts pin stays 0" with genuine XHC hardware
too, not just clones.

Confirmed fix (tested, jog now moves the machine correctly):

else if (!counters.isLeadCounterActive() && (true))
{ mHal.setJogCounts(counters); }

(i.e. call setJogCounts() unconditionally — Lead/spindle-override and
feed-override modes are already handled in the branches above this one,
so this is safe.)

Separately found and fixed a second, related bug: even after forcing
STEP behaviour in dispatchFeedValueToHal(), feedButton.stepSize()
still resolved through the CON (percentage) map internally, so the
jog-scale pin received values like 10 instead of 0.1mm. Fixed by
mapping directly from the raw key code instead of relying on
stepSize():

switch (feedButton.keyCode().code)
{
    case 0x0d: axisJogStepSize = 0.001; break;
    case 0x0e: axisJogStepSize = 0.01;  break;
    case 0x0f: axisJogStepSize = 0.1;   break;
    case 0x10: axisJogStepSize = 1.0;   break;
    default:   axisJogStepSize = feedButton.stepSize(); break;
}

Happy to open a PR with both fixes if that's useful — let me know if
there's a preferred approach (e.g. whether MPG should be treated
identically to STEP, or given its own explicit branch).

[grandixximo]

I think these pendant have internal firmware versioning, which might be operating differently, I doubt the driver never worked, it probably worked with some old version of the firmware, and we can't change behavior for those on stable release, would it be possible for the changes to be in conditionals that sense your particular version of the pendant? I'd feel more confident in merging something that changes behavior once it checks that the version of the thing is communicating to is the correct one. I think it returns a string with a number in the lsusb, not sure if it has a firmware version address you can compare...