EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: mbboDirect record questions
From: Vikram Bhagat <[email protected]>
To: Mark Rivers <[email protected]>, "[email protected]" <[email protected]>
Date: Wed, 13 Mar 2013 02:47:12 -0700 (PDT)
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 <[email protected]>
To: Vikram Bhagat <[email protected]>; "[email protected]" <[email protected]>
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: [email protected] [[email protected]] on behalf of Vikram Bhagat [[email protected]]

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

To: [email protected]

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















References:
[no subject] Vikram Bhagat
mbboDirect record questions Mark Rivers

Navigate by Date:
Prev: quadEM R4-0 now available Mark Rivers
Next: asynInt32 pass 2 value Vikram Bhagat
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: mbboDirect record questions jun-ichi.odagiri
Next: mca 7-3-1 available Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·