Hej Mark,
thanks for digging.
The problem can probably fixed in asyn or in boRecord.c,which is part of EPICS base.
I took the time to do some more printf-ing.
Setting/reseting the different alarm states/severies seems to be a splitter resonsiblity
between the record code (in EPICS Base) an device support in asyn.
My conclusionfor the moment is that the device support is the "first one to know” that there
has been a UDF=1 -> UDF=0 transition, caused by a callback.
Because now we need to build up the new alarm state/severity from scratch.
My suggestion is a change/improvement in asyn:
<https://github.com/EuropeanSpallationSource/asyn/commit/459d2697b6a6747d051adcec7b6ee826fff4e2ea>
But we may argue that EPICS Base is a better place to fix it.
BR
/Torsten
> On 29 May 2021, at 17:11, Mark Rivers <notifications at github.com> wrote:
>
>
> I modified devAsynInt32.c::processBo to print some debugging as follows:
>
> diff --git a/asyn/devEpics/devAsynInt32.c b/asyn/devEpics/devAsynInt32.c
> index 4dfc50c..8d1ab1e 100644
> --- a/asyn/devEpics/devAsynInt32.c
> +++ b/asyn/devEpics/devAsynInt32.c
> @@ -1213,37 +1213,40 @@ static long processBo(boRecord *pr)
> devPvt *pPvt = (devPvt *)pr->dpvt;
> int status;
>
> epicsMutexLock(pPvt->devPvtLock);
> if(pPvt->newOutputCallbackValue && getCallbackValue(pPvt)) {
> /* We got a callback from the driver */
> if (pPvt->result.status == asynSuccess) {
> pr->rval = pPvt->result.value;
> pr->val = (pr->rval) ? 1 : 0;
> pr->udf = 0;
> + asynPrint(pPvt->pasynUser, ASYN_TRACE_WARNING, "processBo record=%s, udf=0\n", pr->name);
> }
> } else if(pr->pact == 0) {
> pPvt->result.value = pr->rval;
> if(pPvt->canBlock) {
> pr->pact = 1;
> pPvt->asyncProcessingActive = 1;
> }
> epicsMutexUnlock(pPvt->devPvtLock);
> status = pasynManager->queueRequest(pPvt->pasynUser, 0, 0);
> if((status==asynSuccess) && pPvt->canBlock) return 0;
> if(pPvt->canBlock) pr->pact = 0;
> epicsMutexLock(pPvt->devPvtLock);
> reportQueueRequestStatus(pPvt, status);
> }
> pasynEpicsUtils->asynStatusToEpicsAlarm(pPvt->result.status,
> WRITE_ALARM, &pPvt->result.alarmStatus,
> INVALID_ALARM, &pPvt->result.alarmSeverity);
> + asynPrint(pPvt->pasynUser, ASYN_TRACE_WARNING, "processBo record=%s, calling recGblSetSevr status=%d, severity=%d\n",
> + pr->name, pPvt->result.alarmStatus, pPvt->result.alarmSeverity);
> (void)recGblSetSevr(pr, pPvt->result.alarmStatus, pPvt->result.alarmSeverity);
> if (pPvt->numDeferredOutputCallbacks > 0) {
> callbackRequest(&pPvt->outputCallback);
> pPvt->numDeferredOutputCallbacks--;
> }
> pPvt->newOutputCallbackValue = 0;
> pPvt->asyncProcessingActive = 0;
> epicsMutexUnlock(pPvt->devPvtLock);
> if(pPvt->result.status == asynSuccess) {
> return 0;
>
> So it prints the a message when it sets udf=0 and it prints a message just before it calls recGblSetSevr with the values it is setting for status and severity.
>
> This is now the complete output after iocInit:
>
>
> iocRun: All initialization complete
> date
> 2021/05/29 10:03:51.073336
> dbpr testAPD:scope1:Clutch 2
> ACKS: NO_ALARM ACKT: YES ASG : BKPT: 00
> COSV: NO_ALARM DESC: DISA: 0 DISP: 0
> DISS: NO_ALARM DISV: 1 DOL : CONSTANT DTYP: asynInt32
> EVNT: FLNK: CONSTANT HIGH: 0
> IVOA: Continue normally IVOV: 0 LCNT: 0
> MASK: 0 NAME: testAPD:scope1:Clutch NSEV: NO_ALARM
> NSTA: NO_ALARM OMSL: supervisory ONAM: On OSV : NO_ALARM
> OUT : INST_IO @asyn(testAPD,0,1)CLUTCH PACT: 0 PHAS: 0
> PINI: NO PRIO: LOW PUTF: 0 RBV : 0
> RPRO: 0 RVAL: 0 SCAN: Passive SDIS: CONSTANT
> SDLY: -1 SEVR: INVALID SIML: CONSTANT SIMM: NO
> SIMS: NO_ALARM SIOL: CONSTANT SSCN: <nil> STAT: UDF
> TIME: <undefined> TPRO: 1 TSE : 0 TSEL: CONSTANT
> UDF : 1 UDFS: INVALID VAL : 0 ZNAM: Off
> ZSV : NO_ALARM
> epicsThreadSleep(3)
> cbLow: dbProcess of 'testAPD:scope1:Clutch'
> 2021/05/29 10:03:52.566 processBo record=testAPD:scope1:Clutch, udf=0
> 2021/05/29 10:03:52.566 processBo record=testAPD:scope1:Clutch, calling recGblSetSevr status=0, severity=0
> date
> 2021/05/29 10:03:54.073656
> dbpr testAPD:scope1:Clutch 2
> ACKS: NO_ALARM ACKT: YES ASG : BKPT: 00
> COSV: NO_ALARM DESC: DISA: 0 DISP: 0
> DISS: NO_ALARM DISV: 1 DOL : CONSTANT DTYP: asynInt32
> EVNT: FLNK: CONSTANT HIGH: 0
> IVOA: Continue normally IVOV: 0 LCNT: 0
> MASK: 0 NAME: testAPD:scope1:Clutch NSEV: NO_ALARM
> NSTA: NO_ALARM OMSL: supervisory ONAM: On OSV : NO_ALARM
> OUT : INST_IO @asyn(testAPD,0,1)CLUTCH PACT: 0 PHAS: 0
> PINI: NO PRIO: LOW PUTF: 0 RBV : 0
> RPRO: 0 RVAL: 1 SCAN: Passive SDIS: CONSTANT
> SDLY: -1 SEVR: INVALID SIML: CONSTANT SIMM: NO
> SIMS: NO_ALARM SIOL: CONSTANT SSCN: <nil> STAT: UDF
> TIME: 2021-05-29 10:03:52.565900993 TPRO: 1 TSE : 0
> TSEL: CONSTANT UDF : 0 UDFS: INVALID VAL : 1
> ZNAM: Off ZSV : NO_ALARM
> epicsThreadSleep(3)
> cbLow: dbProcess of 'testAPD:scope1:Clutch'
> 2021/05/29 10:03:54.566 processBo record=testAPD:scope1:Clutch, udf=0
> 2021/05/29 10:03:54.566 processBo record=testAPD:scope1:Clutch, calling recGblSetSevr status=0, severity=0
> date
> 2021/05/29 10:03:57.073942
> dbpr testAPD:scope1:Clutch 2
> ACKS: NO_ALARM ACKT: YES ASG : BKPT: 00
> COSV: NO_ALARM DESC: DISA: 0 DISP: 0
> DISS: NO_ALARM DISV: 1 DOL : CONSTANT DTYP: asynInt32
> EVNT: FLNK: CONSTANT HIGH: 0
> IVOA: Continue normally IVOV: 0 LCNT: 0
> MASK: 0 NAME: testAPD:scope1:Clutch NSEV: NO_ALARM
> NSTA: NO_ALARM OMSL: supervisory ONAM: On OSV : NO_ALARM
> OUT : INST_IO @asyn(testAPD,0,1)CLUTCH PACT: 0 PHAS: 0
> PINI: NO PRIO: LOW PUTF: 0 RBV : 0
> RPRO: 0 RVAL: 0 SCAN: Passive SDIS: CONSTANT
> SDLY: -1 SEVR: NO_ALARM SIML: CONSTANT SIMM: NO
> SIMS: NO_ALARM SIOL: CONSTANT SSCN: <nil> STAT: NO_ALARM
> TIME: 2021-05-29 10:03:54.565963934 TPRO: 1 TSE : 0
> TSEL: CONSTANT UDF : 0 UDFS: INVALID VAL : 0
> ZNAM: Off ZSV : NO_ALARM
>
> Note that the first time the record processes it has indeed set udf=0 and called recGblSetSevr with status=0, severity=0. Yet for some reason the record STAT and SEVR fields are UDF and INVALID.
>
> I am having a hard time seeing that I am doing something wrong in asyn.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or unsubscribe.
>
- Navigate by Date:
- Prev:
RE: Display Only Lock and/or pw protection for Phoebus Stainer Tom via Tech-talk
- Next:
React Automation Studio V3.0.0 wduckitt via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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:
Re: Epics MODbus driver, can this be run as a MODbus Slave? Mark Rivers via Tech-talk
- Next:
React Automation Studio V3.0.0 wduckitt via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
| 
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·