Recommendation for XHC-HB04 pendant driver enhancement

More
24 Jul 2017 08:36 #96338 by hwylie
The driver correctly synthesizes pins (and associated HAL logic) for 'goto-zero', '=1/2' and 'zero' buttons, in addition to creating default pins (independent of rotary switch selection). 'xhc-hb04.tcl' creates nets as appropriate, but this leads for instance to simultaneous 'stop spindle' and 'half-x' commands (for the attached INI config), when the '=1/2' button is pressed with rotary switch in 'x' position, as 'watch' of the associated button pins confirms.

It is suggested that the driver should be enhanced to implement additional HAL logic to inhibit the three default (non-synthesized) button functions when the rotary switch is not in the 'off' position.

See also comments in stanza [XHC_HB04_BUTTONS] of attached INI file.
Attachments:

Please Log in or Create an account to join the conversation.

More
26 Jul 2017 07:26 #96448 by hwylie
With reference to the attached proposed (as yet untested) code fragment to replace lines 450 - 474 of linuxcnc/src/hal/user_comps/xhc-hb04.cc, the enhancement should require only minor code changes to the XHC-HB04 HAL User Component.

With para 7.5 of the LCNC Developer Manual in mind, guidance on protocol to follow for this minor functional enhancement will be appreciated. I do not find an existing github branch appropriate for validation of the proposal, nor do I have a github account.

Being registered on the LCNC Users mailing list, (but not Developers), this post will be mailed there too.

Existing code (with comments inserted) included in attached xhc-hb04 user_comp_lines_450_474.txt.
Attachments:

Please Log in or Create an account to join the conversation.

More
27 Jul 2017 02:20 #96525 by dgarrett
The changes you describe alter the pendant behavior in a way
that could affect existing user configurations in the field.

For example, a configuration that uses one (or more) of the
buttons allocated for synthesis of additional hal pins
according to the rotary switch position (zero,gotozero,half)
for any purpose with the *expectation* that the button is
active *independent* of the current rotary switch position.
would not work with employment of the suggested changes.

(The original intent of the derivative (synthesized) pins is
that they would be used *instead* of the base pin for
configurations that needed coordinate-specific button
actions. E.g., if a configuration uses synthesized pins
like xhc-hb04.zero-x,-y,-z,-a, it would likely not use the
base pin xhc-hb04.zero)

The suggested changes *could* be incorporated conditionally
with a new option to preserve backwards compatibility.
For instance:
[XHC_HB04_CONFIG]
ALTERNATE_SYNTHESIS_METHOD = 0|1
Omitting this setting should cause default (=0) behavior
that should be the same as in the current implementation.

Adding your change plus an added backwards-compatibility option
and with documentation for the master branch would necessitate
updates to the following files:

