Re: Naming bits in an mbbiDirect record

[Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>]

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