Experimental Physics and
Industrial Control System

Bill Nolan wrote:
> What I am actually looking to do is well suited to SNL,
>     I am scheduling the path a product will take through a production
> line, starting with input bins and ending in output bins.
>     Each step in the production functions independataly and is
> controlled by some form of low level controller, in some cases that is
> an EPICS iOC, but in most cases it it a vendor supplied software package
> with high level hooks, typically a stringout and two Bi/Bo records.
>
>     If the process was static or semi static I could schedule it using
> SNL and have no issues at all, But the process is VERY dynamic, changing
> as much as 3 time in an 8hr day. So I need a way to control the sequence
> of events that is easy and rapid to program.
>
>     I have looked at using SEQ or SSEQ records, but the any way i have
> been able to think of to model the process has be requiring a new
> instance of the seq record for each piece going through the system. And
> well, until we get a dynamic database loader that is out.
>
>     I was considering possibly writing a GUI State editor and doing some
> sort of compile on the fly state programs, but that seems like, well, a
> lot of work.
>
>     The real killer is that the only thing that is fixed in the entire
> system are the records in my database, how they connect and in what
> order is entirely dynamic.

I'm not sure what a record corresponds with in this case, a process
to be performed, or a product (state) to be handled.  But let me just
steam on ahead anyway, and spew some possibly ignorant ideas. (If I say
something hilariously stupid, be sure and tell me.  I could use a good
laugh.)  My main point will be that links between records need not be
regarded as fundamentally different from other kinds of record fields.
They're just data that can be read and written.

Reprogramming every few hours sounds like a job for a client.
Suppose you configure your database for one particular sort of
product, and use a parameter save tool (e.g., casave) to save all the
programmed fields (all the links between records, and all the constants
that specify the manner in which each operation is to be done) in a file.
Then any time you want to configure the line for that sort of product,
you use carestore to write the links and parameters back.  You could
have many different setups in this way, and change from one to another
in seconds.

What you can't do with this simplistic approach, of course, is
to have several different kinds of products simultaneously in the
production line.

--
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab

Replies:

Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Pete Jemian

References:

Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Bill Nolan

Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Tim Mooney

Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Bill Nolan

Navigate by Date:

Prev: Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Bill Nolan

Next: Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Pete Jemian

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: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Bill Nolan

Next: Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Pete Jemian

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