EPICS Re: Base 3.15 and record initialization

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> 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 2011 2012 2013 2014 2015 2016 <2017> 2018 2019 2020 2021 2022 2023 2024
<== Date ==>		<== Thread ==>

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

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

<== Date ==>

<== Thread ==>

Subject:

Re: Base 3.15 and record initialization

From:

Bruce Hill <[email protected]>

To:

"Dunning, Michael" <[email protected]>, EPICS Tech-Talk <[email protected]>

Cc:

"Condamoor, Shantha" <[email protected]>

Date:

Sat, 2 Sep 2017 01:28:28 -0700

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