XHC WHB04B development?

I have not been following this but if the system fails with a program running, there is a fault with the driver logic. Jogging should not be permitted unless the machine is in teleop mode and programs are not permitted to run in teleop mode.

The driver could request teleop mode with halui.mode.teleop and this will prevent a program from running. I did this with a hard wired pendant. Gmocappy is a good gui to demonstrate this because setting teleop mode makes it display the jog buttons.

The current component tries to change to manual/teleop mode even with a program running/paused. The changes made by Hannes prevents that. However, if a program is not running/paused and you start jogging, it will change to manual/teleop mode automatically. It could of course be discussed if the pendant should be "allowed" to do this just by jogging the wheel. But the PR by Hannes is really mainly bugfixes, so I would presume that it's best not to alter the behavior of the pendant more than necessary.

In my case I had a deadman's switch that had to be held down to enable the jog wheel on the pendant so I set teleop mode when that button was pressed.  I don't think you should allow just jogging the wheel to change modes. There are some safety rules around this stuff. And yes having to switch modes to jog on screen or a pendant is frustrating but probably for safety.

You are right, rodw, and I don't particularly like it. But that's how it is.
That part can be taken out, for sure.

Some news. I think it is now narrowed down to debian 12 and probably gcc 12.2
Hannes, your question on trixie, I thought I was on trixie on my development pc, no I was on 12.13.
And suspicion about va_args.
So I upgraded to trixie and gcc 14.2.0.
Recompiled, and now it doesn't segv anymore.
It continues after a short break, like it should.
The problem is in libusb1.0 when compiled with gcc 12 (if I understand right).
 

rodw: I tend to agree that jogging should not be possible by accident. However, I would personally keep that kind of behavior change separate from the bugfixes in the PR. I just fear that changing behavior makes the PR more likely to be not be accepted. But I don't really know, and it's Hannes' PR after all.

Hakan: Great if you got rid of that libusb issue. Then unless somebody else experience the same issue, I think not much need to dig deeper.

That WHB component is somewhat a rabbit hole... I tried to do proper error handling, can you test it?
github.com/hdiethelm/linuxcnc-fork/tree/...fix-v2-errorhandling
The proper way of testing would be:
1. Get this version to fail reliably: github.com/hdiethelm/linuxcnc-fork/tree/xhc-whb04b-6-fix-v2
2. Now test this version: github.com/hdiethelm/linuxcnc-fork/tree/...fix-v2-errorhandling
Otherwise, you can never be sure the change made any difference. I now that is often not that easy.

Looking at the code, just removing the assert() probably can result in segfaults in libusb as long as the error is not handled properly.

Note that even with my changes, it is not really how you would do it in a nice way but it should work I think. I am not able to reproduce your issue, so I can just guess and try to do better error handling.

@rodw: Jogging in manual mode is fine. My machine can not jog in teleop mode due to I have two Y axis servo motors. The only thing the WHB component does after my PR is:
- Change to teleop mode if not homed (which fails on my machine but on others, it will do that) -> You can jog before homing any special action
- Change to manual mode if homed AND program is idle -> You can jog after homing without any special action