Experimental Physics and
Industrial Control System

Ned Arnold <nda> · Thu, 5 Sep 2002 08:10:07 -0500 (CDT)

Another idea ...

A clever nameserver might be able to be told where the "real" channel is
located. This would, of course, require all clients to use this nameserver.

	Ned

> Hi Susanna,
> 
> general answer: No.
> 
> EPICS (in this case: Channel Access) does not provide any hot swap or
> fall back capabilities based on redundant channels. The mere existence
> of multiple channels with the same name will create exceptions (usually
> seen as error messages) at the client side. Redundant channels are on
> the wish list for Channel Access, somewhere in the upper half of the
> middle third, I guess. (NB: Things on the CA wish list can be raised in
> priority by generous donations of manpower to EPICS core development.)
> 
> Specific answer: Wrrrnnnrrrlll ... still no.
> 
> You can stop records from processing by disabling them. But this won't
> touch their existence, so CA would still see them.
> 
> You can put up CA access security to have noone read nor write access to
> the channels. But still CA will see the name and create exceptions.
> 
> You can set EPICS_CA_ADDR_LIST on the client side so that a client only
> sees the IOC where the real hardware is. This works fine, but as long as
> there are other channels on the "other" IOC that the client also wants to
> see, no chance.
> 
> You could of course introduce an additional set of soft records with the
> generic channel name and have two sets of hardware related records with
> different names. The OUT and INP links of the generic record layer would
> point to the hardware side records that are currently in use. In that
> case you would get a performance hit by adding another record layer
> _and_ an additional CA layer (the generic records reside on one IOC and
> have to use CA to get to the hardware related records in at least one of
> the two locations).
> 
> So ...
> 
> Splitting the databases to move the channels that are connected to your
> hardware into a separate db file and then commenting / uncommenting the
> dbLoadRecord calls in the startup command when rebooting the IOCs seems
> the only reasonable way to handle this situation.
> 
> Ralph
> 
> >>>>> "Susanna" == Susanna Jacobson <[email protected]> writes:
> 
>   > Hi Folks,
>   > Here at the ALS, we are making a transition from an older
>   > system to a newer one over several years, one device or
>   > subsystem at a time.
> 
>   > We want to be able to turn off one or more channels in the
>   > older IOC, and then turn them on in the newer IOC, without
>   > having to rebuild .db files for the two IOCs.  That is,
>   > when a hardware connection is moved to the new sys from the
>   > old, the associated EPICS records appear to move as well.
>   > (Although in fact the same record is in both databases.)
> 
>   > Has anyone else done something like this with EPICS records?  
>   > Is it possible?

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System