Experimental Physics and
Industrial Control System

Bill Nolan <[email protected]> · 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.
>>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System