EPICS Controls 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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Channel access dynamic array subscription update element count
From: "Jeff Hill" <[email protected]>
To: "'Benjamin Franksen'" <[email protected]>, <[email protected]>, "'Andrew Johnson'" <[email protected]>
Cc: [email protected]
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        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Jeff Hill
> Sent: Monday, October 05, 2009 9:24 AM
> To: 'Benjamin Franksen'; [email protected]
> 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        [email protected]
> LANL MS H820              Voice        505 665 1831
> Los Alamos NM 87545 USA   FAX          505 665 5107
> 
> Message content: TSPA
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:tech-talk-
> [email protected]]
> > On Behalf Of Benjamin Franksen
> > Sent: Friday, October 02, 2009 1:11 PM
> > To: [email protected]
> > Subject: Re: Channel access and ca_element_count
> >
> > On Freitag, 2. Oktober 2009, [email protected] 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  2018  2019  2020  2021  2022  2023  2024 
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  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·