Advanced Search

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.

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?

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.

I mean, what do your program and usbhid-dump do that stop the disconnect/reconnects?
And why doesn't the whb04b component do the same?
Rhetorical question.

I looked briefly at the codes, but this is a big hurdle..

Regarding the firmware for the pendant, I thought about trying to read it out with glitching or some other technique. But I have not seen the need for it so far. I did read out the firmware from the dongle, but also that was quite much work for what in theory should be simple:
github.com/finngineering/ch55x_firmware_extractor
The reverse engineering I have done for that is with Ghidra. But the dongle is based on the CH554 microprocessor, which is a "8051" type. And the support for that processor is not the best in Ghidra.

I'm not sure what differences you are asking about for the usbhid-dump Hakan. I haven't really checked the source, but I guess it's just polling the interrupt endpoint more or less the same as my test program and the xhc-whb04b-6 component. What would be interesting to know is if there are disconnects with all these program if left running long enough. Say, 1 day or so. Or if that happens only with the xhc-whb04b-6 component (and maybe only while LinuxCNC is running)... I could maybe leave it running overnight myself to check.

Found usbhid-dump github.com/DIGImend/usbhid-dump/tree/master
which already is in the linuxcnc systemalso keeps the xhc from disconnecting.
What's the difference vs the component?
The whb04b component uses async transfers, but more?

FWIW, I put the usb dongle in my windows 11 computer. Disconnects/reconnects there also.

you might try to read the firmware by glitching the voltage, I did that with an STM32F0 part in the past (but another application), I was even able to re-flash the image. I don't know if it also works with the G0, but you might try. Most importantly is to remove the capacitors.

sec-consult.com/blog/detail/secglitcher-...32-microcontrollers/

I will take a photo of the wired USB version later this week since my pendants are in the shop

Yes, the output stops for some 10 seconds after operating the pendant (I think any action, not only the wheel). If you press a button during that time, it still comes through. But the regular updates resumes only after about 10 seconds.

At first I thought this 10 second delay was because I somehow polled the dongle in a wrong way. But I later tried it with the Mach3 driver, and found it to exhibit the same behavior. So I would say this is again pointing to not so high quality dongle firmware.

The idea was the program was partly to investigate the issue, partly to maybe create a new driver for LinuxCNC. Like I have mentioned, I'm not fully happy with xhc-whb04b-6 component functionality nor with how its coded (too many layers of abstraction for my liking/understanding). And the "blocking calls" are basically a fundamental issue with it. But don't get me wrong. I do appreciate and praise all the work done by the guys/gals who has made and updated the component. Evidently it works fine in many situations, just not (all the time) for me.

I was just thinking that I was able to work with the pendant for hours, despite disconnects.
You are of course right, it's not correct. The component seems to try to adapt to the situation
and succeeds to 99.5%.

Tried your code. Had to replace libusb_init_context with libusb_init, after that it ran.
You have some skills there for sure.
Yeah, it kept the pendant busy. There were no disconnects while running.
The polling stopped, or maybe the output stopped, for some ten seconds
after turning the wheel, then it started again. I guess that was intentional.

What's your idea with the code? Just for test or should it replace the usb code
in the whb04b component or ?

I should be able to downgrade my usb to usb 2.0 on wednesday.

 

Here are a few photos of my pendant that I took in the summer. Sorry, but I do not currently have any photos with the cards inside the housing. And just for info... I tried to read out the firmware from the STM32, but unfortunately it is read-out protected.