XHC-HB04 wireless MPG pendant HAL module

Hi.
My LinuxCNC is a fresh install from LinuxCNC 2.7 Live/Install CD (Debian),

I done more test, and then ..

First i checked my conf and sim conf. Still cant fast jog on keyboard if i HB04 is not turned on and rotary switch switched to X and then to OFF. So default mode is MPG Jog ON after runing LinxCNC.

Then i get upgrade from buildbot to 2.7.0.37-gf336b2f and it get worse, much worse.
No i have slow JOG on all the time, and becouse of low Acceleration (50) cant home machine, cant fast jog, cant work

It is possible to get back to 2.7.0?

I have attached my config and axisrc file to this post.

I may still not understand your issues but I will try to explain
the intended behavior when using:
The intended behavior (which is identical to the behavior i observe
with both sim configs and a servo-driven XYZ machine and a servo-driven
XZC machine) is as follows:

1. Accelerations for AUTO (running a program) and MDI modes are
set by ini file settings for [AXIS_n]MAX_ACCELERATION.
These acceleration settings are conventionally as high as
feasible for a given machine to maximize performance when
running programs.

2. Using the [AXIS_n]MAX_ACCELERATION settings for wheel jogging
with a manual pulse generator (MPG) like the xhc-hb04 is sometimes
problematic in that the motions for small increments are impulsive
and shake the machine for each small movement of the MPG. This
jerky motion is objectionable to folks with large, high performance
machines (or so i'm told).

3. The provision for the _optional_ settings for:
[XHC_HB04_CONFIG]mpg_accels = a0 a1 a2 a3
was added in order to provide reduced accelerations when using
the xhc-hb04 jog wheel so that the motions are less impulsive (more
gentle).
These accelerations are in effect in all manual modes (with inclusion
of commit b1b59a9) so they apply for keyboard jogging and homing (but
not when running a program or using MDI).

4. The commit b1b59a9 addressed an issue with the xhc-hb04 going to
sleep. Prior to this commit, when the pendant went to sleep,
the accelerations for keyboard jogging would revert to the
unaltered (typically high) values causing unexpected behavior.

You say that:

Still cant fast jog on keyboard if i HB04 is not turned on and rotary
switch switched to X and then to OFF. So default mode is MPG Jog ON
after runing LinxCNC.

Expected behavior is that keyboard jogging will use the (typically lower)
accelerations specified with [XHC_HB04_CONFIG]mpg_accels. Please
note that the accelerations are limited but _velocity_ is not limited
with use of this feature.

I cannot reproduce behavior that requires the pendant to be off.
It is possible your pendant behaves differently than mine -- no clue.

Then i get upgrade from buildbot to 2.7.0.37-gf336b2f and it get worse,
much worse. No i have slow JOG on all the time, and becouse of low
Acceleration (50) cant home machine, cant fast jog, cant work

As explained in 3. (above) jog and homing accelerations will be set to
the [XHC_HB04_CONFIG]mpg_accels value.
I do not know why your machine cannot home with an accel=50, how does
it move at all with that value? How did you choose accel=50?
What are you trying to achieve with [XHC_HB04_CONFIG]mpg_accels?

If you want to use the xhc-hb04.tcl script AND use [XHC_HB04_CONFIG]mpg_accels
AND have fast keyboard jogging you will have to use additional hal logic.
The xhc-hb04.tcl script is just a convenience to connect pins in HAL, you
can connect them without the script if it suits your needs.

There are man pages for the userland xhc-hb04 driver and the xhc_hb04_util
component used by the xhc-hb04.tcl script:You can study the connections made by the script by issuing this command
in a separate terminal:
As an example of logic you can add, you can experiment using the sim_pin gui
to alter the mpg_accels for each axis and test in different modes:

It is possible to get back to 2.7.0?

In my tests (with the sim configs and with real hardware) the behavior
is what I expect and with the fewest surprises. The use-case for
a) slow accels with the xhc-hb04 MPG
and
b) fast accels with keyboard jogging
is not supported with the xhc-hb04.tcl script. It could be probably be
done with custom logic of your own design of course.

I've spent a fair amount of time verifying that the behavior aligns
with the design intent but the convenience of the provided script
may not satisfy every user's objectives -- fortunately hal can be
customized to suit special cases.

First. Thank you for your time, patient and trying to explain. My english is poor but i understand a lot what you write.

4. The commit b1b59a9 addressed an issue with the xhc-hb04 going to
sleep. Prior to this commit, when the pendant went to sleep,
the accelerations for keyboard jogging would revert to the
unaltered (typically high) values causing unexpected behavior.

Along with the hotfix installation i completely lost the ability to fast travel whether by keyboard or MPG. The only option is to write a MDI command or turn off APP=xhc-hb04-accels (im assuming).

As explained in 3. (above) jog and homing accelerations will be set to
the [XHC_HB04_CONFIG]mpg_accels value.
I do not know why your machine cannot home with an accel=50

My machine can't HOME because when referencing the low value of the acceleration does not allow to stop on the limit&home switch, just pass it and crash.

, how does it move at all with that value?

Slow, like it should when i Jog close to work piece.

How did you choose accel=50?

