Experimental Physics and
Industrial Control System

Ben Franksen via Core-talk <core-talk at aps.anl.gov> · Mon, 23 Mar 2020 12:53:50 +0100

Am 23.03.20 um 06:07 schrieb Johnson, Andrew N.:
> The ‘wrap-around’ feature as you describe it sounds like the circular
> buffer mode of array field access, which Is an essential feature for
> a few record types such as the histogram record IIRC. I’m not sure
> if/how it interacts with the filters (there may be bugs in those
> interactions, I have no idea) but we can’t afford to drop it. I
> suspect it’s described in the AppDevGuide since it’s been included
> for a very long time.

Okay, thanks. I didn't know about that feature.

Let me see if I understand how this behavior is specified. Suppose we
have an array valued PV (a field of some record). It has a static
capacity C (maximal array length), which is what we get when we
"connect" to such a PV (via runtime DB access) as the no_elements member
of dbAddr. But at runtime we also have to query (via the get_array_info
rset method) a current offset S >= 0 and length N <= C. If there is no
such method, the offset and length default to S=0 and N=C.

When we access that PV, we should map a request index i < N to the
internal index

(*)  i' = (i + S) % N

As I understand it, this mapping is an internal implementation detail of
the database. In principle, a record type could implement the same
behavior by actually copying around elements of the array and returning
a zero offset in its get_array_info, it would just be (a lot) slower.

I also understand this to not interfere with the invariant that we never
access any element of the PV beyond its current length N i.e. any values
PV[N],..,PV[C-1] are considered undefined/non-existing. The only valid
array elements are PV[0],..,PV[N-1] and the offset-shifting happens only
among these elements.

Is it correct to assume that S may be larger than N? With the above
formula it could, so a record could, in principle, increment its
internal offset repeatedly (until it overflows, at which point behavior
would become undefined).

It follows from this that array filters are completely orthogonal. When
we access such a PV with an array filter [s:r:e], the start index s and
end index e are considered /request/ indices: they refer to the array as
it appears from the outside. Operationally, when we read the PV, we
first apply the index mapping (*), then modify the result as specified
for the array filters. When we write the PV, we first apply the array
filter to the request, then apply the mapping (*). Particularly, as
documented, the bounds specified with an array filter do /not/ have this
special "ring buffer" behavior: if I specify the filter with r=1 and
e=N-1 and s>0, then the request is truncated i.e. what I actually get
are e-s+1 elements.

Assuming I got this right, I think the current code works fine, even if
another filter is interposed before the array filter.

Cheers
Ben

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Volkmar Dietz, stv. Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (Sprecher), Prof. Dr. Jan Lüning, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System