Experimental Physics and
Industrial Control System

Pete Jemian <[email protected]> · Fri, 18 Aug 2006 17:14:13 -0500

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.
-----------------------------------------------------------

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System