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?

Short update on that, Hannes. 
While in auto mode and running a program it doesn't show F: nor S:
It does react on Feed+/- and Speed+/- but only on displayed values in the HMI, not the pendant display.
In Man mode it shows F: and S: in the way one expect.

@Hakan:
Strange. Mine doesn't show anything. But it's an LHB04B-6 TX V3 (Wired version)
As much as I read, it should work the same, but might be not.

Starting with -Ha and commenting out github.com/LinuxCNC/linuxcnc/blob/master...whb04b-6/usb.cc#L209 it shows:

out 0x06fefdfe801800bc 060e0800161e0200 06008069006e0000
out size 24B hdr 0xfdfe dom 0xfe status 0x80 coord1 +0024.3772 coord2 +0008.7702 coord3 -0002.0000 feed 0105 spindle feed rate 00110

So it seams the values are sent. Might be my device has a different firmware. With Mach3, I tried already and I didn't see any value. I will try again with Mach4.

Do you mean that the pendant did not recover in the above situation after you had commented out the assert line?

You could enable all logging by adding the "-a" option when loading the xhc-whb04b-6 component. It will write a lot of things to the terminal... which makes it easier to figure out if it gets stuck in some specific part of the code.

I have added a bit more logging to the component..
The component is attempting to connect, it says, but I wonder if it actually tries and why that doesn't work.

Okay. I did not really think that libusb_fill_interrupt_transfer() would solve the issue. But that IS the correct function to use in any case.

If the disconnect happens only at mode switches, I'm pretty sure it can be solved simply by modifying the xhc-whb04b-6 component. Maybe we need to add some more (temporary) logging to the component to pinpoint the issue.

It appears our dongle firmware is different by one version increment. But of course the hardware side is the important one for compatibility. I would think that there is a good chance that the hardware is compatible or the same.