Experimental Physics and
Industrial Control System

"Allison, Stephanie" <[email protected]> · Wed, 6 Jan 2010 09:43:20 -0800

Hi Dirk,

I agree with everything you propose for changes to mbboDirect.

> What about extending the mbb* records to 32 bits?

This would be very nice with the caveat that now VAL would be an
unsigned long which means CA sends it as double which affects the way
some clients use the data (ie, I'd want to see it in hex and not all
clients allow this for doubles).  

> 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?

Sounds good to me.  

It may also be helpful to set zero and one severity per Bx bit.   Carl
Lionberger made this change for some old app a long time ago but I can't
remember the context.   Maybe better to just use or add bi/bo instead.

Stephanie

> -----Original Message-----
> From: Dirk Zimoch [mailto:[email protected]]
> Sent: Wednesday, January 06, 2010 1:38 AM
> To: Allison, Stephanie
> Cc: [email protected]
> Subject: Re: mbboDirect problem
> 
> 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
> >
> >
> >

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System