EPICS Home

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: Disconnected PVs
From: Matt Newville <[email protected]>
To: "Andrew C. Starritt" <[email protected]>
Cc: EPICS Tech Talk <[email protected]>
Date: Tue, 10 May 2011 21:40:22 -0500
Hi Andrew,

I think one counter-argument could go like this:

   If you have a client program that keeps "Fat PV" objects that
   are meant to maintain such "associated data", then you can
   probably afford to add a connection callback to that object.
   When a connection is re-established, the associated data
   could be re-fetched in the connection callback.  That would
   avoid having the client explicitly disconnect from a dead
   server (assuming this would fully work), and then somehow
   know that it should re-connect when the server returns to life.

It turns out that PV objects from PyEpics (where this topic started)
would qualify as "Fat PVs", and do have an internal connection
callback.  On successful connection/re-connection, this does
automatically set internal variables for count, type, host, and
read/write access, but not precision, units or names of enum states.

I don't have a strong opinion about the preferred behavior, just
thought I'd point out an alternative.

Cheers,

--Matt Newville


On Tue, May 10, 2011 at 7:29 PM, Andrew C. Starritt
<[email protected]> wrote:
> Hi all,
>
> 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.
>
> 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.
>
> Although such PV changes are relatively rare, they do occur.
>
> Any counter arguments?
>
> --
> Andrew Starritt | Principal Controls Engineer | Australian Synchrotron
> p: (03) 8540 4164 | f: (03) 8540 4200
> [email protected] | www.synchrotron.org.au
> 800 Blackburn Road, Clayton, Victoria 3168
>
>
> <br>This message and any attachments may contain proprietary or confidential information. If you are not the intended recipient or you received the message in error, you must not use, copy or distribute the message. Please notify the sender immediately and destroy the original message. Thank you.
>
>


References:
Disconnected PVs Andrew C. Starritt

Navigate by Date:
Prev: Calculation in SNL/SEQ liuping
Next: Re: Calculation in SNL/SEQ Chestnut, Ronald P.
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: Disconnected PVs Andrew C. Starritt
Next: Re: Disconnected PVs Andrew Johnson
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