Advanced Search

I have added a bit more logging to the component..
The component is attempting to connect, it says, but I wonder if it actually tries and why that doesn't work.

Okay. I did not really think that libusb_fill_interrupt_transfer() would solve the issue. But that IS the correct function to use in any case.

If the disconnect happens only at mode switches, I'm pretty sure it can be solved simply by modifying the xhc-whb04b-6 component. Maybe we need to add some more (temporary) logging to the component to pinpoint the issue.

It appears our dongle firmware is different by one version increment. But of course the hardware side is the important one for compatibility. I would think that there is a good chance that the hardware is compatible or the same.

The sticker on my pendant 
 

Had two crashes yesterday. Mode switching. libusb_fill_interrupt_transfer() isn't the solution.
 
I had commented out the assert() in setupAsyncTransfer and let it continue
Failed here github.com/LinuxCNC/linuxcnc/blob/0673e3...whb04b-6/usb.cc#L541





 

I used the mill for a couple of hours today with my firmware in the pendant. I tried my best to cause some issues, but no disconnects from the dongle nor any other issues as far as I could tell. To be honest, I'm surprised that it works this well already.

I found a sticker with version information on the back on my pendant (underneath the rubber):
 
The top row is the firmware version and the bottom row the hardware version, I believe. And the RX should be the dongle, because there is a V09 marking on the main board (underneath the RF module).

And I attach a couple of photos from the dongle as well, in case somebody wants to compare. Not the best photos. I took them through the microscope some months ago. And right now I have a thousand wires connected for debugging, so not possible to take good photos at the moment.
 
 

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.