Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: RE: Channel access dynamic array subscription update element count
From: "Jeff Hill" <johill@lanl.gov>
To: "'Benjamin Franksen'" <benjamin.franksen@bessy.de>, <michael.abbott@diamond.ac.uk>, "'Andrew Johnson'" <anj@aps.anl.gov>
Cc: tech-talk@aps.anl.gov
Date: Mon, 5 Oct 2009 10:11:04 -0600
This is being tracked under Mantis entry 368. You can add comments there
directly or forward them to tech-talk, myself, etc - and I will append them
to the mantis entry.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA


> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov]
> On Behalf Of Jeff Hill
> Sent: Monday, October 05, 2009 9:24 AM
> To: 'Benjamin Franksen'; tech-talk@aps.anl.gov
> Subject: RE: Channel access and ca_element_count
> 
> 
> > You just stumbled over what I think is one of the most irritating
> > mis(sing)-features of EPICS as it stands: support for array fields is
> very
> > weak. Particularly it is limited to arrays which are of fixed size at
> > run-time.
> 
> Our current situation:
> The server does learn the element count form convert_db_addr when the
> channel
> connects, and it doesn?t ask for the current array length when sending
> subscription updates. We also have been careful about changing the array
> length to other than what the client has specified when issuing the IO
> request
> as this might break backwards compatibility (responsible API design etc).
> 
> In the short term:
> Clients _are_ currently allowed to _not_ specify the element count when
> they subscribe (they can specify an element count of zero). So perhaps
> the CA code should be changed allowing the array length to be dynamic in
> just
> that situation. Currently, we are locking the element count for that
> situation
> to what was there when the channel connects, but perhaps this is wrong
> (lazy)
> etc. Any opinions from Andrew or others? We would need an efficient way to
> query the current element count before each call to db_get_field. The way
> to
> 
> proceed is to first get general agreement on this being a defect, and next
> to
> install a Mantis entry against R3.14 or R3.15 so that we will remember to
> attend to the matter.
> 
> For the future:
> This is certainly one of the more complex issues when designing the
> programming
> interfaces. IMHO, the client _should_ have an option to rigidly specify
> how
> many elements will be received, but should also have an option to _not_
> specify
> the element count and just receive however many elements happen to be
> there. Clients should probably have flexibility to specify, or not, for
> each
> 
> bound on the hypercube (multidimensional array). Am I off base on that as
> a
> future direction for the API design? Open to suggestions.
> 
> Jeff
> ______________________________________________________
> Jeffrey O. Hill           Email        johill@lanl.gov
> LANL MS H820              Voice        505 665 1831
> Los Alamos NM 87545 USA   FAX          505 665 5107
> 
> Message content: TSPA
> 
> 
> > -----Original Message-----
> > From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-
> bounces@aps.anl.gov]
> > On Behalf Of Benjamin Franksen
> > Sent: Friday, October 02, 2009 1:11 PM
> > To: tech-talk@aps.anl.gov
> > Subject: Re: Channel access and ca_element_count
> >
> > On Freitag, 2. Oktober 2009, michael.abbott@diamond.ac.uk wrote:
> > > 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.
> >
> > You just stumbled over what I think is one of the most irritating
> > mis(sing)-features of EPICS as it stands: support for array fields is
> very
> > weak. Particularly it is limited to arrays which are of fixed size at
> > run-time.
> >
> > > 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!
> >
> > AFAIK, this is more or less built into the database machinery itself,
> e.g.
> > the same problem appears with database links. At least that is my
> > experience from trying to write my own array handling record types. I
> > originally thought that, by writing appropriate (if perhaps not
> extremely
> > efficient) code, I could circumvent this, but to no avail: even database
> > links between two records (of types where you wrote the support
> yourself),
> > once they are initialized by the EPICS core, cannot change the reported
> > number of elements at run-time. The existing API is insufficient, as
> e.g.
> > convert_db_addr, get_array_info, and so on are called only during link
> > initialization, never during run-time. The only way to work around this
> is
> > to use /two/ separate links to two separate fields, one for the array,
> and
> > one for the (current) array size.
> >
> > With CA, the situation is similar: once the channel is established,
> there
> > is
> > (to my knowledge) no way for the server to notify clients of a change in
> > the PV's array size. The corresponding field of chid structure is filled
> > once when the channel connects and never changes as long as it stays
> > connected.
> >
> > Cheers
> > Ben




Replies:
Re: Channel access dynamic array subscription update element count Andrew Johnson
References:
Channel access and ca_element_count michael.abbott
Re: Channel access and ca_element_count Benjamin Franksen
RE: Channel access and ca_element_count Jeff Hill

Navigate by Date:
Prev: RE: Channel access and ca_element_count Jeff Hill
Next: Re: state notation code flags Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: RE: Channel access and ca_element_count Jeff Hill
Next: Re: Channel access dynamic array subscription update element count Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·