Bruce,
Yes, using an input link makes the associated calculation useless
(with COPT=="Conditional"). But there's no reliable way to infer
the user's intent via an input link, because we can't know whether
or not the linked-to record was processed -- all we can know is whether
the value was changed, and that's not enough. (We could know with a
CP input link, though. I haven't reconsidered the calculation decision
since CP links were introduced, but maybe I should.)
The transform record does still test to see if a value has changed
before recalculating it, because a value change is proof positive
that someone intended the field to be an independent variable. I
left that code in there when I added the bit map, because I wasn't
confident that the bit map would correctly represent the field's
status in every conceivable case -- if something wrote to the field
*while* the record was in its process() routine, for example.
Tim
----- Original Message -----
> From: "Bruce Hill" <[email protected]>
> To: "Tim Mooney" <[email protected]>, [email protected]
> Sent: Thursday, September 29, 2011 4:59:09 AM
> Subject: Re: Transform Record no_inlink test
> 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
> >
--
Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab
- References:
- Re: Transform Record no_inlink test Bruce Hill
- Navigate by Date:
- Prev:
Re: Combing Two State Sets into One Eric Norum
- Next:
RE: building 64-bit base on windows matthew.pearson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
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
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|