Experimental Physics and Industrial Control System
> 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:[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 and ca_element_count Jeff Hill
- RE: Channel access dynamic array subscription update element count Jeff Hill
- Re: Channel access and ca_element_count Andrew Johnson
- References:
- Channel access and ca_element_count michael.abbott
- Re: Channel access and ca_element_count Benjamin Franksen
- Navigate by Date:
- Prev:
Re: state notation code flags Andrew Johnson
- Next:
RE: state notation code flags Mark Rivers
- 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 Benjamin Franksen
- Next:
RE: Channel access and ca_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