Experimental Physics and
Industrial Control System

<[email protected]> · Mon, 11 Mar 2013 09:34:33 +0900

Hi, Mark

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

I'm also aware of this behavior of mbboDirect. The first time I put
a value into VAL, the mbboDirect outputs 0 (Zero).

Every time I write a new device support, I forget it and spent some
time to find the cause. And in the end, I remenber that the cause is
not in my device support but in mbbiDirect as you mentioned.

I also would like to know if the behavior of mbboDirect is a bug or
specification.

J. Odagiri

----- Original Message -----
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System