Re: Strange behavior of async calcout with CPP input link

["Johnson, Andrew N. via Core-talk" <core-talk@aps.anl.gov>]

On 8/27/19 9:26 AM, Benjamin Franksen via Core-talk wrote:

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.

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.

As your example database sets output.ODLY it makes no difference whether you use Async Soft Channel or Soft Channel since a non-zero ODLY makes that record asynchronous anyway. One other way to resolve this could be to set input.MDEL to -1 so it continues to process the check record after its value has stopped changing, but doing that might have undesirable effects further down the chain.

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.

I agree that this behaviour doesn't seem ideal, but I'm not sure how easy it would be to change given the way that the triggering from a monitor event currently works. Maybe using another queue like scanOnce but have it check PACT and set RPRO (like dbPutField() does) might do the trick.

I'm filing your example (lightly edited) as a Wishlist bug so we don't lose it, thanks for the report!

- Andrew

-- 
Complexity comes for free, Simplicity you have to work for.