Experimental Physics and
Industrial Control System

Folks,

 

Jueri Tagger from BNL says the asynPortDriver::readInt16Array method in asyn R4-44-1 is not working for him.  He says the readInt16Array method is not being called when the associated waveform record processes.

 

It works fine for me in the asyn testErrorsApp test program.

 

This is dbpr on my waveform record:

 

epics> dbpr testErrors:WfInt16In 4

ACKS: NO_ALARM      ACKT: YES           AMSG:               APST: Always

ASG :               ASP : PTR (nil)     BKLNK: ELL 0 [(nil) .. (nil)]

BKPT: 00            BPTR: PTR 0x9e9d40  BUSY: 0             DESC:

DISA: 0             DISP: 0             DISS: NO_ALARM      DISV: 1

DPVT: PTR 0xa0f080  DSET: PTR 0x7f699647ece0

DTYP: asynInt16ArrayIn                  EGU :               EVNT:

FLNK: CONSTANT      FTVL: SHORT         HASH: 0             HOPR: 0

INP : INST_IO @asyn(PORT1,0,1)INT16_ARRAY_VALUE             LCNT: 0

LOPR: 0             LSET: PTR 0x9d8b40

MLIS: ELL 4 [0x7f694802f580 .. 0x7f694802f478]

MLOK: 10 9d 9e 00 00 00 00 00           MPST: Always

NAME: testErrors:WfInt16In              NAMSG:              NELM: 100

NORD: 100           NSEV: NO_ALARM      NSTA: NO_ALARM      OLDSIMM: NO

PACT: 0             PHAS: 0             PINI: NO            PPN : PTR (nil)

PPNR: PTR (nil)     PREC: 0             PRIO: LOW           PROC: 0

PUTF: 0             RARM: 0             RDES: PTR 0x994010  RPRO: 0

RSET: PTR 0x7f69961c09e0                SCAN: 1 second      SDIS: CONSTANT

SDLY: -1            SEVR: NO_ALARM      SIML: CONSTANT      SIMM: NO

SIMPVT: PTR (nil)   SIMS: NO_ALARM      SIOL: CONSTANT      SPVT: PTR 0xa29f60

SSCN: <nil>         STAT: NO_ALARM      TIME: 2023-03-21 17:31:36.000000000

TPRO: 0             TSE : -2            TSEL: CONSTANT      UDF : 0

UDFS: INVALID       UTAG: 0             VAL : PTR (nil)

 

This is what he sees for his record:

 

epics> dbpr("SR-RF{CFC:E-NA}Val:R-Wf", 4)

ACKS: INVALID       ACKT: YES           AMSG:               APST: Always

ASG :               ASP : PTR 0x1a4fda0 BKLNK: ELL 1 [0x16482a0 .. 0x16482a0]

BKPT: 00            BPTR: PTR 0x19267e0 BUSY: 0             DESC:

DISA: 0             DISP: 0             DISS: NO_ALARM      DISV: 1

DPVT: PTR 0x1a15e30 DSET: PTR 0x7ff1f6d21f00

DTYP: asynInt16ArrayIn                  EGU :               EVNT:

FLNK: DB_LINK SR-RF{CFC:E-NA}Val:Wf-Calc                    FTVL: SHORT

HASH: 0             HOPR: 0             INP : INST_IO @asyn(rfport,0)NA I

LCNT: 0             LOPR: 0             LSET: PTR 0x16f49e0

MLIS: ELL 0 [(nil) .. (nil)]            MLOK: b0 67 92 01 00 00 00 00

MPST: Always        NAME: SR-RF{CFC:E-NA}Val:R-Wf           NAMSG:

NELM: 128           NORD: 0             NSEV: NO_ALARM      NSTA: NO_ALARM

OLDSIMM: NO         PACT: 0             PHAS: 0             PINI: NO

PPN : PTR (nil)     PPNR: PTR (nil)     PREC: 0             PRIO: LOW

PROC: 1             PUTF: 0             RARM: 0             RDES: PTR 0x1206680

RPRO: 0             RSET: PTR 0x7ff1f5783960                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: <nil>

TIME: 2023-03-22 11:45:16.791763817     TPRO: 1             TSE : 0

TSEL: CONSTANT      UDF : 0             UDFS: INVALID       UTAG: 0

VAL : PTR (nil)

epics>

 

I notice that on his record the MLIS,SPVT, and STAT fields are <nil> whereas that is not the case for my record.

 

Is this an indication of a problem like perhaps memory corruption in his driver, or can that be normal?

 

Thanks,

Mark

 

 

 

 

 

-- 
Complexity comes for free, Simplicity you have to work for.