EPICS Controls Argonne National Laboratory

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: Tim Mooney <[email protected]>
To: Bruce Hill <[email protected]>
Cc: [email protected]
Date: Thu, 29 Sep 2011 12:32:34 -0500 (CDT)
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  <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 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·