Experimental Physics and
Industrial Control System

[email protected] (Jeff Hill) · Wed, 11 Aug 1999 11:44:04 -0600

Noburu,

I am not the author of the sub-array record and so I hope that I am not
premature in my initial conclusion that this appears to be a bug in the sub
array record, and that the best solution is to fix this bug which is the
root cause of the problem.

Perhaps the subArray record's cvt_dbaddr() structure should be changed
follows
so that the maximum number of elements is always returned:

static long cvt_dbaddr(paddr)
	struct dbAddr *paddr;
{	
	.
	.
	.
	paddr->no_elements = psa->malm;
	.
	.
	.
}

Is anyone else who is more familiar with the subArray record willing to
comment?

Jeff

> > 
> > When channel access connects to the process variable it is provided
> > with the maximum number of array elements by the "dbAddr" structure
> > which is filled in by the "cvt_dbaddr" record support routine. As
> > you have correctly observed the client library will not allow the
> > client program to send get or put requests for more than this maximum
> > number of elements, and a new maximum is only discovered when the
> > client reconnects.
> > 
> > Here is an extract from the cvt_dbaddr() function from the subArray
> > record:
> > 
> > static long cvt_dbaddr(paddr)
> >     struct dbAddr *paddr;
> > {
> >     if (!psa->udf && psa->nelm > psa->nord)
> >        paddr->no_elements = psa->nord;
> >     else
> >        paddr->no_elements = psa->nelm;
> > }
> > 
> > So we can see that the NELM and the NORD field are used to provide this
> > maximum.
> > 
> ubarray Record has three fields related size of array, i.e. MALM, 
> NORD, NELM.
> According to REcord reference mannual, each fields has following meanig.
> 
> MALM : Maximum number of Elements in sub-array.
> NELM  : Number of Elements in sub-array.
> NORD  : Number of Elements read.
> 
> Usually, MALM is equal to NELM (Larger  MALM than NELM is possible).
> So you can say NELM field is a maximum number of elements in a sub-array.
> In our application, NORD may vary time-to-time. (NORD should be less than
> or equal to MALM=NELM).
> 
> If you use cvt_dbaddr routines from running database, it retuns NORD filed
> as a number of elements in a sub-array, and it is NOT the MAXIMUM number
> of elements in a sub-array(MALM=NELM)
> 
> > Is it possible to just set the maximum value in these fields to 
> be greater
> > the maximum number of elements that will at any time be used in your
> > system?
> 
> We  set MALM and NELM to the maximum number of elements in the 
> application.
> NORD may vary time-to-time, depending on the state of the device.
> (We collect data from the device periodically. Number of record
> accumulated 
> in each period may vary , 1 or 2). 
> 
> The problem is that CA picks a number of elements in an array at one
> point and use it as a maximum number of elements in the array.
> It will be OK if CA can get  the MAXIMUM number of elemetns correctly
> when channel is open. 
> 
> > 
> > If not I am open to discussing relaxing this restriction so that the
> > client can send get and put request for more than the maximum provided
> > at connect time. In this situation the database access layer will be
> > responsible for detecting, and refusing, out of bounds requests. 
> 
> I think dbAccess layer routines and/or record access routines checks 
> size of array already. Am I wrong?
> 
> > The primary
> > drawback will be that client applications that use put and get requests
> > that do not receive a call back on IO completion may have more trouble
> > determining which get/put has failed when several get/put(s) occur
> > together, and the wrong number of elements is specified.
> 
> Or user should check size of sending data explicitly before 
> CA request.
> 
> > 
> > Jeff
> > 
> 
> Noboru
> 
> > >
> > > on Page93, chap 7,sect5 of EPICS IOC Application Developer's
> > > Guide,it says,
> > > "get_array_info() function  returens the CURRENT number of 
> elements and
> > > the offset of the first value of the
> > > specified array".
> > > In other words,  n
o_elements which get_array_info() return may be
> > > smaller than the maximu size of this array.
> > >
> > > Now, ca library compares requested elements count with privCount field
> > > of channel structure and
> > > it rejects request when the requested count is larger than privCount.
> > > privCount field is updated only when
> > > channel is (re) connected. i.e. you cannot request loger array data
> > > than the size of array which get_array_info
> > > when your channel is connected with the Database.
> > >
> > > In our application , the CURRENT number of elements of
> SubArray records
> > > can vary time to time.
> > > However,  application program cannot read an array data
> longer than the
> > > element count which is a element count
> > > at the time channel is connected. It may loose data and its
> size cannot
> > > be predictable.
> > >
> > > Does anyone encounterd similar problem? Or have you solved
> this problem?
> > >
> > > Ragards,
> > >
> > > Noboru Yamaoto
> > > KEKB control Group
> > > KEK, JAPAN
> > >
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System