XHC-HB04 wireless MPG pendant HAL module

Hay thanks for the quick response. I'm new to Linux. Can you help me? How do I add this source code into LinuxCNC? I want to try to change the code (device address for reading and writing)

See also this post

forum.linuxcnc.org/forum/24-hal-componen...dule?start=230#58005

I made the same mistake. I also thought I could simply change the VID/PID pair but I think things are rather more complicated. I am not saying it can't be done but I think it does require quite a lot more work than that. I found the simplest solution was to return the wrong one for an exchange. I can confirm that the proper HB-04 works really well and as well as the 'normal' jog functions I have got it doing auto probing Z height and toggling mist and flood.

Thanks for the reply.
Does anyone have any idea how to work with this remote

Yes, I would agree - there seems to be an issue about the word length (8 bit on the HB03 vs 16bit on the HB04) as the display is different. I am sure it is possible to do something about this but I concluded it was non-trivial and would take far longer than my return trip to the post office for a replacement HB04. If you have a friendly programmer they may have an alternative view

#_wc_frac - it is 8bit for WHB03 and 16bit for WHB04 ... it is simple whan you look two display max frac part for WHB03 it is .99 and for WHB04 it is .9999 ... this value also have a SIGN bit if value is negarive you must set most significant bit to 1... little example:

WHB03
our X position is: -117.33
we put 117 to x_wc_int
we also put 33 to x_wc_frac
we have negative value... we also need to set most significant bit of x_wc_frac to 1...

Code: Select all
x_wc_frac = x_wc_frac | 0x80;


WGB04
our X position is: -220.3345
we put 220 to x_wc_int
we also put 3345 to x_wc_frac
we have negative value... we also need to set most significant bit of x_wc_frac to 1...

Code: Select all
x_wc_frac = x_wc_frac | 0x8000;

Well I was trying to sort through why I can't get the scale or filter to work and I realize I may have done things wrongly.

I ended up building my own xhc.hal file based on the connections in the man page. It does a "loadusr -W xhc-hb04 -H -I xhc-hb04-layout2.cfg -s 3" and connects lots of stuff.

There's a [XHC_HB04_BUTTONS] and [XHC_HB04_CONFIG] section in my .ini file which are what the .tcl file said to include. But HALFILE = xhc-hb04.tcl in the ini broke the loading, so I omitted it. Those two sections don't seem to do anything, which confused me, but now I think I see they were used by the .tcl and I'm not actually using the tcl.

Now I think I understand, xhc-hb04.tcl is literally the hal file which reads [XHC_HB04_BUTTONS] and [XHC_HB04_CONFIG] sections. This causes 2 problems- one, it seems there can only be one load of xhc-hb04, and two, signals I connect in mine get connected there.

So I tried removing the xhc.hal file I worked so hard on, but found the xhc-hb04.tcl HAL was conflicting with the way spindle-rps had been used elsewhere, and broke motion somehow (joint following errors). I feel like it would be a huge setback to go back to diagnosing joint following errors.

Am I right in my understanding now? Does it make sense to try to make the .tcl work? All I really think I need is flipping the Z axis- in MDI, Z+ makes it go up (stepper DIR is correct), but the wheel CW (should mean +) goes Z-, none of the other axes are - for CW. And filtering- is ilowpass a good option? Can I just install that? How can the Z-wheel be flipped?

I saw the .tcl connected through pendant_util. Is that still there? Should I manually connect pins through it in the hal without the tcl?

OK I realized I was being dumb and the line inverting the Z-count was right there.

I tried ilowpass and I saw the following things:

1. "Scale" is terrible. It just skips mpg pulses, which is detrimental to the feel and utility of it. e,g. "scale=3.0" on 0.01in/tick means the first tick moves 0.01", the second nothing, the third nothing, then the fourth moves 0.01". So, 1.0 is the only good value for this.
2. If I reduce gain to the point where it seems to be doing real filtering, I can get a "joint 2 following error", which I have not seen for a long time, and I'm perplexed why this would be. With a 1ms servo thread:
setp ilowpass.0.scale 1.0
setp ilowpass.0.gain 0.05
net jog-counts_in xhc-hb04.jog.counts => ilowpass.0.in
net jog-counts_out ilowpass.0.out => axis.0.jog-counts axis.1.jog-counts axis.2.jog-counts

With gain set to 0.1, it doesn't get a following error, but smoothing performance isn't very good either.

axis.2.jog-counts is still subject to accel and velocity limits, right? I have no problem with running fast 3D carving g-code, or keyboard, or mdi, or non-ilowpassed mpg, even when spun wildly.

I suppose when spun wildly, ilowpass would slow the gantry response leading to a larger accumulation of mpg counts. But how could that break the joint following? I've had the router set with slow velocities and high mpg distance-per-tick and it caches a lot of ticks (and distance) and continued to move for like 5 sec after the mpg wheel was stopped, but never did this cause a following error.

EDIT: Really ilowpass DOES NOT improve things in any significant way. What I'm seeing is it's just slowing down an accumulation of pulses, but that's not the problem here. Like the coarse 0.1"/step scale, with a machine with high accel, you turn the knob slowly and the pulses don't get backed up, but then the machine feels EXACTLY the same as it does a high accel for each 0.1" pulse, then stops, then gets a new pulse command. You can add a very low gain but it's not going to help. It does nothing to resolve the shaking.

I need to vary acceleration here, and lowpassing doesn't achieve that.

EDIT2: OK, I see what they're doing, you're supposed to scale up a pulse by like 1000x, lowpass it, and divide by 1000 to achieve the same scale. Thing is, xhc-hb04.jog.counts is already calculated by the xhc-hb04 mux depending on what speed is selected. So I can't hardcode in a constant like the integrator's guide uses. I don't see the exposure of the scale=1,2,3 selection, just the selected scale (1,10,100). Actually I really need that because filtering is different on different scales and potentially axes. But I don't see the exposure.

I could divide by 1000x again at:
net jog-scale xhc-hb04.jog.scale => axis.0.jog-scale axis.1.jog-scale axis.2.jog-scale

But can you do an arithmetic divide on an float inside of a HAL? Google is telling me that's... awkward. Well, there's a mult2 component, but you have to add it to a thread, and I'll need to create another component, invert, to tie it directly to ilowpass.0.scale.

What gets me is that when going into 0.001" stepsize, lowpass is still dividing by 1000x, making a 0.000001" stepsize inside lowpass. I don't see how that breaks anything right now, but it looks pretty crazy. That lowpass divider just isn't correct for the 0.001" stepsize but there's no way to adjust it by stepsize. I actually could make the divider change by axis, by creating 3x lowpass all fed by xhc-hb04.jog.counts and outputting to independent mult2 and then to each axis.x.jog-counts. But there's not a lot of need for that.

Why is it always so difficult to set something up in LinuxCNC?

It really is like trying to program a microcontroller in assembler or pulling your own teeth out. Always editing files with little details to make it work. Mind you when it works it does work fantastic but it always seems to be a struggle to get anything working.

I have a XHC-HB04 wireless version. I selected the sim module and it opens a window and all appears to work with positions and codes.

So where do I find that sim folder and do I just copy the whole section into my HAL file?. Someone needs to please make up a MPG install for dummies
I am using 2.7.7


Mark