Re: Question about mbboDirect record

[Andrew Johnson <anj@aps.anl.gov>]

Hi Mark,

Mark Rivers wrote:
> I have a question about the mbboDirect record, specifically the
> interaction of the .VAL and .B0-.BF fields.
>
> On the mbbiDirect record the 	.VAL fields and .BO-.BF fields are
> always consistent.

The mbbiDirect is an input record; it reads an unsigned integer 
bitpattern from the device support into the VAL field (converting from 
RVAL if necessary), then splits the result into bits in the B0-BF 
fields.  Both the VAL and Bn fields are marked pp(TRUE) so a CA put to 
any of these fields (or a DB put with PP) will result in the above 
calculation being re-done.

A DB put from another record that is NPP will be able to modify any of 
the Bn fields without causing the record to be processed, thus resulting 
in an inconsistency between VAL and Bn.  There is no code in the record 
support that converts the Bn fields back to a bitpattern in the VAL field.

> However, this does not seem to be the case with the mbboDirect record.
> If I write to the .Bn fields of the mbboDirect record, the .VAL field
> updates as expected.  However, the opposite is not true.  If I write to
> .VAL field, the .Bn fields do not change.  This does not make sense to
> me.

The mbboDirect is an output record that has OMSL and DOL fields; if OMSL 
is closed_loop it reads VAL from the DOL link and sends the result to 
the device support.  If OMSL is supervisory however it takes all the 
values from its B0-BF fields and combines them into an unsigned integer 
bitpattern in the VAL field which is then passed to the device support. 
 The VAL and Bn fields are marked pp(TRUE), thus a CA put to any of 
these fields (or a DB put with PP) will result in the above calculation 
being re-done.

In this recordtype the OMSL and Bn fields are marked special(SPC_MOD), 
thus any puts to the Bn fields (over CA or DB, with or without PP) will 
cause the special processing routine to be run that sets or clears bits 
in the VAL field to match the Bn change.  Puts that make the OMSL field 
supervisory also cause all the Bn fields to be recombined into VAL.

There is no code in the record that converts the VAL field back to a 
bitpattern in the Bn fields, and the VAL field is not special so a DB 
put from another record that is NPP will be able to modify the VAL field 
without causing the record to be processed, thus resulting in an 
inconsistency between VAL and Bn.  If OMSL is closed_loop, the Bn fields 
are ignored completely.

> Can someone explain why this is so, or is it a bug?

Hopefully the above explanation can be matched to your experience.  We 
don't have a generic bidirectional bit multiplexer/demultiplexer record 
in Base, and I'm not aware of one from elsewhere but it might exist.

- Andrew
--
The right to be heard does not automatically include
the right to be taken seriously. -- Hubert H. Humphrey