Experimental Physics and
Industrial Control System

Ben Franksen via Tech-talk <tech-talk at aps.anl.gov> · Tue, 16 Feb 2021 15:50:01 +0100

Am 16.02.21 um 14:22 schrieb Mark Rivers:
>> 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?

It very much looks like one, doesn't it?

>  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?
This is what I suspected at first, which is why I explicitly triggered
processing by writing to PROC. This did not have the expected effect (of
re-computing and thus fixing VAL).

The next time this happens I will hopefully be able to get more
information (like doing a full dbpr); any idea what else I could do?

Cheers
Ben

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

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System