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
- Replies:
- Re: mbboDirect record questions jun-ichi.odagiri
- Re: mbboDirect record questions Vikram Bhagat
- References:
- [no subject] Vikram Bhagat
- Navigate by Date:
- Prev:
RE: Area Detector Mark Rivers
- Next:
Re: Area Detector Zenon Szalata
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: Mark Rivers
- Next:
Re: mbboDirect record questions jun-ichi.odagiri
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|