I'm almost certain that this is an easy fix, but it's subtle enough I'd like to get
a second opinion before making changes. In particular, I'm wondering about
interactions with dbNotifyCompletion().
I notice that dbPutField() sets RPRO=1 when PACT=1, but dbProcess()
itself does not. This means that dbPutField() to a record w/ PACT=1
is queued for reprocessing, but async records processed indirectly
(via DB link) are not queued for reprocessing.
A database which demonstrates the process is the following.
I think that "tst:val.VAL" should _eventually_ be 2.
Currently it's 1, with the change below, it's 2.
> record(fanout, "tst:fout") {
> field(PINI, "RUNNING")
> field(LNK1, "tst:calc")
> field(LNK2, "tst:calc")
> field(TPRO, "1")
> }
>
> record(calcout, "tst:calc") {
> field(INPA, "tst:calc")
> field(CALC, "A+1")
> field(ODLY, "0.1")
> field(OUT , "tst:val")
> field(TPRO, "1")
> }
>
> record(longin, "tst:val") {
> field(TPRO, "1")
> }
I think the simplest fix is:
> diff --git a/src/ioc/db/dbAccess.c b/src/ioc/db/dbAccess.c
> index 71e25310f..6376dc46d 100644
> --- a/src/ioc/db/dbAccess.c
> +++ b/src/ioc/db/dbAccess.c
> @@ -526,6 +526,8 @@ long dbProcess(dbCommon *precord)
> if (*ptrace)
> printf("%s: Active %s\n", context, precord->name);
>
> + precord->rpro = TRUE;
> +
> /* raise scan alarm after MAX_LOCK times */
> if ((precord->stat == SCAN_ALARM) ||
> (precord->lcnt++ < MAX_LOCK) ||
- Replies:
- Re: RPRO inconsistency Johnson, Andrew N.
- Navigate by Date:
- Prev:
Jenkins build is back to normal : epics-base-3.15-win64 #331 APS Jenkins
- Next:
areaDetector developers meeting @ APS Mark Rivers
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
2025
- Navigate by Thread:
- Prev:
Jenkins build is back to normal : epics-base-3.15-win32-test #143 APS Jenkins
- Next:
Re: RPRO inconsistency Johnson, Andrew N.
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
2025
|