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
<2021>
2022
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
<2021>
2022
2023
2024
|