Experimental Physics and Industrial Control System

> While you're responding on this subject could you definitively answer
> Micheal's original questions, which were:

> > Firstly, is it possible for the element count of a channel to change
while
> > the channel is connected?  I'm thinking in particular of the case when
> > using camonitor (well, ok, I mean ca_create_subscription()) to monitor a
> > waveform PV.  Each event_handler callback is informed of the dbr count -
> > but as far as I can tell, it's always the maximum waveform size, even if
> > NORD is smaller.

Current behavior:
1) If the subscription request specifies a nonzero element count, then CA
always returns exactly the number of elements that the client application
requested, and zero pads if there are currently less elements available than
requested. The subscription request is rejected by the client library, if
the channel is currently connected, and the subscription request specifies
an element count greater than the element count received from the server
when the channel connects.
2) If the subscription request occurs before the channel connects and it
specifies an element count of zero, then CA always returns exactly the
element count that the client library received from the server when the
channel connects, and zero pads if there are currently less elements
available than requested.

> > Is the fact that the update size doesn't change, 
> > ca_element_count() always
> > reports the NELM, and subscribing with zero count gets the full
wavelength,
> > is this restriction fundamental to channel access, a limitation of the
> > channel access server, or just something that hasn't been implemented in
> > the waveform record?  This question becomes more interesting as we use
> > waveform records for large images!

The current behavior is partly resulting from a desire for a clear, concise,
safe, and consistent api design. There was a desire for the core behavior of
ca_get, ca_get_callback, and ca_create_subscription to all be consistent. It
would be unsafe, for example, for the number of elements returned by ca_get
to not match the number of elements requested by the client application, and
the other two were implemented consistent with ca_get. Once we ended up with
that behavior then it's not easy to change now because of a desire to remain
backwards compatible.

If the database interfaces provided an efficient mechanism for querying the
element count then it would be safe to conclude that the restrictions
presented at CA interfaces are imposed solely by code within CA.

Near-term:
Nevertheless, if one is slightly cavalier about backwards compatibility then
we could change the behavior when subscribing, or calling ca_get_callback,
and specifying zero elements to mean "return the current number of
elements". The behavior would also be modified to not change if the
subscription request is made before, or after, when the channel connects (as
it does now). That would probably be a safe conservative option which
provides important new functionality, and probably breaks very few if any
legacy clients.

Long Term:
I am proposing that client applications specify some complete set, or
subset, of the hypercube slice that they desire. If a bound (a single
dimension's bound) on the slice is left unspecified, then they would receive
the entire extent of the array (currently occupied) for that bound.

I will reflect questions about the exact behavior of the local database
links back to Andrew :-)

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


> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Monday, October 05, 2009 10:20 AM
> To: Jeff Hill; [email protected]
> Cc: [email protected]
> Subject: Re: Channel access dynamic array subscription update element
> count
> 
> Jeff,
> 
> While you're responding on this subject could you definitively answer
> Micheal's original questions, which were:
> 
> > Firstly, is it possible for the element count of a channel to change
> while
> > the channel is connected?  I'm thinking in particular of the case when
> > using camonitor (well, ok, I mean ca_create_subscription()) to monitor a
> > waveform PV.  Each event_handler callback is informed of the dbr count -
> -
> > but as far as I can tell, it's always the maximum waveform size, even if
> > NORD is smaller.
> 
> > Is the fact that the update size doesn't change, ca_element_count()
> always
> > reports the NELM, and subscribing with zero count gets the full
> wavelength,
> > is this restriction fundamental to channel access, a limitation of the
> > channel access server, or just something that hasn't been implemented in
> > the waveform record?  This question becomes more interesting as we use
> > waveform records for large images!
> 
> Thanks,
> 
> - Andrew
> --
> The best FOSS code is written to be read by other humans -- Harald Welte

References:

Channel access and ca_element_count michael.abbott

RE: Channel access and ca_element_count Jeff Hill

RE: Channel access dynamic array subscription update element count Jeff Hill

Re: Channel access dynamic array subscription update element count Andrew Johnson

Navigate by Date:

Prev: Re: Channel access and ca_element_count Benjamin Franksen

Next: RE: Channel access dynamic array subscription update element count 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: Channel access dynamic array subscription update element count Jeff Hill

Next: javaIOC Marty Kraimer

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