Re: Naming bits in an mbbiDirect record

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

Hi Andrew,

We do use device support that allows fetching multiple bits from the same address, but as you mentioned, fetching the whole word at once then shifting the bits afterwards is more efficient.

In fact, we don't even need to do the shift operation again, as mbbiDirect already takes care of that and provides access to the bits through fields like .B1, .B2, .B3, etc. We generally just link to them via INLINK to the bi.

Even so, I think the point still remains. IMO, for the scenario where one does not need alarm settings for each bit, the approach I and others on this thread mentioned are all workarounds to the fact that this feature is missing. The record already has the full word at once, and each bit already parsed, the only missing info is what each of them mean.

I am happy to try working on a PR to that feature, as long as it is agreed as a nice one to have. Spending time on it if it is doomed before the start would be a shame.

Best regards,

André Favoto

---

From: Johnson, Andrew N. <anj at anl.gov>
Sent: Friday, 04 September 2026 19:16:00
To: André Favoto <andrefavotto at outlook.com>; EPICS Tech Talk <tech-talk at aps.anl.gov>; Ralph Lange <ralph.lange at gmx.de>
Subject: Re: Naming bits in an mbbiDirect record

 

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.

- Andrew

-- 

Complexity comes for free, Simplicity you have to work for.

On 9/4/26, 4:04 AM, "Tech-talk" <tech-talk-bounces at aps.anl.gov> wrote:

I did open an issue some time ago requesting that feature: https://github.com/epics-base/epics-base/issues/846

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