Re: Transform Record

[Tim Mooney <mooney@aps.anl.gov>]

Dirk Zimoch wrote:

> Hi Tim,
>
> I tried to use the transform record, but somehow it does not work as I 
> expect. When I change one record, the others don't update. Where is my 
> mistake?
>
> Dirk
>
> record (ao, "DZ:WIDTH")
> {
>     field (FLNK, "DZ:TRANS")
> }
>
> record (ao, "DZ:CENTER")
> {
>     field (FLNK, "DZ:TRANS")
> }
>
> record (ao, "DZ:LEFT")
> {
>     field (FLNK, "DZ:TRANS")
> }
>
> record (ao, "DZ:RIGHT")
> {
>     field (FLNK, "DZ:TRANS")
> }
>
> record (transform, "DZ:TRANS")
> {
>     field (INPA, "DZ:LEFT")
>     field (CLCA, "C-D/2")
>     field (OUTA, "DZ:LEFT PP")
>     field (INPB, "DZ:RIGHT")
>     field (CLCB, "C+D/2")
>     field (OUTB, "DZ:RIGHT PP")
>     field (INPC, "DZ:WIDTH")
>     field (CLCC, "(A+B)/2")
>     field (OUTC, "DZ:WIDTH PP")
>     field (INPD, "DZ:CENTER")
>     field (CLCD, "B-A")
>     field (OUTD, "DZ:CENTER PP")
> }

Three things:

1) If there is an input link for a value field (A...P), the transform
record will not evaluate the corresponding expression (CLCA...CLCP).
The usual rule, that the record will evaluate an expression if the
corresponding value has not changed and has not been written to, is
overridden by the presence of an input link.  (Probably this is
excessively conservative, but that's the way the record works at
present.)

2) The ao records probably should be writing to the transform record
via PP links, rather than forward linking to it and thereby causing
the transform record to read their values via input links.  Aside
from the input-link-disables-calc rule, this arrangement would also
allow the transform record to correctly handle the case in which the
value written to one of its fields happens to be the same as the old
value of that field.  (The transform record keeps track of writes to
its value fields.  If there was a write, it regards the value as "new"
for the purpose of deciding whether or not to recalculate it, even if
the write did not change the value.)

3) The transform record probably should not write new values directly
to the ao records.  This is a little involved, and took a long time
to work out, but once you've discovered how EPICS behaves, there's a
pretty simple prescription for making it do what you want.

In one possible use (probably the most common use) of this database,
one of the ao records will be processing as the result of a channel
access put, and the others will not be processing.  If you write to
the record that is processing with a PP link (while it's PACT field
is still 1), EPICS will set the record's RPRO field, and the record
will be processed again after all the dust has settled from the
current round of processing.  You won't get an infinite loop, because
the second round of processing will have been started by a database
put, and lock-set rules will terminate the processing loop after
the second round.

Writing back to the ao records with an NPP link also would not work, if
you want CA clients to see the new  values.  EPICS doesn't post values
written to VAL fields -- the only way to get a VAL field posted is to
cause the record that owns it to process.

Writing with a CA link will get you an infinite loop.

So, you *do* want the ao records to which you are writing new values
to process and post those new values.  But you don't want to tell the
record that is already processing to process.  (If you do, the database
will appear to work, but that second round of processing eventually
will cause some obscure kind of trouble downstream.)  The only way I've
been able to get this accomplished is with a set of write-back ao
records, each record disabled by the PACT field of the record to which
it writes.

--
Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.