Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Fri, 25 Sep 1998 08:37:30 -0500

Paul Sichta wrote:
> 
> 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; 

I just looked at some device support. Here is an example (camac)

        /*  set shft and mask fields to the bit position
        (where the least significatn bit is 0) */
        pmbbi->shft = fsd;
        pmbbi->mask <<= fsd;

Here is another
    /* For mbbi records, the final parameter specifies the input bit
shift,
       with offset specifying the message byte number. */
    prec->shft = pcanMbbi->inp.parameter;
    prec->mask <<= pcanMbbi->inp.parameter;

Thus it appears that the mask should be applied before the shift.
Can we gurantee that no device support will be affected? Not clear.
Maybe it would be safer to change the soft raw device support.

            /*
> 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?

Maybe there is a dependence problem.

Try the following.

In your base/src/rec

touch mbbiRecord.c]
gnumake

Should see mbbiRecord compile and .o file installed.

In your application src directory

gnumake

Does the xxxLib get rebuilt? If not dependency problem. Do a

gnumake rebuild

Marty

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System