Subject: |
Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. |
From: |
Bill Nolan <[email protected]> |
To: |
Tech-Talk <[email protected]> |
Date: |
Mon, 21 Aug 2006 10:06:37 -0500 |
Thanks,
The combination of a library of clients and making good use of CA
save/Restore looks like it will give the functionality I need.
--Bill
Pete Jemian wrote:
>
> 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.
>>
>
- 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
- Re: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Pete Jemian
- Navigate by Date:
- Prev:
Re: looking for OSI version of epid record Tim Mooney
- Next:
Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
- 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. Pete Jemian
- Next:
RE: Dev Asyn and Cygwin/Win IOCs , Modbus and scheduling. Mark Rivers
- 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
|