XHC WHB04B development?

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?

I flashed back the factory firmware to the dongle for some tests. With no program polling the pendant, pushing buttons and rotating knobs makes the dongle disconnect faster than if left alone. Somewhat surprisingly, turning the jog wheel makes the dongle reconnect faster than if left alone. So if you continuously spin the wheel, the disconnect/reconnect cycle will be much faster. I have not tried to check why, nor do I think it matters much in the end.

Also my pendant shows the F: and S: properly, so maybe it's something with the wired version. For debugging, I think the second best to a hardware USB analyser is Wireshark. It's pretty easy to monitor the USB requests/replies, and I can help with "setup" if needed. URB_INTERRUPT in is the data from the pendant and SET_REPORT is the data to the pendant (split up into 3 parts).

Yes, the STM32G030C8T6 could be replaced. Or reprogrammed in place, because that is not protected. But without the factory firmware, it's more difficult to figure out how to drive the display and the RF module. Although now that I have the dongle firmware somewhat working, the RF part for the pendant is probably pretty much the same.

The dongle mostly translates between USB on one side and 433MHz RF on the other. The microcontroller (at least in my dongle) is a CH554 and the RF module is a HW3000.

Here is the dongle firmware I am developing:
github.com/finngineering/whb04b

I would say it is mostly working. However, there are some things I would still like to improve. And for sure it needs some more long-term testing. But I do think this has the potential to be better than the factory firmware in almost every way.

Dongle is the thing we put in the usb port, right? 
What do I need to test?

You are miles ahead with knowledge about this device. I'll help were I can, like testing.

Yes, unless somebody have better terms, I prefer to call the USB part the dongle and the actual handheld device the pendant. In case of the wired version, I would presume all logic is in the pendant and the "USB part" is only a connector.

The problem for everybody else than myself is that you might have different hardware/firmware version. And if you overwrite the factory firmware with this new firmware, you can no longer go back, because you don't have the factory firmware. I could give you the factory firmware that was in my dongle, but it could be different than what is in yours. The firmware can be extracted (like I have done), but its tedious.

Anyway, I think its a little bit early for public beta testing. I will make some improvements and see if it appears stable over time. Maybe there could be some way to do at least a partial readout/verification of the factory firmware through USB.

Had a milling session, not very long. XHC didn't crash. Doesn't say much, so I'll continue using libusb_fill_interrupt_transfer().

Ok no testing. Interesting to see how it goes, and if the firmware in the dongle is to blame.