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  2011  2012  2013  2014  2015  2016  <2017 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
<== Date ==> <== Thread ==>

Subject: Re: Base 3.15 and record initialization
From: "Johnson, Andrew N." <anj@aps.anl.gov>
To: Bruce Hill <bhill@slac.stanford.edu>
Cc: "Condamoor, Shantha" <scondam@slac.stanford.edu>, EPICS Tech-Talk <tech-talk@aps.anl.gov>
Date: Sun, 3 Sep 2017 04:59:05 +0000
Hi Mike,

Bruce's discovery shows that the change in behavior is a bug in Base-3.15 which I will fix (for DB links at least, CA links have always suffered from that lockup problem and fixing them wouldn't be easy), but I agree that your link probably shouldn't be specifying MS anyway so that change should be sufficient to resolve your alarm severity lockup.

In fact it is no longer necessary to use links to reference previous Calc values. For quite a long time now the libCom Calc engine has supported the VAL keyword which normally returns the contents of the result from the last time the calculation was executed. If someone puts to the VAL field of a calc record the VAL keyword will return whatever was written to VAL instead, which gives exactly the same behavior as a self-referential input link. Using VAL frees up one more input to the _expression_, which is sometimes useful for complex expressions.

- Andrew

-- 
Sent from my iPad

On Sep 2, 2017, at 3:28 AM, Bruce Hill <bhill@slac.stanford.edu> wrote:

Hi Mike,

I dug further into this and found that in 3.14.12 and earlier, the call to inherit_severity() in dbGetLinkValue() in dbAccess.c has this test for DB_LINKs to block records from inheriting severity from themselves:

        if(precord!= paddr->precord) {
            inherit_severity(ppv_link,precord,paddr->precord->stat,paddr->precord->sevr);
        }               

In 3.15.5, that code has moved to dbLink.c and the equivalent call to inherit_severity()
in dbGetLink() doesn't have that test.

This is another indication that the use of "MS" in your calc records was probably not intentional
and likely didn't behave different than if "NMS" had been used, so it should be safe for you to
make that change.

For the community, the question is whether or not this is correct behavior and if there is a use
case for a record inheriting severity from itself.    I can't think of one.

Regards,
- Bruce

On 09/01/2017 04:21 PM, Dunning, Michael wrote:
We're upgrading some IOCs to base 3.15.5, and are seeing some new behavior with self-referential calc records.  Here's a simplified example:

=================================
record(ao, "TEST123:AoTest") {
  field(HIGH, "5")
  field(HIHI, "10")
  field(HSV,  "MINOR")
  field(HHSV, "MAJOR")
  field(PINI, "1")
  field(FLNK, "TEST123:CalcTest")
}

record(calc, "TEST123:CalcTest") {
  field(INPA, "TEST123:CalcTest NPP MS")
  field(INPB, "TEST123:AoTest NPP MS")
  field(CALC, "B<100?(A+1):A")
  field(FLNK, "TEST123:AiTest")
}

record(ai, "TEST123:AiTest") {
  field(INP,  "TEST123:CalcTest")
  field(HIGH, "5")
  field(HIHI, "10")
  field(HSV,  "MINOR")
  field(HHSV, "MAJOR")
}
=================================

Notice the "MS" in the calc record's INPA.  We don't yet know why the original developer did this, and it seems that it would just cause the record to get stuck in an alarm state if any input went into an alarm state.

Also notice that the calc record gets processed by the ao record, so it's not an issue of anything being undefined.

With base 3.15.5, when the IOC starts, the calc record has SEVR: INVALID and STAT: LINK.
If I change INPA from "MS" to "NMS" and restart the IOC, the record has SEVR: NO_ALARM and STAT: NO_ALARM.  

I verified that with base 3.14.11 and 3.14.12 the problem doesn't happen; i.e. the record has SEVR: NO_ALARM and STAT: NO_ALARM.

Can anyone comment on whether we can safely replace "MS" with "NMS" in a record chain like this?  And if there have been more significant changes to the way that records are initialized, should we expect anything else to break?

Thanks,
Mike


Michael Dunning
SLAC National Accelerator Laboratory
2575 Sand Hill Road, MS 63
Menlo Park, CA 94025


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

References:
Base 3.15 and record initialization Dunning, Michael
Re: Base 3.15 and record initialization Bruce Hill

Navigate by Date:
Prev: Re: Base 3.15 and record initialization Andreas Lüdeke
Next: Re: C++ multi threaded application. Giacomo S.
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
Navigate by Thread:
Prev: Re: Base 3.15 and record initialization Bruce Hill
Next: Re: Base 3.15 and record initialization Andreas Lüdeke
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
ANJ, 04 Sep 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·