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
<2009>
2010
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
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|