EPICS Controls 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  2020  2021  2022  2023  2024  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  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: ca subscriptions, invalid pv
From: "Jeff Hill" <[email protected]>
To: <[email protected]>, "'Andrew Johnson'" <[email protected]>
Cc: [email protected]
Date: Thu, 3 Mar 2011 09:58:16 -0700
> Thank you for your reply. I found the following in the channel access
> reference manual under the ca_create_subscription description:
> 
> If at any time after subscribing, read access to the specified process
> variable is lost, then the call back will be invoked immediately
> indicating that read access was lost via the status argument. When read
> access is restored normal event processing will resume starting always
> with at least one update indicating the current state of the channel.
> 
> Is there a list of all the possible values of the status argument and what
> they correspond to?

o The status field in "struct event_handler_args" will be one of the ECA_XXX
status codes in caerr.h. These error codes are also documented at the end of
the ca reference manual. The first consideration for the callback handler is
if this status code is, or isn't, ECA_NORMAL because if off-normal then the
pointer to the dbr type will be nill indicating that the data couldn?t be
obtained from the server. These error codes can also be converted to text,
vi ca_message ( status ),  for diagnostic messages. See also the doc under
ca_create_subscription() and the "function call interface guidelines" in the
reference manual.

o See the doc under ca_replace_access_rights_event() for a description of
the read/write access state currently communicated by that callback. This
callback is used by clients to track the current state of their access
rights.

o Clients can also call ca_read_access(chid) or ca_write_access(chid) at any
time to determine the current state of their access rights.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
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: [email protected] [mailto:[email protected]]
> On Behalf Of [email protected]
> Sent: Wednesday, March 02, 2011 5:56 PM
> To: Andrew Johnson
> Cc: [email protected]; [email protected]
> Subject: Re: ca subscriptions, invalid pv
> 
> Hi Andrew,
> 
> Thank you for your reply. I found the following in the channel access
> reference manual under the ca_create_subscription description:
> 
> If at any time after subscribing, read access to the specified process
> variable is lost, then the call back will be invoked immediately
> indicating that read access was lost via the status argument. When read
> access is restored normal event processing will resume starting always
> with at least one update indicating the current state of the channel.
> 
> Is there a list of all the possible values of the status argument and what
> they correspond to?
> 
> Thank you,
> Patrick
> 
> > Hi Patrick,
> >
> > On Wednesday 02 March 2011 16:45:19 [email protected] 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.
> >
> >



References:
ca subscriptions, invalid pv pthomas
Re: ca subscriptions, invalid pv Andrew Johnson
Re: ca subscriptions, invalid pv pthomas

Navigate by Date:
Prev: RE: ca subscriptions, invalid pv Jeff Hill
Next: Re: How to know if a PV is on a Soft IOC or not ? 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  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: 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  2020  2021  2022  2023  2024 
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 ·