> 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?
Could this be a race condition? What would happen if there were multiple CA callbacks while the record was processing? Is it possible for one of the inputs to change state without processing the record again to compute the correct VAL?
Mark
________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Ben Franksen via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, February 16, 2021 4:56 AM
To: EPICS tech-talk
Subject: Yet another calc record / CPP link problem
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
- Replies:
- Re: Yet another calc record / CPP link problem Ben Franksen via Tech-talk
- References:
- Yet another calc record / CPP link problem Ben Franksen via Tech-talk
- Navigate by Date:
- Prev:
Detect PV connect and disconnect events in CSS Pogacnik, Matic via Tech-talk
- Next:
Re: Detect PV connect and disconnect events in CSS Kasemir, Kay 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
<2021>
2022
2023
2024
- Navigate by Thread:
- Prev:
Yet another calc record / CPP link problem Ben Franksen via Tech-talk
- Next:
Re: Yet another calc record / CPP link problem Ben Franksen 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
<2021>
2022
2023
2024
|