XHC WHB04B development?

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.

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?

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

 

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

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. 


 

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

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.

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
 

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.