Experimental Physics and
Industrial Control System

Ben Franksen via Core-talk <core-talk at aps.anl.gov> · Wed, 18 Mar 2020 17:39:02 +0100

Am 18.03.20 um 13:59 schrieb Ralph Lange via Core-talk:
> Very nice summary - couldn't have said it better.

Thanks.

> Your approach sounds right, too.

Good!

> Note, however, that the requirements and user interface for the
> array-on-write filter are not obvious and trivial.
>
> In the implemented read/monitor case, the input is an array, the
> configuration

(I guess with this you mean: the JSON data attached to the link)

> defines a subset of that input array, and the output is an
> array that consists of that subset.
>
> On write, does the configuration define which subset of the source is
> written to the target?
> Or does it rather define what part of the target array the source array is
> being written to?
> I think both operations do have valid use cases.

I was thinking of the latter. For instance, I want

> caput PV.[2] 4.0

to mean "set the element with index 2 of PV to 4.0". Similarly,

record(ao,"X") {
  field(OUT,"PV.[2]")
}

should write X.VAL to the element with index 2 of PV. I think that these
are the only reasonable interpretations when using the array bracket
short-hand notation, and therefore, by extension, of the existing JSON
syntax for array filters. (I just saw Andrew's reply and I think he
makes a similar point.)

The other operation (modifying which elements of the source record are
written) certainly has valid use cases, but it would be better served by
a suitable extension of the JSON syntax. For the current project this is
out of scope.

> It might be fine to require an additional record instance in some cases,
> especially for the combination, i.e., writing a well-defined subset of the
> input array into a well-defined part of the output array.

This is perhaps not necessary if the JSON syntax is extended to cover
this use case. A relatively clean way to do that would be to add a layer
of indirection: "arr" would optionally have one or two sub-objects "src"
and "tgt", that can each contain the members "s", "i", and "e"; the
existing syntax "arr":{"s":s,"i":i,"e":e} would then be short-hand for
"arr":{"tgt":{"s":s,"i":i,"e":e}}.

Please note that this is not a fully thought-through proposal, just the
first thing that came to my mind. One might rightfully argue against the
choice of keywords here, since for a read filter "tgt" may invoke the
wrong intuition. Defining such syntax needs very careful consideration
and should ideally go through a process of public review before
finalizing it. I also think that such an extension may need additional
members for db_field_log, which currently seems to be concerned with
exactly one field of one record.

Again, this is out of scope for my current plan.

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