EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Transform Record no_inlink test
From: Bruce Hill <[email protected]>
To: Tim Mooney <[email protected]>, "[email protected]" <[email protected]>
Date: Thu, 29 Sep 2011 02:59:09 -0700
Hi Tim,
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.
That doesn't say what I meant it to say.   Let me try again.

Each field with an input link fetches the value, but if the PV it links to hasn't changed,
the value will be the same.    Thus, in the calculation loop, the only calculations
that would be skipped are those that have a changed value.

This works well for a simple case like the following, which would seem to be
the normal way to use transform.
record( transform, "TRAN" )
{
    field( INPA, "A" )
    field( INPB, "B" )
    field( INPC, "C" )
    field( CLCA, "B+C" )
    field( CLCB, "A-C" )
    field( CLCC, "A-B" )
    field( OUTA, "A PP" )
    field( OUTB, "B PP" )
    field( OUTC, "C PP" )
}
record( ao, "A" ) { field( FLNK, "TRAN PP" ) }
record( ao, "B" ) { field( FLNK, "TRAN PP" ) }
record( ao, "C" ) { field( FLNK, "TRAN PP" ) }

I see how the code for the map bits provide more control for complex situations,
where you might want to suppress calculations even when the value hasn't changed.

I just don't get what the no_inlink test is accomplishing.   Doesn't that make the input
links unusable for any variables in the transform set?    Since the only other way to change
the values of A, B, C, ... is to write directly to those fields and that sets the map bit,
why bother computing the variable called same if  input links aren't supported for
any fields with a calculation?

Regards,
- Bruce

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" <[email protected]>
>> To: [email protected]
>> Cc: [email protected]
>> 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



Replies:
Re: Transform Record no_inlink test Tim Mooney
References:
Re: Transform Record no_inlink test Tim Mooney
Re: Transform Record no_inlink test Bruce Hill

Navigate by Date:
Prev: building 64-bit base on windows matthew.pearson
Next: the seq that launched a thousand seqs Laznovsky Michael
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Transform Record no_inlink test Bruce Hill
Next: Re: Transform Record no_inlink test Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024