Advanced Search

Thank you for testing. The output indicate that the program was working as expected. The firmware is not exactly the same as mine, but it looks similar. How big differences/similarities there are would require disassembly comparing those. I can see that at least memory addresses are a bit different. Here is the output from mine (not the real dongle, I put the factory firmware on another device which has bootloader version 2.40):The addresses and sizes are close to each other, but not exactly the same.

Because you have bootloader version 2.40, I believe we would be able to read out the firmware through the bootloader. But it requires creating a similar program for that as the one we just used. And to get to bootloader mode, a 10k resistor needs to be added to the pendant. So maybe better to wait until I have tested the new firmware a bit more. And then you could read out the firmware and flash the new one at the same time, if you are still interested at that point.

Here is what happens when I run the tool. My whb04b is from the era when they just stopped selling the predecessor.The output from the command is attached,

I had a feeling that it could be possible to read out the factory firmware from the dongle due to some bugs in the firmware. And that is indeed the case, at least for a partial readout. It is possible to read the firmware from where the USB device descriptor is stored in program memory until and including the bootloader. I added this tool to the github repository:
github.com/finngineering/whb04b/blob/mas...s/firmware_readout.c
While I think this tool should be safe to use, I give no guarantees. With a partial readout, I could compare that to my firmware, and if it matches, the likelihood that the whole firmware is the same is very high.

Actually, now that I've done this, I remember that there is a much easier way to read out the firmware from CH55x with bootloader version lower than 2.50 (which is the version that my dongle has). The above tool should print the bootloader version, and if it's less than 2.50, I could maybe make a tool to read out the firmware through the bootloader and over USB.

I don't think I would trust a USB device under these circumstances. I would recommend you go back to XHC's website and look for a 433 MHz pendant that hard wires in to send/receive unit. After years  of use, these have never let me down 

Do you have a link to the one you use or a model number?

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.

Finngineering wrote:

... I prefer to call the USB part the dongle and the actual handheld device the pendant.

That is the usual naming since the dawn of "security dongles" started by software companies to prevent copying software and later adopted by some banks, and naming them something else... forgot what exactly, but dongle prevailed.

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.

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.

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.

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.

Hi,

The forum was unavailable all weekend.
I checked your configuration.
You are using my config and have deleted the modules in master idx="1" in the XML.
Accordingly, you must also delete the corresponding links in the hal.
These are all links in the “# Switches” section.
If you don't have a handwheel, you can remove this:
loadusr -W xhc-whb04b-6 -HsfB and all MDI_COMMAND in the .ini

However, the error ./cia402-example.hal:63: parameter or pin ‘joint.0.request-cia-homing’ not found 
is strange. The corresponding pins are present.
Can you upload the complete error log next time?
PS: setp iocontrol.0.emc-enable-in 1 System without emergency stop?
Very dangerous.
 

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?

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.

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.

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.