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.
>
>
- Replies:
- RE: ca subscriptions, invalid pv Jeff Hill
- References:
- ca subscriptions, invalid pv pthomas
- Re: ca subscriptions, invalid pv Andrew Johnson
- Navigate by Date:
- Prev:
RE: ca subscriptions, invalid pv Allison, Stephanie
- 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
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: ca subscriptions, invalid pv Andrew Johnson
- 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
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|