Experimental Physics and
Industrial Control System

Hi Vikram,

If you want to pass a mask to the mbbi record you must use the asynUInt32Digital device support, not asynInt32.

Your message only had a 3-lines from the asynDriver manual.  Here is a more complete section

********************************************************************************

The support uses the following conventions for DTYP and INP. OUT fields are the same as INP.

    field(DTYP,"asynXXX")

    field(INP,"@asyn(portName,addr,timeout)drvParams")

     or

    field(INP,"@asynMask(portName,addr,mask,timeout)drvParams")

where

• XXX - The name of the type of interface supported.
• portName - The name of the port.
• addr - The address. If addr is not specified the default is 0.
• mask - This is for devAsynUInt32Digital. It is also used by devAsynInt32 to specify the number of bits of the hardware device for drivers that do not support getBounds().
• timeout - The timeout value for asynUser.timeout. If not specified the default is 1.0.
• drvParams - This is passed to the low level driver via the asynDrvUser interface. It is optional.

********************************************************************************

Note that for “mask” it says:

“It is also used by devAsynInt32 to specify the number of bits of the hardware device for drivers that do not support getBounds().”

So the purpose of the “mask” parameter in devAsynInt32 is different from the use in the devAsynUInt32Digital.  For asynInt32 it is intended to be used for drivers than cannot know how many bits a device like an A/D or D/A converter has, and so cannot implement the asynInt32::getBounds() function.  The Modbus driver is an example, since it is generic and cannot know what type of A/D or D/A is in use at a particular Modbus address.

For masking bits with the mbbo or mbbi record you should use the asynUInt32Digital interface and device support.

However, I do not understand why you got the error message you did.  I just tested it, and it actually let me use the asynMask notation with the asynInt32 interface with no error message.  Here is the output of dbpr on such a record:

epics> dbpr 13SIM1:cam1:SimMode_RBV 10

ACKS: NO_ALARM      ACKT: YES           ASG:                ASP: (nil)         

BKPT: 00            COSV: NO_ALARM      DESC:               DISA: 0            

DISP: 0             DISS: NO_ALARM      DISV: 1             DPVT: 0x958cd28    

DSET: 0x85bdc7c     DTYP: asynInt32     EIST:               EISV: NO_ALARM     

EIVL: 0x0           ELST:               ELSV: NO_ALARM      ELVL: 0x0          

EVNT: 0             FFST:               FFSV: NO_ALARM      FFVL: 0x0          

FLNK:CONSTANT 0     FRST:               FRSV: NO_ALARM      FRVL: 0x0          

FTST:               FTSV: NO_ALARM      FTVL: 0x0           FVST:              

FVSV: NO_ALARM      FVVL: 0x0          

INP:INST_IO @asynMask(SIM1,0,12,1)SIM_MODE                  LALM: 1            

LCNT: 0             LSET: 0x960d9c8     MASK: 4294967295   

MLIS: 00 00 00 00 00 00 00 00 00 00 00 00                   MLOK: 18 b9 13 09  

MLST: 1             NAME: 13SIM1:cam1:SimMode_RBV           NIST:              

NISV: NO_ALARM      NIVL: 0x0           NOBT: 0             NSEV: NO_ALARM     

NSTA: NO_ALARM      ONST: Peaks         ONSV: NO_ALARM      ONVL: 0x1          

ORAW: 1             PACT: 0             PHAS: 0             PINI: NO           

PPN: (nil)          PPNR: (nil)         PRIO: LOW           PROC: 0            

PUTF: 0             RDES: 0x8e01738     RPRO: 0             RSET: 0x85be860    

RVAL: 1             SCAN: I/O Intr      SDEF: 1             SDIS:CONSTANT      

SEVR: NO_ALARM      SHFT: 0             SIML:CONSTANT       SIMM: NO           

SIMS: NO_ALARM      SIOL:CONSTANT       SPVT: 0x97115b8     STAT: NO_ALARM     

SVAL: 0             SVST:               SVSV: NO_ALARM      SVVL: 0x0          

SXST:               SXSV: NO_ALARM      SXVL: 0x0           TEST:              

TESV: NO_ALARM      TEVL: 0x0           THST:               THSV: NO_ALARM     

THVL: 0x0           TIME: 2014-11-17 15:19:03.041359713     TPRO: 0            

TSE: 0              TSEL:CONSTANT       TTST:               TTSV: NO_ALARM     

TTVL: 0x0           TVST:               TVSV: NO_ALARM      TVVL: 0x0          

TWST:               TWSV: NO_ALARM      TWVL: 0x0           UDF: 0             

UNSV: NO_ALARM      VAL: 1              ZRST: LinearRamp    ZRSV: NO_ALARM     

ZRVL: 0x0

Note that the INP field is “INST_IO @asynMask(SIM1,0,12,1)SIM_MODE” and the DTYP field is “asynInt32”.  I did not get any error when booting the IOC or changing the record.  However, in this case the mask will be ignored, the devAsynInt32 device support ignores the mask for mbbi and mbbo records.

I suspect you are getting the error message because parseLink put that message in your pasynUser->errorMessage field, and it was never printed (because the parseLink message is not really an error in this case).  Sometime later your driver produced an error but did not replace pasynUser->errorMessage, so you ended up with a bogus error message.

Mark

    field(INP,"@asyn(portName,addr,timeout) drvParams")

     or

    field(INP,"@asynMask(portName,addr,nbits,timeout) drvParams")