Advanced Search

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.

MRx wrote:

I'm going to operate it with a large CNC in the near future so I will see if it will hit me too.
 

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 

Thought a bit about this with disconnects/reconnects.
It is actually normal behavior and the component is designed to work with that.
In run(), that is the main loop, github.com/LinuxCNC/linuxcnc/blob/ffc393.../xhc-whb04b6.cc#L414
There is a loop that opens the device, processes and teardown usb, repeatedly.

The stop in setupAsyncTransfer() should not be fatal. The assert() statement makes it fatal.
I now remember my original issue I opened two? years ago, it was to remove assert() statements,
because I at that time found that the code does the right thing, in principle. Just that the asserts() 
should be removed.

The call to setupAsyncTransfer tries to see if the usb device is connected with the mIsRunning flag,
but if I understand right (not necessarily) things change sometimes before libusb_submit_transfer().
github.com/LinuxCNC/linuxcnc/blob/ffc393...whb04b-6/usb.cc#L539
github.com/LinuxCNC/linuxcnc/blob/ffc393...whb04b-6/usb.cc#L456

I think now that the right thing to do is to have a failed libusb_submit_transfer() not crash the component through an assert() call
Instead finds it way in the call stack back to ::run() where the usb comm is torn down and the device is reconnected
and everything can continue.



 

I'm interested to try it out.

Can there be different versions of the usb dongle firmware?
Like newer devices don't have the reconnect issue?

I tested now and get same behavior as you. This was some small news for me. I thought it only started reconnecting if it had already been in use already by LinuxCNC.

The test was like:
1. Pendant off, plug dongle into computer. No disconnects for 5 minutes.
2. Turn pendant on. Disconnects start with around 20 s cycle.
3. Turn pendant off. It looks like dongle stays disconnected. Maybe just bad/good luck with the timing.

I already made some first steps for a new driver. The initial target of that was to have reliable polling. I already abandoned it and started thinking more about the firmware. But maybe I should give it another shot. I'll try to have a look tomorrow if I can clean it up just slightly and post it here. It's simple enough to play around with and it should be able to provide stable polling.

If you just have the dongle and pendant attached and switched on do you get resets every 20 sec?
I mean, without linuxcnc.

I took the dongle and pendant to a bit newer N150 PC. Plugged it in. Ok, was discovered.
Switched on the pendant and it started with the 20 sec disconnects/reconnects.
Switched off the pendant with the button and it stopped. There is a clear relation.
It can be related to polling, I guess.
Searched for a simple program to regularly poll a usb device.
Best I found was "usbreset" but it didn't change anything.

Interesting that you MRx says it is stable. Advice was to test with USB 2.0 and I have looked
and it isn't easy to find a PCI-E USB 2.0 board I can get in a few days. My motherboard
Gigabyte Z170N-WIFI does have an internal header for USB 2.0/1.1 and I should get a cable
and test I guess.

I had/have very similar issues as you mention earlier today Hakan. The after the pendant disconnected once, it kept doing so every 20 s or so, just like for you. And you see the LIBUSB_ERROR_NO_DEVICE because the dongle has disconnected. However, if you again start LinuxCNC (maybe need to try a couple of times to get the timing right), the pendant will resume working just fine and the disconnects stop for the time being.

As I have said, I believe the reason for the disconnects is that the dongle is unhappy with the current situation and resets itself. And "unhappy with the current situation" is most likely because the host has not been polling its interrupt endpoint for some time (maybe half a second or so).

I attach here a logic analyser screenshot, capture file as well as wireshark capture from a "forced" disconnect event. For this capture, I had the dongle disconnected, LinuxCNC (sim) running a program and in the background waiting for the pendant. I then started all captures, connected the pendant, pressed the Step button (and maybe some others) on the pendant and jogged the wheel. This caused the Usb::setupAsyncTransfer assert failed.

In the screenshot you can see that from approximately 2950 ms (corresponding to wheel jogging), there are no packets until ~3600 ms (except for SOF, which I have turned off on purpose). And at 3750 ms, there is a reset on the USB bus, corresponding to the dongle "disconnecting" and the assert failed. This reset is as far as I'm concerned generated by the dongle itself, because it was unhappy with the conditions.
 

If I zoom in a little bit on the disconnect/reset event, that becomes more clear. Here I have turned the SOF packets back on, and we see that they are sent every 1 ms as expected. And then suddenly the D+ signal drops to zero, indicating a bus reset (either from the device or the host). And I see no reason why the host should generate a reset in this situation, so I say its generated by the dongle. This is consistent with repeated disconnects every 20 s already discussed.
 

The .sr file can be opened with PulseView and the .pcapng with Wireshark, in case anybody wants to have a look.

At least for me the pendant is anything but solid. And I do think the dongle firmware is mainly to blame. That being said, it could very well be that different drivers/hardware could mask some of the issues I experience. If only I knew what causes (all) the disconnects, I'm sure we could figure out some ways to fix it.

Under normal operation there's no disconnect of the XHC pendant. It's solid. If you power it off it will disconnect.

I heard from others that they had EMI problems with USB and the XHC pendant in the past, I'm going to operate it with a large CNC in the near future so I will see if it will hit me too.
I think you have to fix a problem on the USB layer, maybe use another system which has a native USB 2.0/ehci port. The XHCI USB ports can cause issues depending on the hardware.

By the way you can easily convert an WHB04B to 6 axis by removing a stopper with a knife which is inside the rotary switch. 6 axis are wired up even on the 4 axis versions.

Had a session with a lot of mode shifts, auto programs, manual and mdi and not being careful when mode shifting.
Worked great, it felt like there was no problem with the xhc.
I had checked autosuspend which was set to 2. Set it to -1 and the disconnect/connects in syslog stopped.

Finished after a few hours. Checked syslog and now the xhc is just laying there doing nothing on the milling machine.
The faint light is on, that's all. And the syslog fills with new disconnect/connects. Every 10-20 seconds it happens.
autosuspend was already set to -1.
Went to the milling machine and turned off the pendant. New disconnects/connects stopped coming in syslog.
Didn't touch the usb dongle during the whole day. The pendant causes the disconnects? When idle?