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  <20102011  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  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: mbboDirect problem
From: Dirk Zimoch <[email protected]>
To: "Allison, Stephanie" <[email protected]>
Cc: [email protected]
Date: Wed, 06 Jan 2010 10:37:53 +0100
Hello

Better to use a longout if multiple
bits need to be written at the same time.

You cannot set a mask with a longout. So you can't say "write bits 3..7". But I found that an mbbo with no states defined works as expected (i.e. you can write to VAL and the value is shifted and the device support can write the masked bytes.)


It is a pity that the Bx fields of mbboDirect do not update when VAL is written. It seems mbboDirect has not been designed to have VAL written. But then neither DOL not the record_init() code makes much sense. Maybe this is an issue for the next Codeathon. Provided we have defined what the "expected behaviour" is.

I propose the following behavior:

VAL and Bx fiels should always stay consistent. Whenever VAL is written (by put, via DOL, initialization from hardware, autoSR restore) the Bx fields have to be updated. If a Bx field changes, a monitor should be triggered. As is is now: Whenever any of the Bx fields is written, VAL has to be updated.

Updating VAL can be done as it is now using the special() function. Updating Bx can be done in monitor(). Then, this function can also take care of triggering monitors for the Bx fields that have changed.

What to do during initialization? A constant DOL initializes VAL. A device support initializes RVAL or VAL. In both cases (i.e. after initializing VAL), the Bx fields should be updated accordingly. AutoSR may save VAL or Bx. Thus, it is probably best to initialize the bits to VAL "or" Bx so that either may be saved: First add all bits to VAL where Bx is set, then update all Bx fields according to VAL.

What about extending the mbb* records to 32 bits?
Heretic question: What about combining the features of mbb[io]Direct with mbb[io], i.e. adding Bx fields to mbb[io] records and get rid of mbb[io]Direct?


Comments welcome!
Dirk


Allison, Stephanie wrote:
Hello,

Since we are on the subject of mbboDirect, there are a few things about
this record type that are interesting and make me limit the use of this
record type:

(1) A static restore of the VAL field of a supervisory mbboDirect record
(ie, on ioc boot) doesn't work.  VAL remains at the value that you
restored until the first time the record is processed when it reverts
back to the mask based on the Bx fields.  It's important that the 16 Bx
fields be restored instead of VAL for supervisory mbboDirect's.  For a
static restore of a soft (not raw) supervisory mbboDirect, UDF is only
cleared when VAL is statically restored (or if DOL is set to a constant
in which case static restore should not be used).  If only the Bx fields
are statically restored, UDF will remain set until a runtime Bx or VAL
put is done.

(2) When DOL is set to a constant value in the database, you would
expect to see the appropriate Bx fields set after record initialization.
This doesn't happen (I think it should).

(3) For a closed loop mbboDirect record, the Bx fields are inconsistent
with VAL. I believe this is per design though I don't understand the
reason. When the loop is opened, VAL will change to reflect the
(probably very old and stale) Bx values which is odd.


(4) A write to VAL doesn't stick unless the mbboDirect record is
closed_loop and DOL is constant. Better to use a longout if multiple
bits need to be written at the same time.


Stephanie Allison

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf
Of Andrew Johnson
Sent: Friday, December 18, 2009 10:05 AM
To: [email protected]
Subject: Re: mbboDirect problem

Hi Dirk,

On Friday 18 December 2009 08:38:35 Dirk Zimoch wrote:
When I write a bit pattern directly into the VAL field instead of
B0...BF,
and the record has UDF=1, the record writes out the old value
instead of
the new one. According to the record reference manual, this is not
an
illegal operation.
Normally it works. Even if the UDF becomes true during run-time, the
worst
thing that happens is that the new value is ignored (which is
already bad
enough). But after a reboot the record writes out 0 (and thus
switches off
all connected hardware).
If UDF is true, the record severity should be INVALID, and what
happens then
is controlled by the setting of the IVOA and IVOV fields (thus I
dispute your
"bad enough" claim since you can control what should happen in this
case).
I also don't think your analysis of the problem location is correct.
The
dbPut() routine in dbAccess.c explicitly checks for a write to the VAL
field
and clears UDF in that case (which happens before the record gets
processed),
thus writing to the VAL field should never allow that prec->udf test
to
succeed.

What I think is happening in your case is that the VAL field is being
overwritten by the code immediately below the prec->udf test, which
converts
the B0..B15 bits into VAL; this is happening because at startup NSEV
is
NO_ALARM, SEVR is INVALID and you probably have OMSL set to
Supervisory.
Can you turn your design around and use DOL to fetch the new value
rather than
putting it directly into the VAL field? That way OMSL will be
closed_loop so
the bit conversion code won't get executed. Actually you could just
set OMSL
to closed_loop anyhow without setting DOL which should be enough to
stop it.
I'm not saying the code shouldn't be changed if someone wants to come
up with
a patch to fix this though.

I am not sure what the purpose of this code is. The record never
sets udf
true. Thus only the device support can do so. Thus it cannot make
sense the
test udf BEFORE the device support is called.
UDF defaults to true at startup. In normal operation the code ensures
that we
follow the IVOA/IVOV settings until such time as a real value is
provided.
- Andrew
--
The best FOSS code is written to be read by other humans -- Harald
Welte





Replies:
RE: mbboDirect problem Allison, Stephanie
Re: mbboDirect problem Andrew Johnson
References:
RE: mbboDirect problem Allison, Stephanie

Navigate by Date:
Prev: RE: mbboDirect problem Allison, Stephanie
Next: RE: Revision tracking on vendor supplied updates? nick.rees
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: mbboDirect problem Allison, Stephanie
Next: RE: mbboDirect problem Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·