XHC WHB04B development?

Do you means when the computer screen re-organizes? Or the pendant screen?

I found that if I try to jog when a g-code program is running, the pendant will disconnect every time. The reason is too long blocking (like I mentioned in the first post) without USB polling. The pendant will request manual/teleop mode (I don't recall which) and wait for minimum 300 ms if the mode does not change. It's these two functions:
github.com/LinuxCNC/linuxcnc/blob/master...6/hal.cc#L1361-L1420
I solved this issue by reducing the "loops" parameters here:
github.com/LinuxCNC/linuxcnc/blob/master...b04b-6/hal.h#L71-L86
Maybe your issue could be because of the same reason?

Still, if I use the mill for an hour or so, the pendant is likely to disconnect. And I have not found any specific reason for that yet.

The computer screen, with the g-code trace. 
I have some user macro buttons, they are on the screen in Man but are removed in Auto and the trace window is resized.
I agree with the too long blocking diagnose, sounds exactly like the problem.
I'll try that tomorrow, it would be great to get a fix.

Okay, cool. Let us know if you try it out. Maybe you could check if its the same for you as for me when trying to jog while running gcode prior to updating the xhc-whb04b-6 component. The pendant always disconnects in that situation for me.

Tested today, but not very conclusive I'm afraid.

Default master branch.
Jog while running Gcode: Doesn't allow me.
First time running gcode, press stop. While in Auto mode spin the wheel: It crashes see screen dump below.
After restart and retry this several times: It works, it switches to Man and moves in Z.

With loops=10, it always works, at least the say five times I tried so maybe not conclusive.
I can continue with this setting to see if it fails later.
 
I always get this "assert" error when it fails.

Okay, thank you for the feedback. I realize now I wasn't clear in my last request, but I meant jogging with the pendant while a program is running. But you did that as well.

This setupAsyncTransfer() assertion failed is also what I had before changing the loops. That error occurs when the USB dongle has already reset, most likely because it saw no activity from the computer side.

I mentioned that after some time, the pendant still stops working for me. But I don't recall right now if I have even checked if I get the same setupAsyncTransfer failed at that time. I should check...

If you continue using this modified version, let us know if it looks to have cured the other issue you had as well.

I just started on writing a new firmware for the dongle. But I'm not sure where that will lead, if anywhere.

What number do you use for loops? Is any number "best"?