Re: Naming bits in an mbbiDirect record

[André Favoto via Tech-talk <tech-talk at aps.anl.gov>]

Correction:

In "from a single PV" I meant "from a single record".

---

From: André Favoto <andrefavotto at outlook.com>
Sent: Monday, 07 September 2026 12:46:00
To: EPICS Tech Talk <tech-talk at aps.anl.gov>; Ralph Lange <ralph.lange at gmx.de>
Subject: Re: Naming bits in an mbbiDirect record

 

By optional I meant that they could be empty strings, sorry for not being clear. Something like these (copied from mbbi):

Field	Summary	Type	DCT	Default	Read	Write	CA PP
ZRST	Zero String	STRING [26]	Yes		Yes	Yes	Yes
ONST	One String	STRING [26]	Yes		Yes	Yes	Yes
TWST	Two String	STRING [26]	Yes		Yes	Yes	Yes

I think 26 chars like the limit on mbbi state strings should be enough (although they serve a different purpose).

But you are right that they would allocate sizeof(STRING[26]) regardless of content, so defining it or not wouldn't make a difference and could impact memory-constrained hardware, indeed. Optional was a wrong word on my end.

I'm not sure if I understand the point of changing the PV name though. I am proposing the creation of an extra field that defines a label. Something like the following:

record(mbbiDirect, "myStatusBits)") {
    field(DTYP, "asynUInt32Digital")
    field(DESC, "32 bit status")
    field(INP,  "@asynMask($(ASYN_PORT),0 0x3FFFFFF)Status")
    field(SCAN, "I/O Intr")
    field(B0NM, "B0 name")
    field(B1NM, "B1 name")
    (...)

}

That on pvget would look like:

pvget  myStatusBits.B1
myStatusBits.B1 2026-09-07 12:28:41.121  (1) B1 name

(not needing to have two strings for each, like ZNAM and ONAM, just a plain label).

If rewiring happens, one would need to change BxNM fields with their names, yes. But for the bi records, we would need at least to change which of the bits the record looks to on it's input link, right?

Say, record(bi, "SomeState") { field(INP, "myStatusBits.B1 CP") } would need to be modified if the information is no longer on B1 or myStatusBits. Perhaps ZNAM and ONAM too, if they are not generic like ON/OFF.

Going further, if these bit names are defined dynamically the PLC for example, with asyn we could have something like:

record(mbbiDirect, "myStatusBits") {
    field(DTYP, "asynUInt32Digital")
    field(DESC, "32 bit status")
    field(INP,  "@asynMask($(ASYN_PORT),0 0x3FFFFFF)Status")
    field(SCAN, "I/O Intr")
}

record(stringin, "$(P)$(R)#BitNam0") {
    field(DTYP, "asynOctetRead")
    field(DESC, "Status bit 0 name")
    field(INP,  "@asyn($(ASYN_PORT),0)Status_NamBit0")
    field(SCAN, "I/O Intr")
    field(FLNK, "$(P)$(R)#BitNam0Out")
}

record(stringout, "$(P)$(R)#BitNam0Out") {
    field(DOL, "$(P)$(R)BitNam0")
    field(OUT, "$(P)$(R).B0NM PP")
}

This would ensure that users can get a full overview of all statuses like this from a single PV, instead of 33 (1+NBits):

(The screen above was composed by looking at myStatusBits + individual stringin records with each name).

Best Regards,

André Favoto

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, September 7, 2026 11:45
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Naming bits in an mbbiDirect record

 

On Mon, 7 Sept 2026 at 10:39, André Favoto <andrefavotto at outlook.com> wrote:

Not to be pedantic, but for me it is still not clear what is/are the point(s) against the bit name fields...

Having 32 full extra binary records feels like extra memory footprint than 32 optional string fields of 20 chars or so, if that is the concern.

There are no optional fields in the EPICS database.

Assuming the normal EPICS string length of 40 bytes, adding 32 fields would add more than a kByte to every existing instance of mbbiDirect records, independent of using the labels or not, also on embedded systems with limited memory.

Adding bi records for every used bit is the intended and normal use of the mbbiDirect record type. mbbiDirect is a slim implementation of a status word, the bi records have all per-bit configuration: description, value strings for 0 and 1, alarm/severity settings, etc.

Conceptual aspect: In my experience, the address information of a signal is part of its implementation and should *not* be part of its PV name.

Using your approach, with the mbboDirect bit field as the PV name, any rewiring (changing the address of a specific bit in the status word or moving the bit to another word) will force a change in the PV name, which is a major pain. (Consider how to handle archiver requests across that change.)

If you use bi records for bits, their PV names can properly express meaning/function and are not affected by rewiring or any other implementation changes.

Having the bit names paired to the bit values would still be the natural approach, even after having the info() structures available.

The user is in full control of info item names - you can pair if you want to.

Cheers,
~Ralph