Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: ca subscriptions, invalid pv
From: Andrew Johnson <anj@aps.anl.gov>
To: pthomas@ligo-wa.caltech.edu
Cc: tech-talk@aps.anl.gov
Date: Wed, 2 Mar 2011 17:41:56 -0600
Hi Patrick,

On Wednesday 02 March 2011 16:45:19 pthomas@ligo-wa.caltech.edu wrote:
> 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?

The only thing I can think of would be access security, which can change 
dynamically so a channel you once were able to see is blocked, or vice versa.  
Your client code can ask to be notified about such changes using the CA API 
routine ca_replace_access_rights_event(), or can ask about its current access 
rights for a channel using ca_read_access() and ca_write_access().  I seem to 
recall that the initial access rights data for a channel get sent /after/ the 
main channel connection data (so appear after the connection callback) but 
before the initial value event, but I might be wrong about that.

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

Not quite sure what you're after there, do you want the IOC to be able to 
detect when an external program has disconnected, or are you just asking how a 
CA client can make a record go into an alarm state?

The first one is possible using a subroutine record subroutine to look at the 
prec->mlis.count field; if there are *no* CA clients monitoring *any* fields 
of that subroutine record the count will be zero.  If course this could be a 
somewhat fragile mechanism, but you might be able to make it do what you need.

HTH,

- Andrew
-- 
An error is only a mistake if you don't learn from it.
When you learn something from it, it becomes a lesson.


Replies:
Re: ca subscriptions, invalid pv pthomas
References:
ca subscriptions, invalid pv pthomas

Navigate by Date:
Prev: ca subscriptions, invalid pv pthomas
Next: RE: ca subscriptions, invalid pv Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: ca subscriptions, invalid pv pthomas
Next: Re: ca subscriptions, invalid pv pthomas
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·