EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Question about mbboDirect record
From: Andrew Johnson <[email protected]>
To: Mark Rivers <[email protected]>
Cc: tech-talk tech-talk <[email protected]>
Date: Fri, 30 Mar 2007 10:48:59 -0500
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

References:
Question about mbboDirect record Mark Rivers

Navigate by Date:
Prev: NSLS Controls Computing Leader Position Zitvogel, Emil
Next: Re: CALC record weird behaviour Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Question about mbboDirect record Mark Rivers
Next: NSLS Controls Computing Leader Position Zitvogel, Emil
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Nov 2011 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·