Advanced Search

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?

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.

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

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.

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.

Do you think the MPG XHC WHB04B 4 model will work well?

Wireless, wired, or does it not matter?

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.

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.

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.

If I am not careful the whb04b crashes and only way to restore function is to restart linuxcnc.

I have found it happens when the display does a big re-organization.
Typically I just finished in Auto, with a certain screen layout.
Then I jog in any axis: The HMI switches from Auto to Man, can also be MDI to Man,
the screen re-organizes, buttons appear. At this point it is 50-50
if the whb04b crashes. 
I have learnt to avoid using the whb04b to switch modes, and now the whb04b works many hours/days.
It looks like something does not like the relatively long wait for the screen
to rearrange. Happened in Gmoccapy, qtdragon and qtdragon_hd.

Okay, I mostly understand. Configuration of the pendant is a bit clunky. Nice that you got it working somehow and good on you for posting the solution.

I am mainly thinking about improvements to the driver and/or firmware. Of course, configuration could maybe also be improved, but that would not be the priority for me.

I already asked this question in the forum a few days ago. 
[solved] XHC-WHB04B-06 rotary knob button feed rate not work

No, the head is working perfectly and all pins are there.
There is just no signal for the feed in program mode.
You need to tap this  from whb.axis.[joint].jog-scale and convert it.

I consider having to restart LinuxCNC unacceptable. If I don't find a better solution, I will not use this pendant.

The rotary knob sounds more like a configuration issue(?). Have you checked if you see the position switch changes by running "xhc-whb04b-6 -a" from a terminal?

Hi,

I'm interested.
I also have the problem that the connection disconnects after a while. For me, however, it's enough to close LCNC, disconnect the dongle, and reconnect it.
I'm interested in the feed setting of the rotary knob button.
This doesn't work; only the increments can be set. I was only able to solve this with a workaround.

Hi,

Is anybody interested in some development for the XHC WHB04B pendant? Both from a user perspective, but also with the development itself.

I bought a WHB04B-6 to use with my mill, thinking it should work okay. But of course there are issues. After a while, it disconnects and I have to restart LinuxCNC to get it back working.

I have already went quite deep with this, and have some and can generate more material:
 - USB packet captures with Wireshark (form both LinuxCNC and Mach3)
 - USB signal capture with logic analyser
 - WHB04B transmitter firmware
 - RF signal capture

One thing I noticed with the xhc-whb04b-6 component in LinuxCNC is that is has some blocking wait states. These can delay the USB polling of the WHB04B so much that it causes the device to reset. I fixed that (for myself), but still there are issues...

There are several possibilities:
 - improve the xhc-whb04b-6 component
 - create a new driver/component for the pendant, realtime if seen necessary
 - create a new firmware for the WHB04B transmitter, possibly also for the pendant itself

Any comments or thoughts from the community?

I guess many have the opinion that both wireless and USB pendants are a no go. Personally I don't see an issue at least for "garage application", provided its properly implemented. The main thing would be to have a watchdog monitoring the communication, which can (e)stop the machine if necessary.