Hi Torsten,
On May 27, 2021, at 10:25 AM, Torsten Bögershausen via Tech-talk < tech-talk at aps.anl.gov> wrote:
EPICS base is here:
commit 745d2755f91eb7ae2922f39f5414fdc1e4d45fab (HEAD, tag: R7.0.4)
And asyn here:
commit 0c70f16c4b27f6717920f40e8c8e0fb2182cac64 (tag: R4-41)
If someone says, please use to the latest, I will update everything.
But until this, I keep it as it is.
I don’t believe an upgrade to Base would make any difference, and I’m not aware that Asyn has changed there. The behavior you’re reporting seems normal to me – unless the fields are set in a .db file all records will start with STAT=UDF and SEVR=(*UDFS)
before iocInit calls the record type’s init_record() routine. The record won’t subsequently update its alarm status/severity to clear the alarm until it actually processes. I don’t believe Asyn’s initial readback (which may be asynchronous in your case, I’m
not quite sure what happens there) is actually causing the bo record to process, even though it does set VAL and clear UDF – Mark, please correct me if I’m wrong.
The normal way that record alarms work is that the calls to recGblSetSevr() and friends as found in the checkAlarms() routine only set the record’s NSTA and NSEV fields. Towards the end of record processing the process() routine (or an internal routine
like monitor() which it calls) calls recGblResetAlarms(). That activates any alarms which have been triggered by moving NSTA to STAT and NSEV to SEVR, and then resets both NSEV and NSTA to 0 for the next round.
So in your case the Asyn readback clears UDF, but the record has to be processed before that change can take effect. What you could do is set the STAT and SEVR fields to zero in your .db file, although it wouldn’t reflect any errors that occurred during
the readback process (disconnected device etc.).
HTH,
- Andrew
On 5/27/21 5:19 PM, Mark Rivers wrote:
I'd like to help understand and/or fix this if it is a problem with asyn.
What versions of base and asyn are you using?
Mark
________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Torsten Bögershausen via Tech-talk <tech-talk at aps.anl.gov>
Sent: Thursday, May 27, 2021 9:35 AM
To: Ralph Lange; EPICS Tech Talk
Subject: Re: asyn bo record staying in INVALID DRIVER UDF
Hej again,
the alaram goes away, if the record is processed one more time.
We don't need to write to the PV, it is enough to disconnect-
and re-connect. Then the asyn callbacks will trigger, and the alarm
goes away.
This code:
IOC:m6-OpenClutchdevAsynInt32.c: static long initBo(boRecord *pr)
{
devPvt *pPvt;
int status;
epicsInt32 value = 0xFFFFFFFF;
status = initCommon((dbCommon *)pr,&pr->out,
processCallbackOutput,interruptCallbackOutput,
interruptCallbackEnumBo,
2, (char*)&pr->znam, NULL, &pr->zsv);
fprintf(stdout, "%s/%s:%d %s status=%d\n",
__FILE__, __FUNCTION__, __LINE__,
pr->name, (int)status);
if (status != INIT_OK) return status;
pPvt = pr->dpvt;
/* Read the current value from the device */
status = pasynInt32SyncIO->read(pPvt->pasynUserSync,
&value, pPvt->pasynUser->timeout);
fprintf(stdout, "%s/%s:%d %s status=%d value=0x%X\n",
__FILE__, __FUNCTION__, __LINE__,
pr->name, (int)status, value);
if (status == asynSuccess) {
pr->rval = value;
return INIT_OK;
}
return INIT_DO_NOT_CONVERT;
}
gives this prints:
../../asyn/devEpics/devAsynInt32.c/initBo:1203 IOC:IOC:m6-OpenClutch
status=0
../../asyn/devEpics/devAsynInt32.c/initBo:1211 IOC:IOC:m6-OpenClutch
status=10 value=0x0
So that the poller() hasn't been able to talk to the controller (yet).
And later, when the callback comes:
static long processBo(boRecord *pr)
{
devPvt *pPvt = (devPvt *)pr->dpvt;
int status;
fprintf(stdout, "%s/%s:%d %s pPvt->newOutputCallbackValue=%d\n",
__FILE__, __FUNCTION__, __LINE__,
pr->name, pPvt->newOutputCallbackValue);
epicsMutexLock(pPvt->devPvtLock);
if(pPvt->newOutputCallbackValue && getCallbackValue(pPvt)) {
/* We got a callback from the driver */
fprintf(stdout, "%s/%s:%d %s pPvt->result.status=%d\n",
__FILE__, __FUNCTION__, __LINE__,
pr->name, pPvt->result.status);
if (pPvt->result.status == asynSuccess) {
pr->rval = pPvt->result.value;
pr->val = (pr->rval) ? 1 : 0;
pr->udf = 0;
}
../../asyn/devEpics/devAsynInt32.c/processBo:1225 IOC:m6-OpenClutch
pPvt->newOutputCallbackValue=1
../../asyn/devEpics/devAsynInt32.c/processBo:1232 IOC:m6-OpenClutch
pPvt->result.status=0
and here udf is set to zero.
But the alarm stays.
I don't know if this is a possible issue in base, asyn or somewhere else.
BR
/Torsten
On 5/27/21 4:12 PM, Torsten Bögershausen via Tech-talk wrote:
Hej Ralph,
I think it is the same-
camonitor, second round:
IOC:m6-OpenClutch 2021-05-27 15:51:06.243006 Closed UDF INVALID
IOC:m6-OpenClutch.UDF 2021-05-27 15:51:06.243006 0 UDF INVALID
IOC:m6-OpenClutch.STAT 2021-05-27 15:51:06.243006 UDF UDF INVALID
IOC:m6-OpenClutch.SEVR 2021-05-27 15:51:06.243006 INVALID UDF INVALID
[snipped warnings because of multihomed]
And this is dbpr IOC:m6-OpenClutch 10
ACKS: NO_ALARM ACKT: YES ASG : ASP : PTR (nil)
BKLNK: ELL 0 [(nil) .. (nil)] BKPT: 00 COSV: NO_ALARM
DESC: motor DISA: 0 DISP: 0 DISS: NO_ALARM
DISV: 1 DOL : CONSTANT DPVT: PTR 0x1030ca0
DSET: PTR 0x7fb1485072c0 DTYP: asynInt32 EVNT:
FLNK: CONSTANT HIGH: 0 IVOA: Continue normally
IVOV: 0 LALM: 0 LCNT: 0 LSET: PTR
0xf143d0
MASK: 0 MLIS: ELL 4 [0x7fb11802fb38 .. 0x7fb11802fc40]
MLOK: b0 e8 fa 00 00 00 00 00 MLST: 0
NAME: IOC:m6-OpenClutch NSEV: NO_ALARM
NSTA: NO_ALARM OLDSIMM: NO OMSL: supervisory ONAM: Open
ORAW: 0 ORBV: 0 OSV : NO_ALARM
OUT : INST_IO @asyn(MCU1,6)OpenClutch PACT: 0 PHAS: 0
PINI: NO PPN : PTR (nil) PPNR: PTR (nil) PRIO: LOW
PROC: 0 PUTF: 0 RBV : 0 RDES: PTR
0xb6e100
RPRO: 0 RPVT: PTR 0x1030c70 RSET: PTR 0x7fb146f9e860
RVAL: 0 SCAN: Passive SDIS: CONSTANT SDLY: -1
SEVR: INVALID SIML: CONSTANT SIMM: NO SIMPVT: PTR
(nil)
SIMS: NO_ALARM SIOL: CONSTANT SPVT: PTR (nil) SSCN: <nil>
STAT: UDF TIME: 2021-05-27 15:51:06.243005887 TPRO: 0
TSE : 0 TSEL: CONSTANT UDF : 0 UDFS: INVALID
VAL : 0 WDPT: PTR (nil) ZNAM: Closed ZSV : NO_ALARM
/Torsten
On 5/27/21 2:21 PM, Ralph Lange via Tech-talk wrote:
Hi Torsten,
On Thu, 27 May 2021 at 12:53, Torsten Bögershausen via Tech-talk
<tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>> wrote:
Asyn-Experts,
I am chasing an interesting problem.
For a motor, we have a clutch that can be opened under very
special conditions, say service mode.
We define it like this:
[...]
The alarm seem to go away, if the record is processed one more time.
(by disconnecting the IOC from the controller and re-establishing the
connection).
Is this a know phenomena ?
Anything that can be done ?
How does the setup behave when using Channel Access?
(To see if it is a problem on the ASYN side or the QSRV side of the
database.)
Cheers,
~Ralph
--
Complexity comes for free, simplicity you have to work for.
|