Re: MBBO IVOA has different behavior in IOC shell and Unix terminal

["Marco A. Barra Montevechi Filho via Tech-talk" <tech-talk at aps.anl.gov>]

Hi, Rolf. Thanks for the help!

Indeed in the example record i blindly accepted VSCode mbbo template and forgot to change the values to numerical ones. In the actual implementation,
the record has numerical values between double quotes, so i figure i can remove these quotes just to be sure.
By what you are saying i understand that i also need to explicitly set the alarm fields to INVALID in order for the IVOA associated algorithm to understand that
those fields should not trigget the OUT field. I did this:

record(mbbo, "record_name") {

    field(DESC, "description")

    field(ZRST, "zero_string")      field(ZRVL, 0)

    field(ONST, "one_string")       field(ONVL,1)

    field(TWST, "two_string")       field(TWVL, 2)

    field(THST, "three_string")     field(THVL, 3)

    field(FRST, "four_string")      field(FRVL, 4)

    field(ZRSV, NO_ALARM)           field(ONSV, NO_ALARM)

    field(TWSV, NO_ALARM)           field(THSV, NO_ALARM)

    field(FRSV, NO_ALARM)           field(FVSV, INVALID)

    field(SXSV, INVALID)            field(SVSV, INVALID)

    field(EISV, INVALID)            field(NISV, INVALID)

    field(TESV, INVALID)            field(ELSV, INVALID)

    field(TVSV, INVALID)            field(TTSV, INVALID)

    field(FTSV, INVALID)            field(FFSV, INVALID)

    field(IVOA, 1)

    field(OUT, "test")

}

record(ai, "test"){}

The interesting thing is: when i do

caput record_name 4
caput record_name 8

Then i can see record_name.RVAL = 0 and test.VAL=4.

Since the actual record is an asyn record:

field(DTYP, "asynInt32")
field(OUT,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))RECORD_NAME")

I figure this means that i wont have the main trouble, which is getting 0 as the value argument in my writeInt32?
I cant test this right now but will test as soon as possible.

Thanks for the help!

Marco 

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Rolf Keitel via Tech-talk <tech-talk at aps.anl.gov>
Sent: 18 October 2023 15:52
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: MBBO IVOA has different behavior in IOC shell and Unix terminal

 

Hello Marco,

The record, as you defined below, uses string values where numerical values are required.

If you define the record "record_name" as you describe, you should get an error message on the IOC console when your database is loaded. Something like:

"Error: syntax error   ....."

This is because the fields ZRVL, ONVL, ... are of type ULONG. If you set them to a string value, which cannot be decoded into an integer, the IOC will load the database with an error message and will set ZRVL, ...  to 0.

You can achieve what you want to do (limit the operational value) by:

• setting ZRVL, ONVL, ... to numerical values
• setting the severities for the states which should not drive the output (e.g.  FRSV, FVSV, ...)  to INVALID
• setting IVOA to "Dont drive outputs" as you did (I believe you were just lucky that the string "1" is decoded as enumerated 1)
  

For example, if you define

record(mbbo, "record_name") {

    field(DESC, "description")

    field(ZRST, "zero_string")        field(ZRVL, 11)

    field(ONST, "one_string")         field(ONVL,13)

    field(TWST, "two_string")         field(TWVL, 15)

    field(THST, "three_string")       field(THVL, 17)

    field(FRST, "four_string")        field(FRVL, 19)

    field(FRSV, INVALID)

    field(IVOA, 1)

}

Now if you do a 

   caput record_name 4

in a linux shell or a

   dbpf record_name 4

on the IOC console, the record's VAL field will be 19, but the OUT link will not be processed.

HTH - rolf -

On 2023-10-17 6:24 a.m., Marco A. Barra Montevechi Filho via Tech-talk wrote:

Hello all. I stumbled upon a curious behavior of mbbo record with configured IVOA field, both in EPICS 3.15.6 and 7.0.7

We were originally testing it in an areaDetector IOC, but managed to make a minimal example. Basically, we want to set forbidden values to mbbo record in such a way that the IOC does not accept values above a certain number (in the example, above or equal to five).
I defined the following record:

record(mbbo, "record_name") {

    field(DESC, "description")

    field(ZRST, "zero_string")        field(ZRVL, "zero_value")

    field(ONST, "one_string")         field(ONVL, "one_value")

    field(TWST, "two_string")         field(TWVL, "two_value")

    field(THST, "three_string")       field(THVL, "three_value")

    field(FRST, "four_string")        field(FRVL, "four_value")

    field(IVOA, "1")

}

By configuring the IVOA field to "Dont drive outputs", i expect that whenever i put 5 into record_name, it does nothing and statys in the old value. This works in ioc shell:

epics> dbpf record_name 3

DBF_STRING:         "three_string"      

epics> dbgf record_name

DBF_STRING:         "three_string"      

epics> dbpf record_name 7

recGblRecordError: 7 Illegal choice PV: record_name

DBF_STRING:         "three_string"      

epics> dbgf record_name

DBF_STRING:         "three_string"      

However, in a linux terminal with caget and caput this is not true:

marco@s-swc10-l:~$ caget record_name

record_name                    three_string

marco@s-swc10-l:~$ caput record_name 7

Warning: enum index value '7' may be too large.

Old : record_name                    three_string

New : record_name                    

marco@s-swc10-l:~$ caget record_name

record_name                    

marco@s-swc10-l:~$

And it changes the value to zero. Even worse: when in an asyn IOC, the value passed to writeInt32 asyn function is also zero.

Is there any better way to set an operational limit to mbbo? Am i missing something?

Thanks in advance,

Marco

Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.

Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.

--
Rolf Keitel, Ph.D.
Researcher Emeritus
e-mail: rolf at triumf.ca
------ Home ------
4158 West 13th Ave
Vancouver, BC, V6R 2T6
604 228 0594
------ Office: ------
604 222 7453
TRIUMF Canada’s particle accelerator centre
4004 Wesbrook Mall Vancouver, BC, V6T 2A3
www.triumf.ca | Twitter | Facebook | Instagram

TRIUMF is located on the traditional, ancestral, and unceded territory of the xʷməθkʷəy̓əm (Musqueam) people,
who for millennia have passed on their culture, history, and traditions from one generation to the next on this site.