|
I see your point about the PV name change; that makes sense.
For the case I used as an example, the bits are not archived. If they were, I agree that they should be isolated to prevent renaming problems.
As I see it, some decisions about "design correctness" are for the engineer to make based on how and when a feature is used, rather than for the tool (EPICS) to prevent it entirely, especially when making one approach available does not prevent using the other.
For example, .EGU can be changed at runtime, say from V/s to mV/s, but if the PV is archived, we shouldn't do that because there is no easy way to correlate the physical meaning of values before and after the change.
Not all features should be used in all cases.
I see the bit names here similarly: they can make the mbbiDirect record self-describing, but that does not imply or force one to use myStatusBits.B1 as the stable PV name for something like "power status".
There are cases where the status word itself is the used interface, especially when looking to operator screens with widgets like "byte monitor" or something similar to what I showed before.
I don't think adding bit names changes the architectural choice between exposing a stable individual signal as a
bi record and exposing an aggregate status word as a mbbiDirect. It would just make the latter self-describing.
I will link this thread to the GH issue for further reference.
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 13:21
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Naming bits in an mbbiDirect record
My conceptual concern is the following:
...
That on pvget would look like:
pvget myStatusBits.B1
...
For a bit signal (e.g., the power status bit of a device), that name is bad.
Once you have to change the implementation (wiring or PLC / software change), your PV name must change - there's no way around that.
This will break all OPI panels that address the single bit signal.
If you want to include the signal in an archiver request, how would the archiver know that myStatusBits.B1 used to be myOtherBits.B5 before a specific date? It doesn't.
Changing PV names is a nightmare for long term support and maintenance of a system.
A power status bit should have a name that carries exactly that information - power status bit. (Mangled through your naming convention, of course.)
If you need to change the INP link to point to a different status word/bit- it is an internal change that clients and archiver don't see - and IMHO shouldn't see.
Your approach of avoiding bi records makes low-level implementation details part of the API, which is wrong.
This is a general argument for using the common architecture with separate bi records and not directly related to description strings.
Cheers,
~Ralph
|