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

Subject: Yet another calc record / CPP link problem
From: Ben Franksen via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS tech-talk <tech-talk at aps.anl.gov>
Date: Tue, 16 Feb 2021 11:56:08 +0100
I have problems with a slightly complicated database that sometimes
"hangs" in an unexpected state because some status bits aren't
propagated as they should be. Investigating the state of the IOC I
tracked the problem down to the following record:

record(calcout,"BPMMUXCB:stTLIO") {
    field(CALC,"A&B&C&D=A|B|C|D?A:VAL")
    field(INPA,"BPMMUX1S16G:stT CPP")
    field(INPB,"BPMMUX1S16G:stL CPP")
    field(INPC,"BPMMUX2S16G:stI CPP")
    field(INPD,"BPMMUX2S16G:stO CPP")
}

The input records are of type mbbi. The CALC expression is such that we
check if all inputs are equal; if yes, set VAL to one of them, else
don't change VAL.

The problematic state is this: all inputs are zero, yet VAL=1. I checked
that both the input fields (A..D) are zero as well as the PVs that
supply the input values.

How is that possible? If the record was able to process its input links
(which it apparently did since A..D have the expected values), then
shouldn't it also process the CALC expression and set VAL accordingly?

Furthermore: processing the record (caput BPMMUXCB:stTLIO.PROC 1) did
/not/ have any effect (VAL remained at 1). However, writing a different
but equivalent expression into CALC field did resolve it: VAL then
became 0 as expected.

This looks similar to https://bugs.launchpad.net/epics-base/+bug/1841634
but note that the calcout here has no ODLY set, so it should (I think)
process synchronously.

I case you wonder: Yes, a simple calc instead of a calcout would have
been sufficient here; that it's a calcout is a left-over from a previous
version. I cannot ATM verify that the calc record has the same behavior.

This problem is very hard to reproduce. The only way I have been able to
reproduce it is to let the Python script that drives the thing in order
to make certain measurements run for a long time and wait until it hangs
(waiting for readbacks to coincide with setpoints after switching the
multiplexor to another channel).

Cheers
Ben
-- 
I would rather have questions that cannot be answered, than answers that
cannot be questioned.  -- Richard Feynman


Attachment: signature.asc
Description: OpenPGP digital signature


Replies:
Re: Yet another calc record / CPP link problem Mark Rivers via Tech-talk
Re: Yet another calc record / CPP link problem Michael Davidsaver via Tech-talk

Navigate by Date:
Prev: EPICS Codeathon: March 8 to March 12 Hartman, Steven via Tech-talk
Next: EPICS latest stable version Delahaye Olivier via Tech-talk
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  <20212022  2023  2024 
Navigate by Thread:
Prev: Re: ELMO motion control using EPICS Mark Rivers via Tech-talk
Next: Re: Yet another calc record / CPP link problem Mark Rivers via Tech-talk
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  <20212022  2023  2024 
ANJ, 16 Feb 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·