Tim's message jostles my imagination.
Can your situation be condensed to a few particular
but different procedures involving the same set of records?
What you describe sounds just like many of the APS beam lines.
Maybe you would be best served by choosing from a library of
clients, each one tailored for its specific function.
(In APS sense, one client for XAFS, another specializes in
diffuse scattering, ... but all use records chosen from the
same beam line.)
Does that help?
Regards,
Pete
Tim Mooney wrote:
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.
--
----------------------------------------------------------
Pete R. Jemian, Ph.D. <[email protected]>
Beam line Controls and Data Acquisition, Group Leader
Advanced Photon Source, Argonne National Laboratory
Argonne, IL 60439 630 - 252 - 3189
-----------------------------------------------------------
Education is the one thing for which people
are willing to pay yet not receive.
-----------------------------------------------------------
- Replies:
- Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Bill Nolan
- 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
- Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Tim Mooney
- Navigate by Date:
- Prev:
Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Tim Mooney
- Next:
RE: looking for OSI version of epid record LYNCH, Damien
- 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. Tim Mooney
- Next:
Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Bill Nolan
- 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
|