XHC WHB04B development?

I think the github issue is dead so better discuss here.

It's always the same error: github.com/LinuxCNC/linuxcnc/blob/ffc393...whb04b-6/usb.cc#L465
Don't have an actual log available, pretty sure it's that line

Okay, thank you. I'm fairly certain that the reason for that message is that the pendant (dongle) has reset itself. But I don't think we know why it did so in this case. It could be something that the xhc-whb04b-6 component is doing wrong (different from the mode change delay). But it could also be that the dongle firmware is just that unstable.

I don't have any real good way to troubleshoot this. For the mode change timeout, I could capture the USB signals with a logic analyzer. But that is not feasible with my equipment if I need to wait for maybe one hour for the issue to occur. Wireshark is a possibility, but it does not show the low level packets...

I wonder what "r" is - it doesn't say.
I'll some printouts.
One can possibly dig deeper into the layers and see exactly where it fails.
One level down:
github.com/libusb/libusb/blob/dcd30cec9a...ff/libusb/io.c#L1486

The crashing doesn't respond well to provocations. I can generally get it to crash when switching modes,
but it doesn't crash when I want it to crash.

I'm pretty sure it's easiest to just add a printf("%d\n", r); between the libusb_transfer_call and the assert statement. And I'm also fairly sure I did that at one point.

And then you can just match the terminal ouput against the libusb_error enum:
github.com/libusb/libusb/blob/master/libusb/libusb.h#L1282

The docs for libusb_submit_transfer also has a section about the errors it can return and a little bit about what they mean:
libusb.sourceforge.io/api-1.0/group__lib...7dad2fee4b27962848ce

What did you find as being the problem? You probably already wrote it, can you do it again?
What is the way to fix?

The problem is that the dongle resets itself. Basically the same as pulling it out of the USB port and reinserting it.

In the situation where you try to jog with the pendant while running a program, this is caused by a too long time during which the xhc-whb04b-6 component does not poll the dongle. This we "fixed" with the loops=10.

In the other situations that happens "randomly" after some time, I do not know what the reason is.

Had event logging on today. It failed again (loop =10).
libusb_submit_transfer failed with LIBUSB_ERROR_NO_ DEVICE (-4) 
github.com/tenderlove/libusb/blob/763471...libusb/libusb.h#L750
github.com/tenderlove/libusb/blob/763471...13/libusb/io.c#L1288

 

Syslog is absolutely full of usb disconnects of the xhc device. Every 16-17 second the device disconnects and reconnects.
Must be the xhc component that does this? It only happens when linuxcnc is running.

 

If I look in github.com/tenderlove/libusb/blob/master...usb/os/linux_usbfs.c and search for LIBUSB_ERROR_NO_DEVICE,
they are there.
Why are all the disconnects/reconnects there? Wouldn't surprise me if that can cause something.
 

Disconnects might be caused by multiple reasons.

a) poor xhci support for that system - try to connect the pendant to a USB 2.0 port
b) check if USB autosuspend is disabled (as root)
cat >/sys/module/usbcore/parameters/autosuspend
echo -1 >/sys/module/usbcore/parameters/autosuspend
c) if connected to a USB hub - don't do that, connect it directly
d) EMI issues, check if there's a pattern that can trigger this, check if a relay is able to disconnect it somehow; I had HDMI displays resetting due to issues with relays a decade ago (eg. missing flyback diodes)

I worked on the XHC pendant some years ago to fix some issues, I never had disconnect issues with it.

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?
 

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.