Large acceleration causes jerking the machine when I use dial MPG dial.

What are you trying to achieve with [XHC_HB04_CONFIG]mpg_accels?

Im trying to get what was in LinuxCNC 2.7.0 version with slow acccel on MPG wheel, keyboard fast (no steps no jerking with high acc and vel).

Since my written English is poor, i will record a video how homing procedure looks like, with the current patch, on my machine. Maybe then you will understand where is a problem.

Along with the hotfix installation i completely lost the ability to fast travel whether by keyboard or MPG. The only option is to write a MDI command or turn off APP=xhc-hb04-accels (im assuming).

Not to quibble but the machine will go as fast as before using keyboard jogging
with reduced accelerations. It just takes more time to get to maximum speed.
Short moves will take longer but that is the price of reducing machine shake
for jogs.

My machine can't HOME because when referencing the low value of the
acceleration does not allow to stop on the limit&home switch, just pass it and
crash.

OK, finally i understand. With reduced accel for homing, the overtravel exceeds
the amount allowed for with your home switch mechanism. You could increase the
range of overtravel allowed (modify the switch mechanism) or just reduce the
home velocity (HOME_SEARCH_VELOCITY).

ref: www.linuxcnc.org/docs/html/config/ini-homing.html

The amount of overtravel is:
distance = 0.5 * (velocity)**2 / (acceleration)
So if the acceleration is reduced by a factor of k the velocity should
be reduced by at least the sqrt(k) to stop in the same distance..

Im trying to get what was in LinuxCNC 2.7.0 version with slow acccel on MPG wheel, keyboard fast (no steps no jerking with high acc and vel).

The behavior before commit b1b59a9 was subject to surprising behavior when the
xhc-hb04 goes to sleep. While the time-to-sleep is probably deteministic,
it can happen unexpectedly in working conditions. An unexpected change from
slow acceleration to fast acceleration is not conducive to safe operation.

ref: git.linuxcnc.org/gitweb?p=linuxcnc.git;a...945e6a36374197281ea2

Have you experienced the xhc-hb04 pendant going to sleep? You can monitor the
pin named xhc-hb04.sleeping with the halshow or halmeter utilities, for example:My pendant goes to sleep after about 40 seconds of non-usage.

I can see that more flexibility could be beneficial so as a suggestion,
try the modifications described below.

The acceleration multiplexing is controlled by this signal:
net pendant:is-manual <= halui.mode.is-manual => pendant_util.is-manual
(The input bit pin pendant_util.is-manual should be renamed to something like
pendant_util.alter_accels -- i will probably do this in a future commit)

Modify the ini file to remove the signal named pendant:is-manual and
use the sim_pin gui to allow manual control of the input bit pin named
pendant_util.is-manual
You can then use the little sim_pin gui (in toggle mode) to toggle the control
of accelerations between the values specified by [XHC_HB04_CONFIG]mpg_accels=
and the ini values like [AXIS_n]MAX_ACCELERATION=

After testing, you could make a pyvcp or glade panel to manage the pin
according to your requirements. You could even add additional hal logic to
manage the pin automatically and disable altered accels while homing or for
other special conditions (The pins axis.0.homing, axis.1.homing, axis.2.homing
are true when homing the respective axis)

thanks Dewey for these little tweaks of knowledge , i had noticed mine going to sleep .

by any chance can we see a example on the machine hal ? I have made the configuration as the WIKI but i cant get it to move from mpg and also the axis and step has no function . All of the rest of the buttons work on it . I have comment out the problems to detect the exact pins . I have understood from the info on the net that i need to translate the pins to halui in main hal file. I see all the buttons and mpg in halmeter so its connected ok

Hi guys, I want to share my Spindle pendant button configuration based on the ruffle post about the MDI mode switch.
I added the toggle function to this button because I would like to use the 1/2 button to find the X1/2 or Y/2 of the current position that would be depend on the axis selector dial. Help me please with this new configuration, thanks in advance.

I'm having trouble getting my config to load with the xhc ini into added. Can't find the problem. please help

you have x y z c declared but no c axis setup , also it helps to place the xhc setup first in the ini
let me know if you still have problems , after rectifying

attached updated files , i have not checked them , so their maybe a typo or whatever

It would be more helpful if you would start linuxcnc in a terminal and
post the session transcript with exact error messages.

Your xhc_test.hal file has this line:

net spindle-manual-stop halui.spindle.stop

This line (probably created by pncconf) creates a signal (spindle-manual-stop)
that connects to pin halui.spindle.stop -- but the signal is _not_ used.

Your xhc_test.ini file has this line in the [XHC_HB04_BUTTONS] stanza:

half = halui.spindle.stop

This line specifies connecting the same pin (halui.spindle.stop) to a
pendant signal.

You can't connect a pin to two signals so you will get an error like:

Pin 'halui.spindle.stop' was already linked to signal 'spindle-manual-stop'
while executing
...

So, if this is the problem, delete unused signal(s) in the halfile.

also it helps to place the xhc setup first in the ini

i doubt this ever matters in a properly assembled inifile. If you can make a reproducible example in a sim config that demonstrates a problem, please make a complete bug report