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