Advanced Search

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.
 
 
 
 

Attached is the "test driver" I made, which repeatedly polls the pendant and displays the data received. It can also update the display if you uncomment the last line in usb_interrupt_callback(). Just unzip the file into a folder and running from the terminal you should get something like:You need to have libusb-1.0-0-dev installed for this to compile it. But if you already compiled LinuxCNC from source, I think you should already have it.

And regarding repeated disconnects... It may be normal behavior in as far as that is what happens. But it is for sure not correct behavior.

I would also prefer a wired pendant over this wireless one. But when I bought it this seemed like the best option for me for a relatively low cost. And I do not think that the issues we see are caused by the RF link failing.

I'm using the hardwired version for years without any problems - no disconnects.
Can you open your pendant and take some photos of the PCBs so I can compare it with mine?

It could be the radio version that have the crash issues I guess.

MRx, you don't see these disconnects/reconnects for your wired pendant?

MRx wrote:

I only have the wired versions of it (3 of them) and they are solid.

A hard wired pendant with no USB is only $30 to $50

I only have the wired versions of it (3 of them) and they are solid.