Experimental Physics and
Industrial Control System

[email protected] (Karen J. Coulter) · Thu, 21 Apr 94 13:32:57 EDT

email from Peregrine:
>> 
>> Marty Kraimer writes,
>> 
>> > We (accelerator controls) could define records to link to all accelerator PVs
>> > needed by the users. A user connects to one of these records rather than to
>> > the actual IOC containing the PV to be monitored/controlled. No matter how
>> > many users connect to the beam line ioc, the number of channel access
>> > clients connected to the rest of the control network will not change. The
>> 
>> 	We think this is great idea and want to bring up a related issue:
>> 
>> 	How do we implement this _without_ doubling our PV name space? This
>> seems to require that the gateway IOC have its own name space that reflects
>> the PV names is use by the real-time IOCs. If there were a way of 
>> rendering this transparent OR by allowing CA to include the IOC name/address
>> in the PV name this could reduce the maintenance issues.
>> 
>> Aloha,
>> 	Peregrine
>> 

Earlier I sent some email to Marty Kraimer that noted some potential issues
with his specific solution to use the ID IOCs at APS to provide machine info
to the beamline users.  That message is included below.  Other questions have
also come to mind recently.  Isn't it preferable to keep outside traffic off
of the machine control network?  The current proposal has multiple copies of
information on different IOCs; network bandwidth could be eaten up by
sending redundant info to many users.  Plus, somewhere something has to enforce
the rule that users not try to talk to other machine IOCs.  My uderstanding is
that the new CA security will do this, but the burden will still be on the 
machine IOCs themselves.  The most attractive part of this scheme, however, 
is that there are definite advantages to providing this data to users via CA.  

What about the possibility of providing a data server machine which collects 
all of the data of interest (one copy in one place), and provides it to an 
outside network?  For instance, suppose this data server were a Sun/HP etc.  
It could have two network interfaces, one to the machine network, and one to 
the 'outside.'  Some sort of reasonable spreadsheet client (or other data 
management tool) could caGet the machine data, and caPut it to an IOC 
on the outside network.  This would look transparent to the users and the
PV name space would not have to be doubled.  User's could define a database
that scans or registers monitors for the machine parameters and never think 
about it again. This data server might lend itself to other data access methods.
A reflective memory module could be provided in this server, and any user 
who wanted to make the investment could connect to the reflective memory 
highway, if this turned out to be a useful thing to do.  In addition to using 
CA to get the data from an IOC, users could use NSF/AFS or use RPC clients 
(some commercial products?) to get the data directly from the server.  
Better yet, if this data server could also be a CA server, a separate crate 
wouldn't be necessary.  I haven't thought about all the implications of this 
approach,  it could end up being a bottleneck for instance.  But at first 
glance it appears to be more flexible and more expandable than relying on 
machine control IOCs themselves.  Plus it eliminates any burden for supplying 
info to outside entities from the machine control IOCs.

Karen

----- Begin Included Message -----

Marty,

> I can think of an easy out. For each sector there is an IOC for control of the beam
> line insertion device. This beam line IOC is managed by accelerator controls
> not by the beam line users. It seems natural to use this IOC as a concentrator.
> We (accelerator controls) could define records to link to all accelerator PVs
> needed by the users. A user connects to one of these records rather than to
> the actual IOC containing the PV to be monitored/controlled. No matter how
> many users connect to the beam line ioc, the number of channel access
> clients connected to the rest of the control network will not change. The
> worst thing the users could do is cause problems with their beam line ioc.
> With proper design this should only affect them and not the users of other
> beam lines.
> 

This may not be a bad idea, but I wanted to point out some POTENTIAL problems
to think about.  The IDs may not be completely independent of each other and
other accelerator components.  This is the goal, but it's possible that the
number of IDs which can be moved at one time might be limited, and it's possible
(likely?) that certain accelerator components will require a somewhat tight
feedback loop with the ID ioc when the gap is being set.  This ioc may be used
for running the ID Vacuum Chamber controls (pumps RGAs etc).  Also, this ioc
will be responsible for MONITORING the status of the interlocks for the ID
and the ID vacuum chamber, two systems which can also affect the operation of
the machine.  Be careful when assuming that this will be an underworked (likely)
and completely independent (not? likely) ioc for the beamlines.  It's probably
a reasonable thing to do, but it does require some very careful consideration,
and some things may remain unknown until commissioning of the storage ring
with all IDs (only 5 in 1995) in place.  As the IDs become more complicated,
(elliptical wigglers, superconducting devices?) the ioc may not be available
for such general support.

Karen

----- End Included Message -----

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System