Re: mbboDirect record questions

["Vishnu Patel" <vishnu.patel@rediffmail.com>]

Ok Mark,
   For Vikram application it may work.
But still question is there about behavior of mbboDirect record at very first time..


I   initialized the prec->sevr at the beginning of record       " init_record" function   (base-3.14.12.3/src/rec/mbboDirectRecord.c)
static long init_record(mbboDirectRecord *prec, int pass)
{
       struct mbbodset *pdset;
       long status = 0;
       int i;


       if (pass==0) return(0);

       prec->sevr = NO_ALARM;                 



Here i initialize   prec->sevr = NO_ALARM at the starting of initialization record.

Is this ok?    or we can't do this in init_record.

With Best Regards






From: Mark Rivers <rivers@cars.uchicago.edu>
Sent: Fri, 15 Mar 2013 04:19:31 
To: "'vishnu.patel@rediffmail.com'" <vishnu.patel@rediffmail.com>, "jun-ichi.odagiri@kek.jp" <jun-ichi.odagiri@kek.jp>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Subject: Re: mbboDirect record questions
However, since Vikram’s application (the origin of this thread) is only writing to the VAL field of the mbboDirect record (and never to the Bn fields) I have told him that there is no advantage of the mbboDirect record, compared to the longout record with devAsynUInt32 device support, using the asynMask syntax. The longout record is then restricted to modifying the bits in the mask. 

Is this correct?

Mark


From: vishnu.patel@rediffmail.com [mailto:vishnu.patel@rediffmail.com] 
Sent: Thursday, March 14, 2013 5:41 PM
To: jun-ichi.odagiri@kek.jp
Cc: Mark Rivers; tech-talk@aps.anl.gov
Subject: Re: mbboDirect record questions

Dear All

I also have same problem with mbboDirect.



I   initialized the prec->sevr at the beginning of record       " init_record" function   (base-3.14.12.3/src/rec/mbboDirectRecord.c)
static long init_record(mbboDirectRecord *prec, int pass)
{
       struct mbbodset *pdset;
       long status = 0;
       int i;


       if (pass==0) return(0);

       prec->sevr = NO_ALARM;                 



Here i initialize   prec->sevr = NO_ALARM at the starting of initialization record.

Is this ok?   

With regards
Vishnu



From: <jun-ichi.odagiri@kek.jp>
Sent: Mon, 11 Mar 2013 06:05:23 
To: "Mark Rivers" <rivers@cars.uchicago.edu>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Subject: Re: mbboDirect record questions
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: 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 




Catch India as it happens with the Rediff News App. To download it for FREE, click here

Catch India as it happens with the Rediff News App. To download it for FREE, click here