Experimental Physics and Industrial Control System

Hi Andrew,

On Tuesday 10 May 2011 19:29:17 Andrew C. Starritt wrote:
> 
> As part of the "ca.py - Throws error - workaround" thread there was some
> discussion whether a CA client should call ca_clear_subscription when it
> detects that a server has disconnected and presumably re-subscribe when
> the server re-connects.
> 
> Although the CA library automatically maintains the subscription, wouldn't
> it be better that when the PV re-connects, the client should do a ca_get
> (or ca_get_array or ca_get_array_callback) and a new
>  ca_create_subscription.

It's going to be quicker if you don't do that; the client library has already 
stored all of the information it needs to reconnect your subscription, and if 
you tear it down and rebuild it every time it will have to free and then 
reallocate memory for that internal storage.  Not a biggie, but it all takes 
resources and a little bit of CPU time.

> I would do this because the nature of a PV might have changed and a new
> ca_get would ensure that the client has the latest associated data
> (e.g. precision, EGU, enumeration values), and a new subscription because
> the field type and/or number of elements may have changed as well.

In R3.14.11 we introduced a new DBE_PROPERTY event subscription type.  The 
intention is that a client will use this to subscribe to a channel for which 
it wants to know metadata such as EGU, precision, ENUM strings etc.  The IOC 
currently only generates DBE_PROPERTY events at runtime for the mbbo and mbbi 
records when there is a change to the ENUM strings, but eventually this will 
expand.  This subscription replaces that single ca_get() of the extended DBR 
type that we currently do on connection, because the client will always be 
sent one monitor event of this type after a connection is (re)made.  This 
should simplify the client code slightly.

Of course it doesn't really help if the data type of the PV changes and you 
really want to subscribe using the channels native type, but that will require 
you to do more work in the client anyway and in practice is pretty rare 
(sufficiently so that I think there is still be a bug in the IOC's dbCa link 
handling if a link target changes type).  Unless you are transferring large 
arrays I would just recommend subscribing using the data type that you want 
the result in and let the library take care of the data conversions.

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

Disconnected PVs Andrew C. Starritt

Navigate by Date:

Prev: RE: asynPortDriver callbacks to I/O Intr, how to propagate an error? Mark Rivers

Next: Area Detector Szalata, Zenon M.

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: Disconnected PVs Matt Newville

Next: asynPortDriver callbacks to I/O Intr, how to propagate an error? Angus Gratton

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