Experimental Physics and
Industrial Control System

Andreas Luedeke <[email protected]> · Fri, 06 Sep 2002 18:06:15 +0200

If you're really sure you need this feature, then there's an easy solution:

You can corrupt the record name in the process database.
To "disconnect" the PV "myPV" just generate the script

a=dbNameToAddr("myPV")
**a='@'

and run it on your IOC.

The channel will be invisible for channel access.
If you provide the same channel name now by
another IOC, all applications will use this new channel.

I think that's what you've wanted. You can even write a small
IOC function for a subroutine record that reads a channel list
and enables or disables those channels on the IOC.
It's even reversible: if you remember the address "a" and it's
original content, you can set it back to the old value and the PV
is accessible on the old IOC again. For the example just write

**a='m'

I guess Ralph thought of that solution when he started saying:
"Wrrrnnnrrrlll ..."
:-)

Cheers
Andreas

[email protected] wrote:

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

--
Dr. Andreas Luedeke, SLS Operations Manager, Tel:+41-56-3104002
mailto:[email protected], http://people.web.psi.ch/luedeke

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System