Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 5 Oct 2009 09:24:25 -0600

> 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System