Re: asyn bo record staying in INVALID DRIVER UDF

[Torsten Bögershausen via Tech-talk <tech-talk at aps.anl.gov>]

Hej Mark,
good to hear from you.

EPICS base is here:
commit 745d2755f91eb7ae2922f39f5414fdc1e4d45fab (HEAD, tag: R7.0.4)
Author: Andrew Johnson <anj at anl.gov>
Date:   Thu May 28 18:12:51 2020 -0500

And asyn here:
commit 0c70f16c4b27f6717920f40e8c8e0fb2182cac64 (tag: R4-41)
Author: Mark Rivers <rivers at cars.uchicago.edu>
Date:   Sat Sep 19 14:12:11 2020 -0500
    Update release to R4-41


If someone says, please use to the latest, I will update everything.
But until this, I keep it as it is.

/Torsten


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