EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  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  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: mbbi/mbbo Mask values
From: "Dalesio, Leo" <[email protected]>
To: "Dudley, David" <[email protected]>, "[email protected]" <[email protected]>
Date: Fri, 1 Jun 2012 13:34:28 +0000
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; [email protected]
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 <[email protected]>
Date: Friday, June 1, 2012 8:58 AM
To: David Dudley <[email protected]>, "[email protected]" <[email protected]>
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; [email protected]
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 <[email protected]>
Date: Friday, June 1, 2012 8:34 AM
To: David Dudley <[email protected]>, "[email protected]" <[email protected]>
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


Replies:
Re: mbbi/mbbo Mask values Andrew Johnson
References:
RE: mbbi/mbbo Mask values Dalesio, Leo
Re: mbbi/mbbo Mask values Dudley, David

Navigate by Date:
Prev: Re: mbbi/mbbo Mask values Paul Sichta
Next: Re: Proposed change in asyn - request for comments Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: mbbi/mbbo Mask values Paul Sichta
Next: Re: mbbi/mbbo Mask values Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·