Advanced Search

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.

Hat sich erledigt.
Hatte die Frage auch im Englischen Forum gestellt und letztendlich eine Lösung gefunden.
XHC-WHB04B-06 rotary knob button feed rate not work

I have found a solution that works for me.
After wasting a week with Mux trying to build something with 6 input pins + enable, I have now decided on a different approach. Since the rotary control does not have a direct output for the feed, I am tapping the signal from whb.axis.a.jog-scale. Now I just had to convert the value with div2 for jog, feed, and rapid.

I tested the signals on the rotary control.
The pins for feed.selected light up depending on the selection.
whb.halui.feed-override.scale always remains 0.
whb.halui.max-velocity.value always remains 166.666. 
 

You could quickly check if those have the desired affect by opening halshow, opening the "watch" tab and picking those pins from the tree. Then you can set values directly.

If that works then link them up in HAL.

I use gmoccapy.

So far, I have found that these two signals control the feed rate:
gmocacapy.spc-feed.value
gmocacapy.spc-speed.value

Which GUI are you using?