Re: mbbo with 32 choices

["Le, An via Tech-talk" <tech-talk at aps.anl.gov>]

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.

 

The line in question:

 

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>
Sent: Friday, April 21, 2023 11:31 AM
To: Le, An <anle at slac.stanford.edu>; 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.