RE: mbboDirect problems

[Mark Rivers <rivers@cars.uchicago.edu>]

I think that is the way the mbboRecord works.  This is from the process() function:

 

        if(prec->nsev < INVALID_ALARM

        && prec->sevr == INVALID_ALARM

        && prec->omsl == menuOmslsupervisory) {

            /* reload value field with B0 - B15 */

            int offset = 1, i;

            unsigned char *bit = &(prec->b0);

            for (i=0; i<NUM_BITS; i++, offset = offset << 1, bit++) {

                if (*bit)

                    prec->val |= offset;

                else

                    prec->val &= ~offset;

            }

        }

        /* convert val to rval */

        convert(prec);

 

If I read this correctly then the first time the record processes sevr==INVALID_ALARM so it will overwrite the VAL field with the Bn fields.

 

Mark

 

 

 

From: Eric Norum [mailto:wenorum@lbl.gov]
Sent: Monday, September 08, 2014 4:44 PM
To: Mark Rivers
Cc: EPICS mailing list
Subject: Re: mbboDirect problems

 

Yes.

 

On Sep 8, 2014, at 2:41 PM, Mark Rivers <rivers@cars.uchicago.edu> wrote:

Does it work if you write to a bit field?

 

From: Eric Norum [mailto:wenorum@lbl.gov] 
Sent: Monday, September 08, 2014 4:17 PM
To: Mark Rivers
Cc: EPICS mailing list
Subject: Re: mbboDirect problems

 

The VAL field.

On Sep 8, 2014, at 2:11 PM, Mark Rivers <rivers@cars.uchicago.edu> wrote:

What field is the client writing to?  The VAL field or an individual bit?

 

In R4-21 the following change was made:

“Improved the initMbboDirect function in devAsynUInt32Digital.c. If an initial value is read successfully from the driver it now sets the .Bn fields in the record. It also sets VAL rather than RVAL and returns 2 rather than 0. Thanks to Andrew Johnson for this.”

Mark

 

 

From: Eric Norum [mailto:wenorum@lbl.gov] 
Sent: Monday, September 08, 2014 3:50 PM
To: EPICS mailing list
Subject: mbboDirect problems

 

I have a number of mbboDirect records like:

 

record(mbboDirect, "$(P)$(R)EVR:event12trig") {

    field(DESC, "Extraction pre-trigger")

    field(DTYP, "asynUInt32Digital")

    field(OUT,  "@asynMask($(PORT) 0x30C 0xFF 0)")

    field(NOBT, "8")

    field(MASK, "0xFF")

}

 

The IOC starts up and reads back the initial value of this record properly.

The *first* caput to the record (I’ve tried from EDM and from caput) writes the readback value again, not the value from the client.

Subsequent caputs do write the value from the client.  It’s only the first operation that uses old data.

Is this a known problem? 

 -- 
Eric Norum
wenorum@lbl.gov

 

-- 
Eric Norum
wenorum@lbl.gov

 

-- 
Eric Norum
wenorum@lbl.gov