As discussed on #emc-devel, this set of patches lets halrun and emc run
.tcl files to set up the hal environment.
The halcmd language is not bad, but it is limited. Often we've made
sacrifices of clarity or succinctness in inifiles in order to cater to
these limitations.
For instance, consider 'stepgen headroom'. Software stepgen still runs
best with an acceleration constraint that is "a bit higher" than the one
used by the motion planner. So we force inifiles to have a manually
calculated value:
[AXIS_0]
MAXACCEL = 10.0
STEPGEN_MAXACCEL = 10.5
What would be preferable is the ability to do calculations in the hal
command language. With this patchset, you can:
setp stepgen.0.maxaccel $AXIS_0(MAXACCEL)*1.05
and skip the STEPGEN_MAXACCEL inifile item altogether.
Another thing you gain is looping and testing. Right now we have
"core_sim" and "core_sim9" hal files. They mostly differ because of the
requirement to connect more or fewer axes. The following tcl code
should work for any combination of axes in a trivkins machine, or at
least it's a step in the right direction:
# Create position, velocity and acceleration signals for each axis
set ddt 0
foreach axis {X Y Z A B C U V W} axno {0 1 2 3 4 5 6 7 8} {
# 'list pin' returns an empty list if the pin doesn't exist
if {[hal list pin axis.$axno.motor-pos-cmd] == {}} { continue }
net ${axis}pos axis.$axno.motor-pos-cmd => axis.$axno.motor-pos-fb \
=> ddt.$ddt.in
net ${axis}vel <= ddt.$ddt.out
incr ddt
net ${axis}vel => ddt.$ddt.in
net ${axis}acc <= ddt.$ddt.out
incr ddt
}
To use this functionality, just use the extension .tcl instead of .hal
for hal files. This is understood by emc and halrun.
What's the price? The main one is syntax incompatability between halcmd
and haltcl: inifile values are accessed using Tcl variable syntax,
$SECTION(ITEM) rather than halcmd syntax [SECTION]ITEM. Second, a few
halcmd commands such as 'gets' and 'list' conflict with Tcl builtin
commands; in these cases, you have to write 'hal gets' instead. These
can both be fixed with a simple sed script.
haltcl also doesn't currently have an interactive mode (as far as I can
tell there's no way to evaluate an initial tcl script and then enter
interactive mode, which is what is required for this). If it did, it
would be worse than halcmd, because we've put a lot of work into halcmd
interactive completion, and because halcmd uses readline by default.
For these two reasons, halcmd and its syntax would also be retained
indefinitely.
Why did I choose tcl? If I limit myself to languages that are already
used in emc, my main other choice is Python. But Python uses a
function-call syntax rather than a shell-like syntax; it's not 90%
halcmd-compatible like tcl is. A third choice is to add flow control
and expression evaluation to halcmd, which is a much bigger time
investment than this work was. The fourth choice is to use /bin/sh or
bin/bash as the command language, but the bourne shell doesn't have
built-in floating-point arithmetic, which is one of the desirable
features.
I conveniently neglected to show one thing I am dissatisfied about. In
'sets' and 'setp' the value argument is implicitly treated as an
expression. But in other contexts, such as 'loadrt', you have to write
[expr {}], e.g.,
loadrt motion base_period=[expr {500000000/$(TRAJ)MAX_PULSE_RATE}] ...
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
