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: "Jeff Hill" <johill@lanl.gov>
To: <pthomas@ligo-wa.caltech.edu>, <tech-talk@aps.anl.gov>
Date: Thu, 3 Mar 2011 09:27:06 -0700
> 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)? 

The threads in the server that manage incoming and outgoing messages run at
a relatively lower priority than, for example, the database. So, if some
other higher priority activity saturates the CPU the subscription updates
will stop. Fortunately, the ca client library will eventually (reference
EPICS_CA_CONN_TMO) conclude in that situation that beacons from the server
are suspended, and after testing the tcp circuit, disconnect the channel.
Furthermore, if database processing were also suspended due to cpu
saturation the same ca client initiated disconnect will occur.  

In the absence of cpu starvation there are of course many other software
related failures that need to be considered, with device driver failure
being of particular concern because the code there might or might not have
been tested on off-normal paths. The more commonly used components tend to
be less prone to failure due to more paths in the code being covered during
testing and normal operation. IOCs of course can also become compromised due
to hardware failure; for example, due to exposure to radiation.

Therefore, a design which relies on a heartbeat or a regular handshake with
the agent in the IOC might provide an extra level of protection if there is
a stronger requirement for knowing, in the ca client, if the agent is
incapacitated or inaccessible.

> 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 connection state update, subscription value update, subscription time
update, subscription alarm status update, and access rights state update
(all communicated by callback handlers) should be considered a baseline
level of protection, but a regular handshake with the agent in the IOC might
be needed for a higher level of protection depending on your application and
your tolerance for faults.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925


> -----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 3: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



References:
ca subscriptions, invalid pv pthomas

Navigate by Date:
Prev: Re: ca subscriptions, invalid pv pthomas
Next: RE: ca subscriptions, invalid pv Jeff Hill
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: RE: ca subscriptions, invalid pv Allison, Stephanie
Next: Strange asyn errors emmanuel_mayssat
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 ·