Experimental Physics and
Industrial Control System

[email protected] (Rozelle Wright) · Fri, 25 Sep 1998 07:20:55 -0600

> From [email protected] Fri Sep 25 07:04 MDT 1998
> To: <[email protected]>
> Subject: MBBI & mask
> Date: Fri, 25 Sep 1998 09:00:30 -0400
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-Msmail-Priority: Normal
> X-Mailer: Microsoft Outlook Express 4.72.3110.5
> X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3
> X-Lines: 46
> 
> A few months ago the ability to specify the SHFT parameter for the mbbi
> record (for soft/raw soft device type) was added.  I now realize that the
> mbbi record's  MASK feature is not applied for soft or raw soft device
> types.    Inspecting the source mbbiRecord.c confirms that the mask is not
> used in record support.   Without the mask,  higher-order bits (those beyond
> NOBT) affect the value and cause invalid states.
> 
> 1)  I propose that the bit mask in the mbbi record be used for all device
> types,  to strip out bits "above" the bit range of interest.
>     a)  The mask is (now) created based on NOBT (number of bits).
>     b)  The mask would be applied to rval after the value has been shifted
> by SHFT number of bits.  For hardware devices,  the shifting occurs in
> device support (prior to the mbbi record). Hardware device types should have
> their SHFT field set to zero.
> 
> A code segment from mbbiRecord.c is shown below,  along with the proposed
> new line.
> 
> 
>         recGblGetTimeStamp(pmbbi);
>         if(status==0) { /* convert the value */
>                 unsigned long   *pstate_values;
>                 short           i;
>                 unsigned long rval = pmbbi->rval;
> 
>                 if(pmbbi->shft>0) rval >>= pmbbi->shft;
>                 rval = rval & pmbbi->mask;                          /*
> proposed new line 25SEP98  */
>                 if (pmbbi->sdef){
>                         pstate_values = &(pmbbi->zrvl);
>                         pmbbi->val = 65535;
> 
> 
> 
> 2)  In an effort to figure out this problem,  I recompiled a "test" version
> of mbbiRecord.c (ran gnumake in base/src/rec).   The new mbbiRecord.o was
> installed in the target's bin directory.  I ran gnumake in my application's
> src directory,  and rebooted the IOC.   The mbbiRecord operation was the
> same as before.  Why didn't the new object file run on the IOC?
> 
Some Possibilities:
1. Did you do a "gmake clean" in the application area.  The epics records
may not be dependencies for the application area make.

2.The RELEASE of EPICS you are using to build your application isn't the same
as the one in which you changed mbbiRecord.o. (Check config/RELEASE in your
application area)

3.The library you are loading on your ioc isn't built in the application
area that you rebuilt. (Sometimes there are several applications and only
one builds a library containing epics code.)

I can't think of any others at the moment.  Assuming you are using the
3.13 makeBaseApp.pl type application environment the baseLIBOBJS file
should pick up mbbiRecord.o from your epics release.
Rozelle

> 
> --
> Paul Sichta
> Princeton Plasma Physics Laboratory
> 609-243-3477
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System