RE: mbbi/mbbo Mask values

["Dalesio, Leo" <dalesio@bnl.gov>]

The suggestion was to use the calc record to mask the three bits that you want to consider - not to use it to make the comparison. So you would say MBBI.VAL & 0x303

The best way to support any arbitrary bit group would be to allow the mask to be configured directly, as you first suggested. I would not want to hold my breath for that change to go into the database. There are two things that happen in this record that have to be coordinated - which bits to use, and there is also an expectation that they are returned as right shifted numbers - so that the comparisons for the current state are in terms of the device - not the particular screws where the signals come in.

Also, changing that MASK to some arbitrary bit pattern in the device support seems a very obscure modification that future engineers trying to understand the application would likely have a difficult time finding. Personally, I try not to be too tricky - I hate getting phone calls in the middle of the night.

Another approach could be to re-wire the PLC so that the bits are consecutive - as you would expect a single device to be.
Or treat this as two multi-bit devices - one that is the values and the other are the validity bits. This is a bit more obvious and it conforms with the definition and intent of the MBBIx records.

So, there are many ways to change what is there. But it may be most prudent to do something that requires no change to the record - and explicitly shows what is going on with the logic.

Bob

---

From: Dudley, David
Sent: Friday, June 01, 2012 9:19 AM
To: Dalesio, Leo; tech-talk@aps.anl.gov
Subject: Re: mbbi/mbbo Mask values

Lemme muddy the waters a little bit more…

Up in the "Read and Convert Parameters"…

Last couple of sentences… (my emphasis…)

"… The user can configure the NOBT field, but the device support routines may set it, in which case the value given to it by the user is simply overridden. The device support routines may also override MASK or shift it left by SHFT bits. If MASK is non-zero, only the bits specified by MASK will appear in RVAL."

I take from that, from the driver's point of view, 'MASK' is optional, and may or may not be used.  If that's the case, seems to me I should be able to define whatever mask I want, and as long as I don't want to match more than 16 values, it should work fine.

..So, if I define a mask in the driver that is 0x0303 for instance (bits 0,1,8, and 9), and set NOBT to 10, I should be able to match against 16 field values, even if the actual values I'm matching have values of "0,1,2,3, 256,257,258,259, 512,513,514,515, 768,769, 770,771" (I've already taken too much space, I'm not going to give them in binary as well ).  As long as I only have <16 valid bit states that I'm looking for, seems that I should be able to use -any– combination of bits (if I can compute their actual values, which I hope I got right).

I could add a calc record and figure some way to generate consecutive bits, but that seems like just adding an additional record that I don't really have to add, if I can define another way.

David

From: <Dalesio>, Leo <dalesio@bnl.gov>
Date: Friday, June 1, 2012 8:58 AM
To: David Dudley <ddudley@bnl.gov>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Subject: RE: mbbi/mbbo Mask values

In the record reference manual on the EPICS wiki
https://wiki-ext.aps.anl.gov/epics/index.php/RRM_3-14_Multi-Bit_Binary_Input
it states:

NOBT

Number of Bits

Number of hardware bits accessed. They must be consecutive.

It would be better if the introduction to this record type had pointed this out. I will chance that today - if I remember how to get into the wiki page.

---

From: Dudley, David
Sent: Friday, June 01, 2012 8:42 AM
To: Dalesio, Leo; tech-talk@aps.anl.gov
Subject: Re: mbbi/mbbo Mask values

I am assuming that is defined somewhere?

Looking at the MBBI record definition, I see that Mask, ZRVl, ONVL, … FFVL are all ULONGS, which would allow a bit field to be defined that didn't depend on consecutive bits.  Seems that the limitation is that NOBT defines MASK.

If NOBT was set to 0 (I would take that meaning as "don't define mask"), seems MASK 'should' be able to be manipulated.

Looking in the ether-ip driver, it doesn't look like mask from the record is even used.  It builds it's own internally.

David

From: <Dalesio>, Leo <dalesio@bnl.gov>
Date: Friday, June 1, 2012 8:34 AM
To: David Dudley <ddudley@bnl.gov>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Subject: RE: mbbi/mbbo Mask values

The limit/definition of the MBBx record types was that the bits were consecutive.
I think that you would have to use a calc record between the input and MBBx record to mask out the bits in between.
Bob