Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: state machine programming
From: quock <quock@aps.anl.gov>
To: Claude Saunders <saunders@aps.anl.gov>, epics Techtalk <tech-talk@aps.anl.gov>
Date: Sun, 30 May 2010 20:28:40 -0500
Claude,

Is the PEM that you are referring to the same thing as SDDS that the OAG uses at APS? Confused about terminology.

Thanks,

Debby

Claude Saunders wrote:
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 <Ralph.Lange@bessy.de> Date: Sunday, May 30, 2010 4:53 pm Subject: Re: state machine programming To: EPICS tech-talk <tech-talk@aps.anl.gov>

emmanuel_mayssat@lynceantech.com 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


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
Re: state machine programming Claude Saunders

Navigate by Date:
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  <20102011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: state machine programming Claude Saunders
Next: RE: state machine programming Dalesio, Leo
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·