Jeff Hill wrote:
>
> Hi Noboru,
>
> 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, no_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
> >
- Replies:
- RE: Array Information Jeff Hill
- References:
- RE: Array Information Jeff Hill
- Navigate by Date:
- Prev:
RE: Array Information Jeff Hill
- Next:
RE: Array Information 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
- Navigate by Thread:
- Prev:
RE: Array Information Jeff Hill
- Next:
RE: Array Information 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
|