EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: [Bug 1841634] Re: CP link triggers lost when record is async
From: Andrew Johnson via Core-talk <[email protected]>
To: [email protected]
Date: Tue, 27 Aug 2019 16:52:53 -0000
One way to fix this might be to replicate the scanOnce queue but have
the active end check PACT and set RPRO if the record is busy at the
time, like dbPutField() does. One question would be whether the
resulting queue ("scanForce" maybe?) should become part of dbScan or
just live in dbCa.c.

-- 
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: [Bug 1841634] [NEW] CP link triggers lost when record is async Andrew Johnson via Core-talk
Next: Re: Strange behavior of async calcout with CPP input link Johnson, Andrew N. via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: [Bug 1841634] [NEW] CP link triggers lost when record is async Andrew Johnson 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  <20192020  2021  2022  2023  2024 
ANJ, 28 Aug 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·