EPICS Controls 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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: state machine programming
From: "Dalesio, Leo" <[email protected]>
To: "Ralph Lange" <[email protected]>, "EPICS tech-talk" <[email protected]>
Date: Sun, 30 May 2010 23:46:41 -0400
Title: RE: state machine programming


>>    
>
> 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)
>  
GDA from Diamond and Daresbury, would be worth a look. This appears to be a standard issue with experimental beam lines. But as you say, the problem is hierarchical. An SNL program may represent some function that is always done the same and has a robust implementation - such as align sample with beam.

The other thing to consider is execution time. Many experiments are moving to on the fly scan - so scripts set up the parameters, but the motion and image acquisition are too fast to be sitting across the network or even on the IOC. We are seeing requirements to set up the motion profile, set the conditions for triggering acquisition, and start the acquisition.

Ralph already mentioned robustness. Scripting tends not to have much on the way of robustness - tests for network outages, verify that outputs were actually set all the way to the hardware, setpoints and outputs stay matched etc...

Is there a good document on PEM? Where is it being used?

Bob


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