EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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  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 
<== Date ==> <== Thread ==>
Subject: Re: mbboDirect record questions
From: "Vishnu Patel" <[email protected]>
To: "Mark Rivers " <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: 14 Mar 2013 23:57:27 -0000
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 <[email protected]>
Sent: Fri, 15 Mar 2013 04:19:31
To: "'[email protected]'" <[email protected]>, "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
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: [email protected] [mailto:[email protected]]
Sent: Thursday, March 14, 2013 5:41 PM
To: [email protected]
Cc: Mark Rivers; [email protected]
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: <[email protected]>
Sent: Mon, 11 Mar 2013 06:05:23
To: "Mark Rivers" <[email protected]>
Cc: "[email protected]" <[email protected]>
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: [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
>
>
>
>
>
>
>
>
>
>
>
>
>
>




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
Replies:
RE: mbboDirect record questions Mark Rivers
Navigate by Date:
Prev: RE: mbboDirect record questions Mark Rivers
Next: RE: mbboDirect record questions Mark Rivers
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: mbboDirect record questions Mark Rivers
Next: RE: mbboDirect record questions Mark Rivers
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 
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 ·