XHC-HB04 wireless MPG pendant HAL module

Hi.
Pedant acc. jogg is a great feature (2.7.0) but i have some comments after testing it, Some of them were already mentioned.

1) After turning on my CNC machine i must always turn HB04, and switch rotary button (XYZ../Off). If i don't do this machine will crash on homing sequence ( acceleration values). There is a problem with default PIN state. It looks like that there is no procedure to verify the status right after you turn the machine (LinuxCNC).
2) Jog ON (rotary switch to X or Y...) should have not any impact (ACC) on running program. So in my opinion HB04 acceleration should work only when wheel is turning (count impulses). Now i must always remember to turn off JOG when i have to put away my HB04.
3) HB04 ACC configuration shouldn't impact on keyboard Jog (add.2)
4) And last, Go to ZERO still don't work on HB04 like manual and sample configuration says (2.6.X and 2.7.0). I saw in this thread what modifications must be carried out, but maybe I did something wrong.

Anyway,...
GREAT WORK and Thank you

Pedant acc. jogg is a great feature (2.7.0) but i have some comments after
testing it, Some of them were already mentioned.

A commit based on a patch mentioned earlier in this thread
addresses unexpected keyboard jogging behavior (unaltered accels)
when the pendant goes to sleep (typically after about 40 seconds).

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

If you are using a rip (run-in-place) build you must update git and rebuild.
If you are using a deb install, you must wget a deb from the buildbot
that includes this patch. You can wget a deb from:
buildbot.linuxcnc.org/dists/

I cannot reproduce any of the anomalies you describe using any of the
sim configs provided.

So please update your linuxcnc install, then test using one of
the provided sim configs and provide details on the steps required
to reproduce unexpected behavior.

The sim configs are available through the standard linuxcnc config picker:
Sample Configurations/sim/axis/xhc-hb04/xhc-hb4-layout1.ini
Sample Configurations/sim/axis/xhc-hb04/xhc-hb4-layout2.ini
Sample Configurations/sim/axis/xhc-hb04/xhc-hb4-layout2_mm.ini

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)