Many device support, e.g. for PLCs, can efficiently handle connecting multiple bi records to different bits in the same memory location of the PLC, and if that's what your configuration looks like I might do that without having the mbbiDirect record at all.
The bi records would address the PLC location and bit; in some cases you might use a PLC address type that directly accesses individual bits, but they might not be as efficient as having the device support fetching the whole word and the individual records
mask out and shift the raw value to get that bit.
On 9/4/26, 4:04 AM, "Tech-talk" <tech-talk-bounces at aps.anl.gov> wrote:
It would be very convenient to have a way to set a label for each bit inside the record.
As a workaround, we have separate PVS like "NameBit1", "NameBit2", etc, which works, but it is as much of a pain as mapping individual bi records.
Having a binary PV for each bit kind of defeats the purpose of using mbbiDirect structure IMO.
There is, of course, the concern of having the individual bit severities that Ralph mentioned on the issue above.
But having one does not block the other, and I don't see how adding labels to the bits would change in any way the severity/alarm handling.
If one needs individual severities/alarms for each bit or combinations of them, then I agree that mapping to separate records is the correct approach.
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: Friday, September 4, 2026 08:59
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Naming bits in an mbbiDirect record
No, not inside the mbbiDirect.
To get the single bit description (and alarm severity/status, and value strings, ...) add a biRecord for each bit and point its input link to the appropriate bit field of the mbbiDirectRecord. If you make that input link CP or CPP, the single bit record will
only process when the value of that bit changes.
Cheers,
~Ralph