Experimental Physics and
Industrial Control System

Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> · Tue, 16 Feb 2021 08:10:13 -0800

On 2/16/21 2:56 AM, Ben Franksen via Tech-talk wrote:
> 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")
> }

Loaded a softIoc with this record and four dummy input bi records.
It didn't take me long to find a sequence which exhibits the
"hysteresis" which you describe.  I'm not so quick with the mouse
this morning, so I don't think this is a race condition.

Initially all 5 records are zero.

> epics> dbpf BPMMUX1S16G:stT 1
> DBF_STRING:         "One"     
> epics> dbpf BPMMUX1S16G:stL 1
> DBF_STRING:         "One"     
> epics> dbpf BPMMUX1S16G:stL 0
> DBF_STRING:         "Zero"    
> epics> dbpf BPMMUX1S16G:stT 0
> DBF_STRING:         "Zero"    
> epics> dbgf BPMMUXCB:stTLIO
> DBF_DOUBLE:         1         
> epics>

The use of "VAL" here confuses me, but I wonder "A&B&C&D=A|B|C|D"
should be "(A&B&C&D)=(A|B|C|D)"?

> 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
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System