Experimental Physics and
Industrial Control System

Benjamin Franksen via Core-talk <[email protected]> · Tue, 27 Aug 2019 16:26:25 +0200

I'll answer both you replies in one message.

Am 26.08.19 um 23:13 schrieb Johnson, Andrew N. via Core-talk:
> On 8/26/19 12:42 PM, Michael Davidsaver via Core-talk wrote:
> This might be https://bugs.launchpad.net/epics-base/+bug/1745039

I think so.

> Any chance you can try to reproduce with Base 7.0.3?

Here is a small self-contained database to reproduce this:

record(calcout,"input") {
    field(CALC,"A<4?A+1:A")
    field(INPA,"input")
    field(ODLY,"1")
    field(OUT,"input.A CA")
}
record(calcout,"output") {
    field(DTYP,"Async Soft Channel")
    field(ODLY,"1.5")
    field(INPA,"input CPP")
    field(CALC,"A")
    field(TPRO,1)
}
record(calc,"check") {
    field(INPA,"input CPP")
    field(INPB,"output CPP")
    field(CALC,"A==B")
}

Processing "input" (caput input.PROC 1) starts the test. The "check"
record should eventually settle to 1.

With 7.0.3 I get this output:

scanOnce: dbProcess of 'output' # initial CPP processing
scanOnce: dbProcess of 'output'
scanOnce: dbProcess of Active 'output' with RPRO=0
scanOnce: dbProcess of 'output'
scanOnce: dbProcess of Active 'output' with RPRO=0

Note how this says "with RPRO=0".

And camonitor says:

franksen@tiber: ~ > camonitor input output check
input                          <undefined> 0 UDF INVALID
output                         2019-08-27 16:02:16.106413 0
check                          2019-08-27 16:02:16.106617 1
input                          2019-08-27 16:02:26.498483 1
check                          2019-08-27 16:02:26.498721 0
input                          2019-08-27 16:02:27.493734 2
output                         2019-08-27 16:02:27.993908 1
input                          2019-08-27 16:02:28.489068 3
input                          2019-08-27 16:02:29.484350 4
output                         2019-08-27 16:02:29.984458 3

So this happens with 7.0.3, too.

> (2) if a record (here: DEV1:trgOn) is active (PACT=1) when an event 
> arrives, it gets processed again, after completing.
> 
> This was only true when a record was processed directly by
> dbPutField() (eg. via channel access).  "CPP" links use dbProcess(),
> which didn't do this.
> 
> I concur with Michael. I think your use of a CPP link to trigger an
> asynchronous record is the source of the problem, and I believe that
> you would still see the problem even when running it on Base-7.0.3.

Yes.

Thanks for your debugging hints and possible work-arounds. My concrete
problem has vanished in the meantime because I found that using "Async
Soft Channel" for DEV1:trgOn wasn't necessary. Indeed using the plain
"Soft Channel" fixed the problem.

I still think the difference in behavior between processing due to a CPP
input link versus processing due to a PP or CA output link is quite
surprising.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System