Re: mbboDirect record questions

[Vikram Bhagat <vbhagat@rocketmail.com>]

Hi All,

      The behavior of mbboDirect to set prec->sevr = INVALID_ALARM, which leads the PV value sets according to b0..b15 irrespective of user value is bug? 

---

From: Mark Rivers <rivers@cars.uchicago.edu>
To: Vikram Bhagat <vbhagat@rocketmail.com>; "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Sent: Sunday, March 10, 2013 6:02 PM
Subject: mbboDirect record questions

Folks,

I am trying to help Vikram understand the operation of the mbboDirect record, but I am not clear on how it is supposed to work either.

First, the mbboDirect documentation in the Record Reference Manual says that the VAL field is type ENUM.  This definitely seems to be wrong?

https://wiki-ext.aps.anl.gov/epics/index.php/RRM_3-14_Multi-Bit_Binary_Output_Direct

Second, I am unclear about the relationship or priority of the Bn and VAL fields.  The record reference manual says that one can write directly to the VAL field, and indeed this does work.  But it seems to have a problem the first time the record is processed.  Here is the output that Vikram observes from caput to the VAL field:

vikram @ control : ~ $ caput SET-MBBO 3
Old : SET-MBBO    1
New : SET-MBBO    0


vikram @ control : ~ $ caput SET-MBBO 3
Old : SET-MBBO    0
New : SET-MBBO    3


vikram @ control : ~ $ caput SET-MBBO 1
Old : SET-MBBO    3
New : SET-MBBO    1

Note that the first time the VAL field is written to with the value 3 the actual output is 0, not 3.

I believe that is because of the following logic in the mbboDirect record 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;
            }
        }

I'm not quite sure what this logic is intended to do.  But it seems that the first time the record processes this block gets executed.  So sevr must be INVALID_ALARM and nsev < INVALID_ALARM, so it sets the VAL field from the Bn fields, even though the VAL field was directly written to with the caput().  Is this what is intended?

Note that the Record Reference Manual does not describe this behavior at all.

Thanks,
Mark






From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Vikram Bhagat [vbhagat@rocketmail.com]

Sent: Friday, March 08, 2013 9:54 AM

To: tech-talk@aps.anl.gov

Subject:













Dear All,


    i am using Asyn driver and mbboDirect record type for my application







record (mbboDirect,"SET-MBBO")

{

        field(DESC, "New Variable")

        field(DTYP, "asynUInt32Digital")

        field(OUT, "@asynMask(ni6528_0, 3,7) writembbo")

  }


Where i have used "writembbo" as reason for device support driver.






i am not setting any other fields









I am not even setting B0 to B15 as want the user can set any value dynamically means user can set any bit 1 or 0 for any bit. 






So first time after IOC restart..... the first value writes 0 (zero) irrespective of the value I am setting then after it is normal.





So why it is only first time then after it is working fine.... whatever value I set it write that value only.




--> if i set  field(SEVR, "NO_ALARM")


then it works fine at first time after IOC restart.







So in record process routine

static long process(mbboDirectRecord *prec)      in record support module



prec->sevr becomes INVALID_ALARM  and val field will fill with B0...B15 and first time value become zero as i am not setting any value for B0..B15
















Due to this record support module write zero in driver and i am not able to set first time user define value at runtime.







How i can come out of this







with regards