Advanced Search

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 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.
 

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.

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

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

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.

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 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

Yeah, at least for me the loops = 10 was not the solution to everything, so not surprised the situation is the same for you. As far as I have seen, this loops = 10 would only help during a LinuxCNC mode change (auto/manual/mdi/teleop/joint).

I was not aware of that issue, so that you for bringing that up. I will write a comment there (if I can), because I think what we have discussed here is a partial solution.

I would be interesting in knowing the error message (if any) when it fails, i.e. console ouput. This I can also "generate" myself, but right now I'm not using the machine.

Used the mpg today, sadly it crashed again. Loops = 10.

I actually opened an issue on github now over two years ago github.com/LinuxCNC/linuxcnc/issues/2237
No resolution. I never made a serious attempt to understand the code structure of the component.
Just looked at what was going on around the triggered assert() and made some more or less random changes.

Where is the blocking call? I'll see if I can do some ... tests.

Yes, I think its realistic to write a new firmware. The goal would be to have the pendant fully reliable and also proper detection if the RF link fails, possibly some other improvements as well.

It doesn't have to be an either/or solution. With the new firmware, I would probably strive to maintain "protocol compatibility", so the same xhc-whb04b-6 component could still be used.

Improving the xhc-whb04b-6 component is certainly possible, and hopefully that could be done as well. For this blocking wait state, I don't really see a clean/simple fix, other than reducing the max blocking time like we have done. And to be honest, the amount of abstractions used in the code makes it difficult to follow for myself.

But this is also one reason why I made this post. To see if others have similar issues (and now you have confirmed that its not only me). Maybe there is somebody else that wouldn't mind updating the xhc-whb04b-6 code, but would need inputs on what to change.

Is it realistic to write a new firmware for the dongle? Is it to improve on the reset?

Sounds like you identified blocking wait states as at least one big part of the problem.
Realistic to rewrite those sections in the component?

fyi, I have the radio version, works well for me needs.

I have loops set to 10 and timeout to 3.

Hi,
anhand deiner Hal denke ich, du sprichst deutsch.
Zunächst: Welche Vorlage hast du für die Konfiguration genommen?
In der ini sehe ich folgendes
1. Für die Verwendung des Handrades musst du noch die Makro buttons mit rein nehmen (müssen nicht belegt sein), sonst gibt es Fehler.
In die hal muss dann folgendes rein: loadusr -W xhc-whb04b-6 -HsfB

2. Es gibt keinen CIA402_HOMING_METHOD=-4 
Schau in die Dokumentation vom A6, da werden alle möglichen Homing Methoden aufgeführt.
Es gibt hier auch keinen Drehmomentbasierten Homing Modus. Du kannst aber einen Endschalter + Z-Impuls nutzen.
Der Endschalter muss aber dann am Driver angeschlossen werden (Di1;Di2)
Wäre zum Beispiel -1 oder -2 je nach Verfahrrichtung.
In der ethercat-conf.xml ist es empfehlenswert sync0Shift="0" zu setzen
 

Hopefully have a completely stable firmware and some type of watchdog to keep track of the communication. By the way, with firmware I speak about the USB dongle and with driver I mean the computer/LinuxCNC component.

I'm not completely happy with how the LinuxCNC xhc-whb04b-6 component works either. And at least for me, the amount of abstraction layers in that code makes it difficult to understand/change.