Re: asynInt32 device support for mbbiDirect record for representing bitmasks

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Hi Jakub,

Here are a few drivers that call setUIntDigitalParam:

https://github.com/epics-modules/measComp/blob/0db360662e2d578c12de203adf1ea29eec416d47/measCompApp/src/drvMultiFunction.cpp#L1159

https://github.com/epics-modules/measComp/blob/0db360662e2d578c12de203adf1ea29eec416d47/measCompApp/src/drvUSBCTR.cpp#L1506

https://github.com/epics-modules/LabJack/blob/703e23674992c2d211f2e2181042f38d2567e47f/LabJackApp/src/LabJackDriver.cpp#L1568

Mark

---

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Monday, February 2, 2026 12:38 PM
To: Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov>; Wlodek, Jakub <jwlodek at bnl.gov>
Subject: Re: asynInt32 device support for mbbiDirect record for representing bitmasks

 

Hi Jakub,

• I'd have to use asynUInt32Digital - I tried this, but it's value did not seem to update with setIntegerParam like I'd have expected

You use setUIntDigitalParam(), not setIntegerParam().

https://epics-modules.github.io/asyn/doxygenHTML/classasyn_port_driver.html#a0e6e8fe3f13fb4226ab9be56af5c560e

• # Add a mask argument, since asynUInt32Digital requires asynMask here. Is 0x4 correct if I have a 4 bit bitmask as an example?

No, assuming it is the low-order 4 bits then the mask is 0xF.

Mark

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Wlodek, Jakub via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, February 2, 2026 9:29 AM
To: Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov>
Subject: asynInt32 device support for mbbiDirect record for representing bitmasks

 

Hi all,

I am writing an asynPortDriver for a device that has many possible configurations, and as such upon connection I query the device to see which features it currently has enabled, and I store this information in a bitmask (to avoid making many records for all of the possible features). I'd still like to be able to access each bit easily from clients outside of the IOC without needing bit manipulation/logic, so it seems to me that an mbbiDirect record is a good option, since I can read the individual bits with the B0 - B* fields.

I currently have this working with two records - one an ai with asynInt32 device support, which forward-links to an mbbiDirect Soft Channel:

record(ai, "$(P)$(R)FeaturesBitmaskRaw_RBV"){

    field(DESC, "Features bitmask raw rb")

    field(DTYP, "asynInt32")

    field(INP, "@asyn($(PORT),$(ADDR),$(TIMEOUT))XSPD_FEAT_BITMASK")

    field(FLNK, "$(P)$(R)FeaturesBitmask_RBV")

    field(SCAN, "I/O Intr")

}

record(mbbiDirect, "$(P)$(R)FeaturesBitmask_RBV") {

    field(DESC, "Features bitmask rb")

    field(INP, "$(P)$(R)FeaturesBitmaskRaw_RBV NPP NMS")

    field(B0, "0")

    ...

    field(DTYP, "Soft Channel")

    field(SCAN, "I/O Intr")

}

I'm wondering if there is a way to do this more directly - meaning that I can set the value of the mbbiDirect from my asynPortDriver directly. It seems to me that asynInt32 does not work with mbbiDirect, and I'd have to use asynUInt32Digital - I tried this, but it's value did not seem to update with setIntegerParam like I'd have expected. I had it set up like this:

record(mbbiDirect, "$(P)$(R)FeaturesBitmask_RBV") {

    field(DESC, "Features bitmask rb")

    # Add a mask argument, since asynUInt32Digital requires asynMask here. Is 0x4 correct if I have a 4 bit bitmask as an example?

    field(INP, "@asynMask($(PORT),$(ADDR),0x4,$(TIMEOUT))XSPD_FEAT_BITMASK")

    field(B0, "0")

    ...

    field(DTYP, "asynUInt32Digital")

    field(SCAN, "I/O Intr")

}

createParam(ADXSPDModule_FeatBitmaskString, asynParamUInt32Digital, &ADXSPDModule_FeatBitmask);

int featureBitmask = // Get my features bitmask from the hardware

setInteger(ADXSPDModule_FeatBitmask, featureBitmask);

but the record does not appear to be processed (UDF_ALARM) on IOC startup. When I switch to my two-record-solution, I just change the second argument of createParam to asynParamInt32 to match the device support, and I get a correct value read back. Am I missing something obvious? I also don't see any issues in the IOC shell during startup, and the code compiles OK.

As an aside, it would be nice if I could also give names to each of the bits in an mbbiDirect/mbboDirect, like with mbbo/mbbi record values. This would be helpful for creating UIs and other client programs. From the record reference manual, I don't see any fields that would allow for this, is that correct?

Thanks!

Jakub