Re: Transform Record no_inlink test

[Bruce Hill <bhill@slac.stanford.edu>]

Hi Tim,
Thanks for the explanation.    I did simplify my example
by eliminating the DTYP and OUT fields, some of which wrote
to a device, but I could have used ao's OUT field for the other variables.

Just my 2 cents, but I think your map bits fix the problem of writing
the same value twice without needing to disable the calculations for
fields with input links.    i.e.  if someone uses an input link, they would
get only the value change test, but if they write directly to the field,
they get the current behaviour where it disables calculations even
when the value is unchanged.

Regards,
- Bruce

On 09/29/2011 09:39 AM, Tim Mooney wrote:

Bruce,
I'm not very clear on what you're trying to do, but it seems
like you want the record to recalculate A, G, and O when someone
sets B, and recalculate B, G, and O when someone sets A, etc.
If so, you're right that this requires external records to drive
the value fields.

Input links don't work in this case, because the record doesn't
use value changes alone to determine whether to recalculate.  (An
early version of the record did use only value changes, but that
strategy failed to please when a user wrote exactly the same
value twice: the first time the record honored the user's write;
the second time it recalculated, ignoring the user's wishes
because the user failed to write a value that was different
from the previous value.  It was ugly.)

In the database you show, you don't have to add dfanout records
to have the ao records write to the transform record.  You could
use the ao records' OUT fields instead.  (Maybe you deleted those
fields for clarity.  If so, thanks and never mind.)

Tim

----- Original Message -----
  

From: "Bruce Hill" <bhill@slac.stanford.edu>
To: "Tim Mooney" <mooney@aps.anl.gov>
Cc: tech-talk@aps.anl.gov
Sent: Wednesday, September 28, 2011 7:32:45 PM
Subject: Re: Transform Record no_inlink test
Hi Tim,
I tried the COPT "Always" setting and it doesn't work for me as it
re-computes and steps on the new values. I've got a solution working
where I deleted the transform record input links and replaced my ao
value
PV's with dfanout records that write to the transform record fields
directly.

However, I think I'm still not understanding how the transform record
is intended to operate.


an input link disables the associated calculation
because the value field will have been fetched by the record
before the calculation was to be performed. Each input link will fetch
a value, but that code doesn't set the map bit,
and the new_value variable detects whether or not the value has
changed.
It would seem to be safe to do the calculations for any new values
whether
they came from input links or from direct writes to the transform
record fields.

Regards,
- Bruce

On 09/27/2011 04:05 PM, Tim Mooney wrote:

Bruce,

The transform record has two modes of operation. The mode is
selected by the field COPT, which can take one of two values:

0) ("Conditional") do calculations only for fields that have
not been written to since the last time the record processed.
This is the default, because it's the behavior for which the
record was originally written, and for backward compatibility
with databases written before the COPT field was added. In
this mode, an input link disables the associated calculation
because the value field will have been fetched by the record
before the calculation was to be performed.

1) ("Always") do all calculations regardless of whether fields
have been written to. This is relatively new, and it's the
behavior you want.

In either mode it's ok for an output link to point to the same
PV as the associated input link.

The idea of conditional, by the way, is to separate value fields
into independent variables (written to) and dependent variables
(not written to; recalculated from independent variables), to
implement bidirectional coordinate transformations. More
details are in the documentation:
https://subversion.xor.aps.anl.gov/synApps/calc/trunk/documentation/transformRecord.html
Tim

----- Original Message -----

From: "Bruce Hill" <bhill@slac.stanford.edu> To: tech-talk@aps.anl.gov
Cc: mooney@aps.anl.gov Sent: Tuesday, September 27, 2011 5:05:16 PM
Subject: Transform Record no_inlink test
In using the transform record V5.7 from calc 2.8, I found that the
record has
a test in transformRecord.c line 398 that disables output calculations
for each variable that
has an input link.

If I disable that test for no_inlink, my transform record behaves as I
expect.

Does anyone know why that test is there?

It seems to preclude using the transform record input links which
select the same PV as the output links.
I can get around it by adding dfanout records to write the values
directly to the
transform record input fields, A-P, but it seems like an ugly
workaround.

Regards,
- Bruce



record( ao, "$(CAM):Gain" )
{
field( DESC, "Set camera gain" )
field( DRVH, "100" )
field( DRVL, "0" )
field( HOPR, "100" )
field( LOPR, "0" )
field( PINI, "YES" )
field( FLNK, "$(CAM):Gain:Calc PP" )
}

record( ao, "$(CAM):GainA" )
{
field( DESC, "Gain for side A" )
field( FLNK, "$(CAM):Gain:Calc PP" )
field( DOL, "0x042" )
field( DRVL, "0x042" )
field( DRVH, "0x1E8" )
}

record( ao, "$(CAM):GainB" )
{
field( DESC, "Gain for side B" )
field( FLNK, "$(CAM):Gain:Calc PP" )
field( DOL, "0x042" )
field( DRVL, "0x042" )
field( DRVH, "0x1E8" )
}

record( ao, "$(CAM):Gain:Offset" )
{
field( DESC, "Offset between gain halves" )
field( PINI, "YES" )
field( FLNK, "$(CAM):Gain:Calc PP" )
}

record( transform, "$(CAM):Gain:Calc" )
{
field( DESC, "Calc camera gain" )
field( INPA, "$(CAM):GainA" )
field( INPB, "$(CAM):GainB" )
field( INPH, "0x1E8" )
field( INPL, "0x042" )
field( INPO, "$(CAM):Gain:Offset" )
field( INPG, "$(CAM):Gain" )
field( CLCA, "(G/100)*(H-L)+L-(O/2)" )
field( CLCB, "(G/100)*(H-L)+L+(O/2)" )
field( CLCG, "(((A+B)/2)-L)*100/(H-L)" )
field( CLCO, "B-A" )
field( PINI, "YES" )
field( OUTA, "$(CAM):GainA PP" )
field( OUTB, "$(CAM):GainB PP" )
field( OUTG, "$(CAM):Gain PP" )
field( OUTO, "$(CAM):Gain:Offset PP" )
}
--
Bruce Hill
Member Technical Staff
SLAC National Accelerator Lab
2575 Sand Hill Road M/S 10
Menlo Park, CA 94025
    

-- 
Bruce Hill
Member Technical Staff
SLAC National Accelerator Lab
2575 Sand Hill Road M/S 10
Menlo Park, CA  94025