Re: mbbo & calcout for drive position management

[Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>]

Hi Dan,

On Thu, 6 Oct 2022 at 20:42, Crisp, Daniel via Tech-talk <tech-talk at aps.anl.gov> wrote:

But I have one a new issue; and still one remaining:

1. The mbbo xxVL fields appear to be ULONG, so the negative positions don't appear to be working correctly; i.e. -11 is shown as 4294967285
   1. Our desired setpoints are both positive & negative. Maybe this is why we were using the calcout. Is there a way around this?

Uh-oh.

I'm sorry. Seems like a wrong interpretation of the problem on my end.

If your values for the different choices are double values, the mbbo can't do the translation. Please go back to your original two-record solution using an mbbo for the choice and a calcout to hold the values.

Here's how I would chain up the two (suggested changes marked):

  record(mbbo, "REA_BTS41:STRIP_D1391:POS_SEL"){

      field(ZRST, "N/A")

      field(ONST, "DLC 500 nm")

      field(TWST, "DLC 2750 nm")

      field(THST, "DLC 3500 nm")

      field(FRST, "DLC 4000 nm")

      field(FLNK, "_REA_BTS41:STRIP_D1391:POS_calc")

      info(autosaveFields, "ZRST ONST TWST THST FRST")

      info(autosaveFields_pass0, "VAL")

  }

  record(calcout, "_REA_BTS41:STRIP_D1391:POS_calc"){

      field(INPA, "REA_BTS41:STRIP_D1391:POS_SEL")

      field(INPB, "90")

      field(INPC, "-11")

      field(INPD, "-44")

      field(INPE, "-77")

      field(INPF, "-110")

      field(CALC, "A==1?C:A==2?D:A==3?E:A==4?F:B")

      field(OUT,  "REA_BTS41:STRIP_D1391:POS_CSET PP")

      field(OOPT,  "On Change")

      info(autosaveFields, "B C D E F")

  }

Btw. You can get very similar behavior when using a seqRecord in "Specified" mode instead of the calcout. Once you have more choices, the seqRecord will provide more input links (choices) and avoid an ugly CALC _expression_. All in all, the seq is probably a tick more appropriate for this problem compared to a calcout, but it's mostly a matter of preference.

Again, sorry for pointing you in the wrong direction. My bad.

1. The mbbo PV & fields appear to be stuck in UDF_ALARM; not just on reboot, but also after making caputs
   1. I tried setting SCAN = "Passive"; I'm not certain this is appropriate, but it didn't seem to help anyways

User facing output records are most often "Passive". This one should be.

I don't see why the mbbo would still be in UDF after you wrote to it.

When I am running a single mbbo (strings: "zero" "one" "two"), it certainly gets defined by writing to it.

ralph @ box : ~ $ caget -a mbbo

mbbo                           <undefined> zero UDF INVALID

ralph @ box : ~ $ caput mbbo one

Old : mbbo                           zero

New : mbbo                           one

ralph @ box : ~ $ caget -a mbbo

mbbo                           2022-10-07 07:46:19.049047 one

Are there any error outputs on the IOC console or on the client side? (Writing a wrong or misspelled choice string would leave it undefined.)

Cheers,
~Ralph