g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014 
<== Date ==> <== Thread ==>

Subject: RE: mbboDirect changes
From: Mark Rivers <rivers@cars.uchicago.edu>
To: "'Andrew Johnson'" <anj@aps.anl.gov>
Cc: EPICS core-talk <core-talk@aps.anl.gov>, Eric Norum <wenorum@lbl.gov>, Rod Nussbaumer <bomr@triumf.ca>
Date: Wed, 13 Feb 2013 19:55:15 +0000
Hi Andrew,

I would like to make the fix you proposed to the asyn mbboDirect device support before I release the next version (hopefully this week).

The asyn device support init_record for mbboDirect currently does the following:

    /* Read the current value from the device */
    status = pasynUInt32DigitalSyncIO->read(pPvt->pasynUserSync,
                      &value, pPvt->mask, pPvt->pasynUser->timeout);
    if (status == asynSuccess) {
        pr->rval = value & pr->mask;
        return 0;
    return 2;

So if it successfully reads a value from the driver it sets rval (not val) and returns 0.  How do I modify your code below to handle this case?  Do I simply replace prec->val with prec->rval?

        epicsUInt16 val = prec->rval;


-----Original Message-----
From: Andrew Johnson [mailto:anj@aps.anl.gov] 
Sent: Thursday, December 06, 2012 12:22 PM
To: Mark Rivers
Cc: Eric Norum; Rod Nussbaumer; EPICS core-talk
Subject: mbboDirect changes

Hi Mark,

On 2012-11-26 Mark Rivers wrote:
> What was the conclusion of the mbboDirect record initialization thread?

The mbbxDirect records are a bit of a mess.  It looks like they were written 
by hacking away at the mbbx records until they did what the author wanted, but 
they don't seem to implement a coherent model of an object.  The wiki page for 
mbboDirect still talks about the SDEF field, which was one of the fields that 
were removed from the mbbo record, and doesn't discuss the Bn fields in the 
record description text at all.

For 3.14.x IOCs a device support's init_record() routine should initialize the 
Bn fields itself if it sets RVAL/VAL and returns 0/2.  Here's the code for 
doing that:

        epicsUInt16 val = prec->val;
        epicsUInt8 *pBn = &prec->b0;
        int i;

        for (i = 0; i < 16; i++) {
            *pBn++ = !! (val & 1);
            val >>= 1;

I have uncommitted changes for 3.15 where the record type initializes the Bn 
fields from RVAL/VAL after the init_record() call as long as UDF is clear and 
OMSL is supervisory.  UDF gets cleared for you if you set RVAL and return 0, 
but you will have to clear UDF yourself if you set VAL and return 2 (this 
matches the expectations of the other output record types).

I've made setting the Bn fields conditional on OMSL to match the process() and 
special() routines, which already use OMSL to determine whether the Bn fields 
should be read from or not.  Closed-loop means process() reads from DOL into 
VAL and ignores the Bn field values; supervisory means the Bn fields are read 
to set VAL, so it only makes sense to initialize the Bn fields in supervisory 

While trying to internalize how the record initialization works after making 
that modification, I came up with the following descriptions, which show that 
the interaction between the various parameters make the record hard to 

* For device support whose init_record() routine reads RVAL from the
  hardware and returns 0, the VAL field will always contain the shifted
  RVAL; the Bn fields will be set from the VAL field if OMSL=supervisory.

* For device support whose init_record() routine returns 2, unless DOL
  contains an integer literal the VAL and Bn fields will not be modified
  by the record initialization (if the device support doesn't set them,
  they will get whatever values were loaded from the .db files).  If DOL
  is set to an integer literal, that value will be used to initialize the
  VAL field.  The Bn fields are set from the VAL field if OMSL=supervisory
  in this case.

Note that the OMSL and Bn fields are special; setting OMSL to supervisory 
results in VAL being calculated from Bn, and subsequent changes to the Bn 
fields also immediately update VAL.  However the Bn fields are never set from 
VAL anywhere in the existing record code, nor does the record post monitors on 
them (since it never changes them itself).  This caused me to pause before 
committing the above change.

I might have expected the Bn fields to be updated from VAL either immediately 
after reading DOL in closed-loop mode, or at least whenever OMSL gets changed 
from closed-loop to supervisory.  The existing code treats the Bn fields as 
pure inputs for manually setting the bits when in supervisory mode.  I will 
probably also make special() update the Bn fields from VAL and post monitors 
on those that change when OMSL gets set back to supervisory; I think that's 
rather more friendly.

Comments welcome.

- Andrew
Computer science is as much about computers as astronomy is about
telescopes. -- Edsger Dijkstra

Re: mbboDirect changes Andrew Johnson

Navigate by Date:
Prev: [Merge] lp:~epics-core/epics-base/spinlocks into lp:epics-base noreply
Next: Re: mbboDirect changes Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014 
Navigate by Thread:
Prev: [Merge] lp:~epics-core/epics-base/spinlocks into lp:epics-base noreply
Next: Re: mbboDirect changes Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·