RE: ca subscriptions, invalid pv

["Allison, Stephanie" <saa@slac.stanford.edu>]

Hi Patrick,

> 2. How do you usually deal with setting a pv invalid if the data is being
> put to it from an external program (ie, not device support) and that
> program fails?

We ask that the other program also write to a heartbeat PV on a periodic basis (ie, 1 sec to 10 sec).  Then logic is added to check the heartbeat and a status PV is updated when it starts/stops.  Currently, we do NOT set the data PVs to invalid but this could be done based on the status PV since the status PV goes to an INVALID state when the heartbeat stops.  And the ye-olde SDIS kluge can be used to force processing/maximize severity of the data PVs - see this tech-talk message:

http://www.aps.anl.gov/epics/tech-talk/2009/msg00691.php

Stephanie Allison

> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf
> Of pthomas@ligo-wa.caltech.edu
> Sent: Wednesday, March 02, 2011 2:45 PM
> To: tech-talk@aps.anl.gov
> Subject: ca subscriptions, invalid pv
> 
> Hi,
> 
> Two questions:
> 
> 1. If a channel is connected or reconnects, and a call to
> ca_create_subscription succeeds or has previously succeeded, is there
> anything else that could go wrong on the ioc side that might cause the
> channel not to be monitored (other than the channel disconnecting)? And if
> so, is there a way to tell from the client side? Do I have to wait for the
> event handler to be called before I can trust that everything is working?
> 
> 2. How do you usually deal with setting a pv invalid if the data is being
> put to it from an external program (ie, not device support) and that
> program fails? Do you write device support for the ioc hosting the pv, and
> use it to get the value and a status update from the program? Is there a
> more preferred method?
> 
> Thank you,
> Patrick