Subject: |
[Bug 1841634] Re: CP link triggers lost when record is async |
From: |
Andrew Johnson via Core-talk <[email protected]> |
To: |
[email protected] |
Date: |
Fri, 30 Aug 2019 18:43:14 -0000 |
Okay, so that part of dbCa changed in 3.16 without my realizing it, I
was looking at the 3.15 version and had forgotten about the
scanLinkOnce() addition, sorry my bad.
So now we need to have a discussion on whether updates from CA links
with CP/CPP set should queue or cache. Maybe there could be another flag
in the link to request queueing, but given that the CA event queues
sending the value updates can and do throw away older updates once the
queue is full I think we're better off not allowing multiple triggers to
get queued up. The dbCa code doesn't queue the values, so I see little
point in processing the record more than once after the last trigger has
arrived and its value cached. We need to ensure that the record does
process once after the last update, but I don't think we could wait for
the dbNotify "finished" event. That might not happen until hours later
in some cases, so I think it would be the wrong mechanism.
RPRO could do what we need if we had a way to get onceTask to do
something different. How about we modify onceTask to give it a more
general callback mechanism as well. It should still use the ring buffer,
but maybe push variable length items to avoid wasting ring space (the
push operation must be atomic, but the pulls don't need to be). A call
to scanOnce() with no callback only needs to push a "process this
record" command and the record pointer; a call to scanOnceCallback()
needs to push "process record and callback" plus the three pointer
arguments; we'd add a generic "call this" command with 2 pointer
arguments.
With this the dbCa callback would lock the record, process it or set
RPRO and unlock with completion checks that we need. The scanningOnce
counter could become a boolean but in any case it should be zeroed in
dbCaGetLink(), which is the point at which we'll have passed the latest
cached value to the record so the trigger from it can expire. We no
longer have a queue with an arbitrary length, and we don't process the
record more than necessary.
Does that finally make some sense?
--
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1841634
Title:
CP link triggers lost when record is async
Status in EPICS Base:
Confirmed
Status in EPICS Base 7.0 series:
Confirmed
Bug description:
From Benjamin Franksen:
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(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 (but doesn't).
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
I 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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1841634/+subscriptions
- References:
- [Bug 1841634] [NEW] CP link triggers lost when record is async Andrew Johnson via Core-talk
- Navigate by Date:
- Prev:
Re: pvPutLog? Michael Davidsaver via Core-talk
- Next:
[Bug 1842086] Re: TestHarness should be TESTPROD instead of PROD Andrew Johnson via Core-talk
- Index:
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:
[Bug 1841634] Re: CP link triggers lost when record is async mdavidsaver via Core-talk
- Next:
[Bug 1841634] Re: CP link triggers lost when record is async mdavidsaver via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
|