XHC WHB04B development?

I believe I have 10, but can't verify until tomorrow or Monday. I have only tried the one value, which was an educated guess and seemed to work.

The total delay can be loops * timeout, i.e. 60 * 5 ms = 300 ms with the default values. In practice it can become longer because of how the delay is made and how the kernel schedules the task. I would imagine that as long as the delay is more than a few servo cycles, it should work. So probably it would work even with loops set to 1. But I have not tested. Nor do I think it would solve all issues that I experience.

Ok, I continue with the 10 I have guessed and set.

Seeing that you understand pretty well what is going on, what will you do different with a new driver?

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.

I have loops set to 10 and timeout to 3.

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.

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.