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
> > >
>
- References:
- Re: Array Information Noboru Yamamoto
- Navigate by Date:
- Prev:
Re: Array Information Noboru Yamamoto
- Next:
TEWS TIP810 Replacement? W T Meyer
- 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: Array Information Noboru Yamamoto
- Next:
[Re: drvGpib.c] Noboru Yamamoto
- 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
|