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
(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.
> -----Original Message-----
> From: email@example.com
[mailto:firstname.lastname@example.org] On Behalf
> Of Andrew Johnson
> Sent: Friday, December 18, 2009 10:05 AM
> To: email@example.com
> 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
> > and the record has UDF=1, the record writes out the old value
> > the new one. According to the record reference manual, this is not
> > illegal operation.
> > Normally it works. Even if the UDF becomes true during run-time, the
> > thing that happens is that the new value is ignored (which is
> > enough). But after a reboot the record writes out 0 (and thus
> > all connected hardware).
> If UDF is true, the record severity should be INVALID, and what
> is controlled by the setting of the IVOA and IVOV fields (thus I
> "bad enough" claim since you can control what should happen in this
> I also don't think your analysis of the problem location is correct.
> dbPut() routine in dbAccess.c explicitly checks for a write to the VAL
> and clears UDF in that case (which happens before the record gets
> thus writing to the VAL field should never allow that prec->udf test
> 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
> the B0..B15 bits into VAL; this is happening because at startup NSEV
> NO_ALARM, SEVR is INVALID and you probably have OMSL set to
> Can you turn your design around and use DOL to fetch the new value
> putting it directly into the VAL field? That way OMSL will be
> the bit conversion code won't get executed. Actually you could just
> to closed_loop anyhow without setting DOL which should be enough to
> I'm not saying the code shouldn't be changed if someone wants to come
> a patch to fix this though.
> > I am not sure what the purpose of this code is. The record never
> > true. Thus only the device support can do so. Thus it cannot make
> > test udf BEFORE the device support is called.
> UDF defaults to true at startup. In normal operation the code ensures
> follow the IVOA/IVOV settings until such time as a real value is
> - Andrew
> The best FOSS code is written to be read by other humans -- Harald
- Re: mbboDirect problem Dirk Zimoch
- Navigate by Date:
RE: CAJ or PV gateway problem? Jeff Hill
Re: mbboDirect problem Dirk Zimoch
- Navigate by Thread:
Re: Revision tracking on vendor supplied updates? Elder Matias
Re: mbboDirect problem Dirk Zimoch