o) src/hal/user_comps/xhc-hb04.cc
(for the changes you describe plus a new option and
text for the --help commandline parameter to describe
the new option)
o) changes to the provided examples directory:
configs/sim/axis/xhc-hb04/README
configs/sim/axis/xhc-hb04/*.txt
configs/sim/axis/xhc-hb04/*.ini
configs/sim/axis/xhc-hb04/*.inc
o) docs/man/man1/xhc-hb04.1 (xhc-hb04 man page)
o) docs/src/getting-started/updating-linuxcnc.txt to
update instructions for changes that alter behavior


#############################################################
An alternate *local* solution.

Hal bit pins are already provided to indicate the position of the
rotary switch:
xhc-hb04.jog-enable-off
xhc-hb04.jog-enable-x
xhc-hb04.jog-enable-y
xhc-hb04.jog-enable-z
xhc-hb04.jog-enable-a
xhc-hb04.jog-enable-feed-override
xhc-hb04.jog-enable-spindle-override

Using these, the functionality you suggest is obtainable
with some additional hal logic that takes into account
the state of the rotary switch position.

For example, consider a configuraton using:
[XHC_HB04_BUTTONS]
...
zero   = halui.mdi-command-10
zero-x = halui.mdi-command-11
...

The connections made for these configuration items
by LIB:xhc-hb04.tcl are:
net pendant:zero   <= xhc-hb04.button-zero   => halui.mdi-command-10
net pendant:zero-x <= xhc-hb04.button-zero-x => halui.mdi-command-11
...

Making the zero button available only if the rotary switch
is in the off position (while the zero-x,y,z synthesized
buttons are active depending upon the rotary switch postion)
can be implemented with some additional hal logic using
these modified configuration items:
[XHC_HB04_BUTTONS]
...
#NOTUSED zero = halui.mdi-command-10
zero-x = halui.mdi-command-11
...
The additional hal logic is needed to condition the pin
for halui.mdi-command-10 so it is asserted iff the rotary
switch is in the off position. Since the xhc-hb04.cc file
creates a userspace component, this halfile must be executed
after userpace components are loaded. This can be done
(with the axis gui for instance) using a postgui halfile:
[HAL]
...
HALFILE = postgui.hal

Example file:
$ cat postgui.hal
loadrt and2 names=A1
addf   A1 servo-thread
net    sig1 <= xhc-hb04.jog.enable-off => A1.in0
net    sig2 <= xhc.hb04-button-zero    => A1.in1
net    sig3 <= A1.out                  => halui.mdi-command-10

#####################################################3


Excerpts from your ini file:
#goto-zero = halui.mdi-command-00
# Synthesized per-axis buttons for goto-zero button:
goto-zero-x = halui.mdi-command-08
goto-zero-y = halui.mdi-command-09
goto-zero-z = halui.mdi-command-10
...
half        = halui.spindle.stop
# Synthesized per-axis buttons for '=1/2" button:
half-x      = halui.mdi-command-04
half-y      = halui.mdi-command-05
half-z      = ""
...

Not using "goto-zero =" (by commenting it) out is
appropriate since you use goto-zero-x,y,z

Using "half=halui.spindle.stop" when you are also using
half-x,y,z seems inappropriate especially since there are
numerous buttons on the pendant that are unused and hence
available for connection to halui.spindle.stop.
The following user(s) said Thank You: hwylie

Please Log in or Create an account to join the conversation.

More
31 Jul 2017 10:21 #96741 by hwylie
The solution adopted applies the XHC-HB04 'mode' button to toggle between 'default' and 'alternate' modes, as described below.

Mode control over pendant functions has been limited in this implementation to inhibiting pendant non-synthesized buttons ('goto-zero', '=1/2' and 'zero') when 'alternate' mode is invoked - but more elaborate 'xhc-hb04_mode_comps.hal' and 'xhc-hb04_mode_nets.hal' implementations can further enrich pendant functionality.

Ideally, indication of mode in effect should be provided on the pendant LCD display. In the absence of XHC-HB04 documentation specifying bit assignment (other than bit 7 'inch' flag identified in 'xhc-hb04.cc) of FLAGS_BYTE mapping to pendant display, brief annunciation on LCNC GUI screen each time the mode is toggled, with floating message window 'Pendant default mode: non-synthesized buttons enabled' or 'Pendant alternate mode: non-synthesized buttons disabled', is appropriate.

Since a static GladeVCP or pyVCP window is not ideal for this purpose, a transient annunciation window launched by a dedicated HAL user component is considered the preferred approach. Is this the recommended method, and is Tkinter invocation in comp c-code appropriate to achieve this? Is there an existing comp illustrating such functionality?

Are there alternative methods to bind HAL (bit, or other) pin events to Python handlers, in the fashion of Python API linuxcnc.stat() methods - with the flexibility to get the state of any HAL pin in existence?

As a footnote, some anomalies were observed attempting the recommended POSTGUI_HALFILE implementation, associated with invocation of more than one postgui file, and HAL TWOPASS. The implementation as attached is modular, while the failure of 'POSTGUI_HALFILE = spindle_to_pyvcp.hal' to execute with 'TWOPASS = on' is reported under separate post (interim solution: halcmd creation of two missing nets).

Please Log in or Create an account to join the conversation.

More
31 Jul 2017 20:26 #96791 by dgarrett

Is this the recommended method, and is Tkinter
invocation in comp c-code appropriate to achieve this?
Is there an existing comp illustrating such
functionality?


There is no single recommended method but typically a
user-space process is used to poll hal pins and take
actions that can include a popup message.

The user-space program is commonly implemented with a
program for a scripting language that has a hal
interface(python,tcl). The program can be launched
automatically as 1) a loadusr command in a [HAL]HALFILE or
as 2) an [APPLICATIONS]APP item.

Refs:
linuxcnc.org/docs/devel/html/hal/basic-hal.html#_loadusr
linuxcnc.org/docs/devel/html/config/ini-...applications_section

As illustration, monitoring xhc-hb04 connectivity is
optionally included using:
[APPLICATIONS]
APP = monitor-xhc-hb04
This script detects loss of connections to the pendant
and issues a popup message when such losses occur.

A similar script could be used to monitor any hal
conditions. Scripts used for loadusr commands or APP=
items must be a) executable and b) located in the PATH
environment (or specified using a relative or absolute
path).

Creating multiple polling applications is likely to
use redundant code so one possibility is to modify
the system provided script (monitor-xhc-hb04) to
perform additional checks.

One way to do this is:
1) Copy the system-provided monitor-xhc-hb04 file to
your *local* configuration dirctory preserving its execution
settings.   The system file location for either
a RIP build environment or a deb install can be
found using:
     $ which monitor-xhc-hb04
2) Modify the *local* script as required to perform
additional monitoring and popups as required.
3) Invoke the *local* script by specifying its 
path relative to the *local* configuration directory:
[APPLICATIONS]
APP = ./monitor-xhc-hb04

If you prefer python scripting, another possibility for
the axis gui is to add functions to its polling loop.
To do this, one would develop a custom python script
and specify it with: a [DISPLAY]USER_COMMAND_FILE=
item. The script can define a user_live_update()
function that will be executed at the axis gui update
interval.

Ref:
linuxcnc.org/docs/devel/html/gui/axis.html#_user_command_file
The following user(s) said Thank You: hwylie

Please Log in or Create an account to join the conversation.

Time to create page: 0.129 seconds
Powered by Kunena Forum