Advanced Search

I made some changes in my firmware so I could generate a disconnect at will. Ten times in a row, I got libusb_submit_transfer to return non-zero in Usb::setupAsyncTransfer. And every time, the pendant reconnected to the xhc-whb04b-6 component without issue. In other words, I am unable to reproduce your issue, which more or less means I cannot help you directly. However, you mentioned that you had to change libusb_init_context() to libusb_init(). It appears libusb_init_context() was introduced in libusb 1.0.27:
libusb.sourceforge.io/api-1.0/group__lib...e12023b7399003c50470
Looking at my system, I have libusb 1.0.28-1. I think it would be well worth trying to upgrade libusb. Or if you don't want to do that, you could use LinuxCNC 2.9.8 as a "live cd" to see if that fixes the issue. This would actually be better, since it's possible that the issue could be in the Linux kernel itself.

What does the 'LEAD' function do?

Hallo Linuxcnc Freunde,

habe festgestellt das bei dem Handrad XHC-WHB04b-6 die Lead Funktion nicht richtig funktioniert.
Habe an der Treiberdatei pendant.cc die Zeile 346 hinzugefügt. Die "oder" Funktion für die 9b oder 1c wurde ja schon mit einegbaut. Danke an alle dafür.

Bei mir funktioniert diese jetzt und lässt sich aktivieren.
Hoffe konnte ein bisschen weiter helfen. Leider muss dazu Linuxcnc neu erstellt werden mit dem make Befehl.

Habe versucht die Datei mit hoch zu laden, hat aber nicht funktioniert.

[edit]
 

That was unexpected. For all the world, it looks like this get stuck in libusb somewhere. After the "is Open" debug text, the code does the following:
1. Function call XhcWhb04b6Component::enableReceiveAsyncTransfer()
2. From XhcWhb04b6Component::enableReceiveAsyncTransfer() call Usb::setupAsyncTransfer()
3. From Usb::setupAsyncTransfer() call libusb_submit_transfer()
4. From libusb_submit_transfer() call libusb_unref_device()
5. In libusb_unref_device() print "libusb: debug [libusb_unref_device] destroy device"
6. libusb_submit_transfer() never returns is my guess
Maybe some deadlock inside libusb. Whether that would be from some bug in libusb or because of some improper handling in the xhc-whb04b-6 component, I cannot say. At least at the moment. I'll look into it some more, but not right now.

Got a crash today. Seems to be the usual way. At mode and screen switch.I have seen that libusb debug printout several times before.Attach are the log and also usb.cc and xhc-whb04b6.cc to be able to follow my printouts. 

Okay. Once you get a crash, post the output here and we can try to work it through together. Please ensure that you have some print statement in place of the commented out assert call, so if it fails there, we know about it. Something like:

Still trying to learn exactly where in the code it fails.
It doesn't reconnect, that's for sure. If it had, it wouldn't have been an issue.
I overwrite the log and, alas, no saved useful log.
"Unfortunately" I didn't get a crash today when I worked with the machine.
I like the whb04b a lot.It's worth spending some time improving stability.

 

I was just in the garage using the mill with the pendant. And thought that maybe I should post a mood picture, so we don't forget why we put effort on improving the pendant software
 

Hakan, as far as I can tell, the component should try to reconnect after a failed asyncSetupTransfer in case you comment out the assert call. It should then after a short while fail on libusb_control_transfer, which then calls setDoReconnect(true), which in turn should cause a restart of the USB stack.

If you run the component with the -a flag, the console output when it fails would be interesting to see.

Thanks! I just modified quickly linuxcnc to send exactly your data. But no F/S. So I think just a buggy firmware.

One more update on display in Auto mode. NOW it does show F: and S:
and also coordinate updates.
After x minutes is seems to enter some sleep mode and stops updating the
display altogether. Buttons still work though.

I think I wrote that the component is prepared for reconnecting. No, it isn't.
If the setupAsyncTransfer() fails, the component exits.

I am testing to see if the usb part can be restarted. 


 

I'm fairly sure I fixed the 0.0035% bug I mentioned in the last post. Swapping two lines in the code should have been enough. Right now, I'm not aware of any real bugs in my firmware. I will continue using it with the dongle/pendant on the mill. But unless something comes up, I consider it good enough.

Unfortunately, I was mistaken about the bootloader version where the dongle firmware can more easily be read out. It is possible for versions before 2.40, but not with version 2.40 or 2.50. So right now there is no easy way to read out the whole firmware from the dongles.

I think the data looks okay for you Hannes, and it seems likely that the firmware on your pendant doesn't support the F/S indications. I am not setup to build linuxcnc on this machine right now, but here is a screenshot from Wireshark showing the same type of data as your terminal output:
 
The highlighted line is the last part of the report, where the feed and spindle overrides are given. For me, both were at 100% = hex 0x64. My pendant also shows the F/S values in auto mode when a program is running. Many different firmware variants, I suppose...

I've had LinuxCNC simulation running a long G-code program a couple of nights to see if I can find some issues with my dongle firmware. So far, no disconnects nor any other meaningful issues. Sometimes (around 0.0035% of the time) it send a zero-length package, which is not correct, but neither is it harmful. I will try to look over the USB handling to see if I can get rid of that one.

I just had an idea: I don't need A/B/C, so I wired the feeds to these channels. It works way better anyway and I can use the jog wheel.

You can not use this in MDI mode due to when jogging, the WHB automatically changes to manual mode.
In auto mode with linuxcnc 2.9.8 without my patch, you probably will get a lot of error messages due to the whb wants to change from auto to manual. But this is gone with this fix:
github.com/LinuxCNC/linuxcnc/pull/3810/c...f939ee3cfb99275R1344

See  after:
#Rewire feeds to A/B/C

 

Hmm, mine shows always 0. In Mach3, Mach4 and LinuxCNC.

I'm pretty sure I just have a variant with a different buggy firmware than yours.

However, if you have time to spare, you can comment out the line in my last post, recompile linuxcnc and send me the result. Which version of LinuxCNC are you using?