Experimental Physics and
Industrial Control System

[email protected] (Deb Kerstiens) · Mon, 3 Feb 97 12:22:18 MST

Tim wrote:
> 
> re...
> 
> > If we're going to add a scripting language as an important part of EPICS, I'd
> > like to see at least some passing thought given to other possible uses of
> > such a language.  For instance, at the user interface, scripts might be
> > invoked from within a DM screen (and scripts written by others than EPICS
> > gurus).
> 
> I'm real glad to hear someone else say this.  We could take a lot of
> trivial calculations out of the database if our display managers had
> even a *little* smarts.  We should be able to define a widget whose
> value is the result of a script.  In fact, we should allow any widget
> to have its value determined in this way, and also let the end user
> write scripts.  (Yeah, I know: "performance, performance, performance",
> but unscripted widgets can still be fast, and it's truly stupid to have
> to put calculations in the database, where they affect *real-time*
> performance, just because the display manager can't do simple
> arithmetic.)

Yes, many of us would love to have some mechanism besides asding database
records for data transformation, especially trivial calculations.  Dm now 
supports conversions for monitor-type objects with the same functionality
as the calc record.  Right now it's limited to converting the value of
the "channel" defined for the object, i.e. no multiple channel calculations.
I've been planning to extend this to support user-defined calculations for
both monitors and controllers.  One thought was to let the users build in 
their own functionality much in the same way we now add records to EPICS.
For simple calculations, having the built-in calc be part of dm still seems 
reasonable.  But we may want to look at using scripts as a flexible way to
let users extend and customize such capability.

> 
> If we *are* going to add a scripting language as an important part of
> EPICS, it should be something we might one day run on the IOC as
> well, to supplement existing run-time-programmable calculations
> performed by the calc & wait records.
> 
> > Perl is a possibility here, but I think TCL is probably a better choice.
> > However, I'd like to propose Python as an even better choice.
> 
> In my opinion, neither Perl not tcl are appropriate languages for this
> purpose because their syntaxes are just too weird and too strewn with
> subtle gotchas for casual use.  What I've seen of Python looks very
> good (except for that stupid business of using indentation alone to do
> what C does with curly braces.)
> 
> By the way, I've also looked at Rexx and at ScriptEase
> (http://www.nombas.com), trying to find a good embedded language for
> end users.  ScriptEase--a 'C' (subset) interpreter--looks good as an
> embedded language, and it's available for a variety of platforms, but
> it's not free.
> 
> Tim Mooney
> 

I don't have enough personal experience to vote for Perl or Python or any
other just yet, but I'm hoping we'll keep this dialog going.  Maybe we
should include it as a topic at the next collaboration meeting??

Deb

**********************************************************************
Deb Kerstiens		[email protected]
Phone			(505)667-3396
LANL AOT-8,MSH820	PO Box 1663, Los Alamos, NM. 87545 
**********************************************************************

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System