Re: mbbo with 32 choices

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

On 12/4/23 08:57, Le, An via Tech-talk wrote:
> Hi Andrew,
>
> Revising this issue, I was wondering if the MAX_ENUM_STATES for channel access could be increased from 16 to 32 for the next release of EPICS base. This would allow us to design reusable mbbo/i records without adding any extra string fields to circumvent the 16-state limit.
Unfortunately no, changing MAX_ENUM_STATES would constitute a backwards incompatible protocol change to the Channel Access protocol.

What is possible now with PV Access, if a little awkward, is to use the PVXS group feature to map an array of STRING of any length.

https://github.com/mdavidsaver/pvxs/blob/0bddf561eb2bfdef673476b5398365f83f8e3ead/test/ntenum.db#L19

As I think about it, it should be possible to change/extend the internal dbAccess.h API to expose arbitrary length
enumerations.  By changing DB_MAX_CHOICES and/or adding a new DBR* to fetch choices in a different way.  eg. fetch
the number of enumerations, and then individually by index.

https://github.com/epics-base/epics-base/blob/d9d35a4eab601fd7e6113415574d9e255bcb6967/modules/database/src/ioc/db/dbAccessDefs.h#L123-L126


> The line in question:
>
> https://github.com/epics-base/epics-base/blob/d9d35a4eab601fd7e6113415574d9e255bcb6967/modules/ca/src/client/db_access.h#L32 <https://github.com/epics-base/epics-base/blob/d9d35a4eab601fd7e6113415574d9e255bcb6967/modules/ca/src/client/db_access.h#L32>
>
> Thanks,
>
> An
>
> *From: *Andrew Johnson <anj at anl.gov>
> *Date: *Friday, April 21, 2023 at 2:38 PM
> *To: *Le, An <anle at slac.stanford.edu>, tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
> *Subject: *Re: mbbo with 32 choices
>
> Hi,
>
> Since this is being used to output a string and alarm severity from the IOC and you aren't expecting the mbbo to be set by a user picking one of the choices, I recommend that you consider replacing your mbbo with a stringin record, and have the subroutine generate that string instead of the status value. Alternatively you could use an aSub record for the subroutine and configure one of its output fields as a string which the code would write to directly.
>
> - Andrew
>
> On 4/21/23 4:24 PM, Le, An wrote:
>
>     Hi Andrew,
>
>     This channel is a soft PV. A subroutine in our application accepts a bitmask representing device status and calculates the worst-case status, encoded as below. We’re looking to add another status description, hence the need for more than 16 options.
>
>     record(mbbo, "$(DEV):STATMSG") {
>
>        field(DESC, "Status Message - worst case")
>
>        field(NOBT, "16")
>
>        field(ZRST, "Good")
>
>        field(ONST, "BCON Warning")
>
>        field(TWST, "Offline")
>
>        field(THST, "PAU Ctrl")
>
>        field(FRST, "Turned Off")
>
>        field(FVST, "Not Degaus'd")
>
>        field(SXST, "Not Cal'd")
>
>        field(SVST, "Feedback Ctrl")
>
>        field(EIST, "PS Tripped")
>
>        field(NIST, "DAC Error")
>
>        field(TEST, "ADC Error")
>
>        field(ELST, "Not Stdz'd")
>
>        field(TVST, "Out-of-Tol")
>
>        field(TTST, "BAD Ripple")
>
>        field(FTST, "BAD BACT")
>
>        field(FFST, "No Control")
>
>        field(ZRSV, "NO_ALARM")
>
>        field(ONSV, "MINOR")
>
>        field(TWSV, "NO_ALARM")
>
>        field(THSV, "MINOR")
>
>        field(FRSV, "MAJOR")
>
>        field(FVSV, "MINOR")
>
>        field(SXSV, "MINOR")
>
>        field(SVSV, "NO_ALARM")
>
>        field(EISV, "MAJOR")
>
>        field(NISV, "MAJOR")
>
>        field(TESV, "MAJOR")
>
>        field(ELSV, "MINOR")
>
>        field(TVSV, "MAJOR")
>
>        field(TTSV, "MINOR")
>
>        field(FTSV, "MAJOR")
>
>        field(FFSV, "NO_ALARM")
>
>        field(OMSL, "closed_loop")
>
>        field(FLNK, "$(DEV):UNAVAILGO")
>
>        field(DOL, "$(DEV):STATCTRLSUB.W")
>
>     }
>
>     Thanks,
>
>     An Le
>
>     SLAC National Accelerator Laboratory
>
>     *From:*Andrew Johnson <anj at anl.gov> <mailto:anj at anl.gov>
>     *Sent:* Friday, April 21, 2023 11:31 AM
>     *To:* Le, An <anle at slac.stanford.edu> <mailto:anle at slac.stanford.edu>; tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>
>     *Subject:* Re: mbbo with 32 choices
>
>     What kind of client are you wanting to use to control this channel? The Channel Access protocol only supports 16 choices for menu/enum fields.
>
>     The IOC internals and QSRV (PVAccess) should be able to handle up to 30 choices at the moment (DB_MAX_CHOICES in dbDefs.h) but I'm not aware how much if any testing has happened beyond 16 — the dbCommon STAT field does have more than 16 possible states though, so if your client can see the WRITE_ACCESS choice of a .STAT field it may work.
>
>     - Andrew
>
>
>     On 4/21/23 12:41 PM, Le, An via Tech-talk wrote:
>
>         Hello,
>
>         I’m looking for an mbbo-like record type that supports 32 choices instead of 16. Has anyone already written an implementation for this?
>
>         Thanks,
>
>         An Le
>
>         SLAC National Accelerator Laboratory
>
>
>
>
>     -- 
>
>     Complexity comes for free, Simplicity you have to work for.
>
>
>
> --
>
> Complexity comes for free, Simplicity you have to work for.