Speaking as the author of PEM, I can say that this whole area of automation has lots of flavors. The sequencer in EPICS is more like a data-driven workflow engine. In other words, the presence of data on an "input" triggers the next step in the workflow. But, it's also unlike data-driven workflow in that many more transitions are implied in sequencer scripts (a finite state machine specification) than in an explicitly diagrammed workflow graph where the transitions are more constrained, typically.
PEM is really just an instrumented scripting language. You write a script (in Tcl) that describes a sequence of work you want done, and statements sprinkled about in that script allow a manager process to step through it like a debugger. There aren't really any optional transitions unless you explictly code them procedurally.
Your "high-level" atomic operations are typically scripted functions, with lots of internal, encapsulated logic. One way of graphically sequencing these sorts of things are workflow tools like Kepler, Taverna, BPEL, or even the DAGman (Directed Acyclic Graph manager) in Condor. Some of these tools support data-driven workflow, some are procedural workflow (with things like explicit conditional and looping logic). And like Ralph said, considering error handling adds a whole new dimension.
GDA is of the procedural, scripting variety, as it supports Jython scripts, although I wouldn't really consider it a "workflow engine" or state-machine.
By the way, Emmanuel, here at APS, we have a need to sequence exactly the sort of high-level functions you described. This time for the beamlines instead of the accelerator proper. I'm looking at things like Taverna, BPEL, Condor, PEM (or perhaps a Python-based reincarnation of it), GDA, EDNA, and other related projects.
But all of this is really above the level of EPICS. Perhaps we need a different mail group for this.
----- Original Message -----
From: Ralph Lange <[email protected]>
Date: Sunday, May 30, 2010 4:53 pm
Subject: Re: state machine programming
To: EPICS tech-talk <[email protected]>
[email protected] wrote:
Through exec() calls a state machine can call any program or script
written in any language on your system. You find that too low level?!
Could you explain your definition of high level in that context?
end_stations_protocol:
align sample with beam
detector_acquire_image
move_grid
rotate_sample
detector_acquire_image
[...]
each command is drag-and-dropped by the experimenter (not a programmer)
sequence can be changed by the experimenter function of what he
wants to do
He should be able to work independently of programmers
[...]
Of course, each of those states can be further broken down and later
refined
(I can easily see a state machine with 500+ states)
interpreted languages are better, no compilation needed
+ you can program a sequence on the fly (no downtime required)
Ahh... now I can see what you are trying to achieve.
These are not the usual finite state machines, though, and the
pluggable
parts are not states (as the term is used in EPICS context).
The sequencer is not the right tool to do this, neither probably are
the
FSM record or the Qt4 thing you were mentioning.
You are looking for a generic script execution engine for an
interpreted
language, with (possibly) a graphical interface. The trickiest part of
these things is getting the exception/error handling right, with the
different options of ignoring vs. instant correcting vs. fallback vs.
safe state transition. To sucessfully do that, state machine like
behavior will be part of the solution, of course.
The closest thing within the EPICS context (that I know of) is the PEM
system you mentioned [1], used at the APS for their scripted operation
procedures. It almost looks like what you described in your last mail
-
I don't know implementation details or recent developments, though.
Other places to look would be the high level app frameworks: XAL and
GDA
might have interfaces that allow such kind of hierarchical script
snippeting. Again: I would see the error handling always being the
hard-to-get-right and crucial part of these engines.
Good luck!
Ralph
[1]
http://www.aps.anl.gov/Accelerator_Systems_Division/Operations_Analysis/manuals/APSPEM/APSPEM4.html
