Experimental Physics and
Industrial Control System

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,

        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:

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;
        }

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

Replies:

Re: asyn bo record staying in INVALID DRIVER UDF Mark Rivers via Tech-talk

References:

asyn bo record staying in INVALID DRIVER UDF Torsten Bögershausen via Tech-talk

Re: asyn bo record staying in INVALID DRIVER UDF Ralph Lange via Tech-talk

Re: asyn bo record staying in INVALID DRIVER UDF Torsten Bögershausen via Tech-talk

Navigate by Date:

Prev: Re: asyn bo record staying in INVALID DRIVER UDF Torsten Bögershausen via Tech-talk

Next: Re: asyn bo record staying in INVALID DRIVER UDF Mark Rivers 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: asyn bo record staying in INVALID DRIVER UDF Torsten Bögershausen via Tech-talk

Next: Re: asyn bo record staying in INVALID DRIVER UDF Mark Rivers 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