XHC WHB04B development?

If the interrupt endpoint is not continuously polled, you get the disconnects. But also the xhc-whb04b-6 component keeps it from disconnecting, at least in most situations. You can run that directly from the terminal, for instance with "xhc-whb04b-6 -a" to enable all logging, and you will see that the pendant will not disconnect.

So in this "easy" situation, there is not much difference between the three programs. We know that the pendant disconnects in a long-time stress test with the xhc-whb04b-6 component and LinuxCNC running. I'm not sure either of the other programs would do any better in similar situations.

Interesting, a lot of output there.
I was just about the write that it must be the connection to linuxcnc, hal that's the problem.
Then I noticed that it disconnects when I turn the wheel. Almost always, when idle.
You have that too?

Please specify what you mean by idle. Is this with LinuxCNC running or one of the other programs polling the pendant?

I left the pendant connected last night directly to the xhc-whb04b-6 component, and now some 15 hours later there still hasn't been a single disconnect.

Hello

I'm pretty new in LinuxCNC, this is my first post... However, at my day job, I do a lot of C++ coding and bug fixing.

I had some issues with the WHB04B so I just fixed them and created a PR:
github.com/LinuxCNC/linuxcnc/pull/3810
Feel free to test. For everyone only wanting these changes, I also create a back-port branch containing also the axis fixes:
github.com/hdiethelm/linuxcnc-fork/tree/...x-v2_backport-v2.9.8

I just discovered this thread right now. Sadly, I can not test your disconnect issues, i have the wired version where reconnecting USB seams to work.

Does the speed and feed display work at your devices? I just always see F:0 and S:0 even thought the values are sent according to my debugging. But might me I am doing something wrong.

Welcome Hannes and thank you from my side for your contributions. I am fairly new here myself, and have made no "real" contributions to LinuxCNC so far.

If you read through this thread, you saw we discussed a "loops" variable. The changes you made to hal.cc should be another way of fixing that specific issue. As for the other changes, I haven't really used any of those features. And to be honest, I'm a bit confused about the modes (auto, MDI, manual, teleop, joint).


In other news, I have been slowly chipping away at making a new firmware for the dongle. As of right now, I have something that is mostly working. I will release the source code once I have it in a little bit better shape. But I don't think it will be of use to most people, as flashing a new firmware is likely a one way street, and may make the pendant unusable.

If you or somebody else wants to update the xhc-whb04b-6 component (more), there is some low hanging fruit:
The libusb_fill_bulk_transfer in:
github.com/LinuxCNC/linuxcnc/blob/master...whb04b-6/usb.cc#L457
should really be a libusb_fill_interrupt_transfer. Endpoint 1 is an interrupt endpoint after all. The dongle/pendant doesn't know the difference between bulk and interrupt, but for scheduling of traffic on the USB bus, there are some differences. It's not inconceivable that some of the disconnects could be from USB congestion and wrong transfer type, but I do think it's unlikely.

Another thing is the checksum calculation. The full formula is: In the XHC implementation, the seed is the day of month [1...31] and "random" is from a timer in the microcontroller.

Please specify what you mean by idle. Is this with LinuxCNC running or one of the other programs polling the pendant?

I saw the effect with no polling program. Didn't see it with one of the pollers active.
Idea was that sitting idle for some time made turning the wheel trigger something that disconnects it.
Didn't find that was the case though.

Hi Hannes, my unit displays the F: and S:, pressing Feed+ makes it display F:105 F:110 and so on. S: also show some values that change with press of S+ and S-. Seems to work.

Switched to libusb_fill_interrupt_transfer. I have a milling session today so I can at least tell if it still crashes.

I guess one can take out the original and solder in a new STM32G030C8T6? They are almost free.
What role does the dongle have? Is it passive or does it too have firmware?