Experimental Physics and Industrial Control System
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
- Replies:
- Re: state machine programming quock
- References:
- state machine programming emmanuel_mayssat
- Re: state machine programming Ben Franksen
- Re: state machine programming emmanuel_mayssat
- Re: state machine programming Ralph Lange
- Re: state machine programming emmanuel_mayssat
- Re: state machine programming Ralph Lange
- Navigate by Date:
- Prev:
Re: state machine programming emmanuel_mayssat
- Next:
Re: state machine programming Ralph Lange
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: state machine programming Ralph Lange
- Next:
Re: state machine programming quock
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024