Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Fri, 15 Jan 2016 13:20:02 +0000

Hi Phil,

> Are you saying that, if the mbbo record had the asyn:READBACK, the _RBV record would be unnecessary?
> Since I've done them all now (or rather, written a utility that generates them all from a spreadsheet),
> is there any advantage in doing so?

It depends what you mean by "unnecessary".  If you put the tag info(asyn:READBACK, "1") then yes, the output record will change the same way the _RBV record would change when the parameter value in your driver changes.  You can read more about it by searching for the string READBACK here:
http://www.aps.anl.gov/epics/modules/soft/asyn/R4-28/asynDriver.html
and here:
http://www.aps.anl.gov/epics/modules/soft/asyn/R4-28/RELEASE_NOTES.html

The asyn test applications testOutputReadbackApp and testErrorsApp demonstrate and test the use of this feature.

That being said, here are 3 advantages to having the _RBV record.

1) If the user types a value in the output field that is invalid for some reason then the RBV should update with a valid value that the driver provided instead.  Being able to see both values at once can be preferred compared to having what you just typed be instantly replaced.

2) Consider the case you were asking about yesterday with the interaction of ADSizeX and ADBinX.  Suppose the camera has a restriction that ADSizeX must be a multiple of ADBinX, as most cameras do.  The user has ADSizeX=1000 and ADBinX=1.  Then they change ADBinX to 3.  The driver probably changes ADSizeX to 999.  If you use the _RBV mechanism the output record will still show 1000, but the _RBV record will show 999.  If you use the asyn:READBACK mechanism the output record will change to 999.  Now the user changes ADBinX back to 1000.  With the _RBV mechanism the user only needs to press Enter in the output record to set it back to 1000.  With the asyn:READBACK mechanism they have to retype 1000.

3) Having both the requested value and the actual value makes it obvious when something is wrong with the driver.  When the IOC is restarted the autosave values are restored one wants the output and readback records to agree.  If they don't then something is wrong with the driver or camera.  If the asyn:READBACK mechanism is used this is not obvious, since only the output record is visible and it is not obvious that the value is not the one that was in autosave.

Just my 2 cents.

Mark

________________________________
From: Phil Atkin [[email protected]]
Sent: Friday, January 15, 2016 4:17 AM
To: Mark Rivers; [email protected]
Subject: Re: areaDetector: ADBinX/Y and ADSizeX/Y interactions

I'm afraid you're showing up my almost total ignorance of the EPICS record structure, so I'm going to have to retaliate by asking more questions.

ADBase.template has, for example:
record(mbbo, "$(P)$(R)FrameType")
{
   field(PINI, "YES")
   field(DTYP, "asynInt32")
   field(OUT,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))FRAME_TYPE")
   field(ZRST, "Normal")
   field(ZRVL, "0")
   field(ONST, "Background")
   field(ONVL, "1")
   field(TWST, "FlatField")
   field(TWVL, "2")
   field(THST, "DblCorrelation")
   field(THVL, "3")
   field(VAL,  "0")
   info(autosaveFields, "VAL")
}

record(mbbi, "$(P)$(R)FrameType_RBV")
{
   field(DTYP, "asynInt32")
   field(INP,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))FRAME_TYPE")
   field(ZRST, "Normal")
   field(ZRVL, "0")
   field(ONST, "Background")
   field(ONVL, "1")
   field(TWST, "FlatField")
   field(TWVL, "2")
   field(THST, "DblCorrelation")
   field(THVL, "3")
   field(SCAN, "I/O Intr")
}
Are you saying that, if the mbbo record had the asyn:READBACK, the _RBV record would be unnecessary?  Since I've done them all now (or rather, written a utility that generates them all from a spreadsheet), is there any advantage in doing so?

Phil

On 14/01/2016 19:11, Mark Rivers wrote:
asyn:READBACK would be for the output records (e.g. ao, bo, mbbo, etc.), not the readback records.  The output records would then change value if you change the parameter in your driver.  The device support is smart enough to not call the driver again when the output record processes because of the callback.

Mark

From: Phil Atkin [mailto:[email protected]]
Sent: Thursday, January 14, 2016 12:27 PM
To: Mark Rivers; [email protected]<mailto:[email protected]>
Subject: Re: areaDetector: ADBinX/Y and ADSizeX/Y interactions

At present my readback records have a field that says:

   field(SCAN, "I/O Intr")

Is the asyn:Readback option an alternative or a possible addition?

Phil
On 14/01/2016 18:10, Mark Rivers wrote:
Hi Phil,

Ø  Out of interest: in the case of the CMOS cameras you choose to ignore the error rather than force the binning value to 1,

Ø  whereas if binning is set to less than one then you do change the value of the parameter.

Ø  Is there a 'philosophy' guideline you're applying there?

The actual value of the parameter being used should be set in the parameter library.  You make a good point, in this case the code should really be:

    s = PvAttrUint32Set(this->PvHandle, "BinningX", binX);
    if (s == ePvErrNotFound) {
        binX = 1;
        setIntegerParam(ADBinX, binX);
    } else status |= s;

    s = PvAttrUint32Set(this->PvHandle, "BinningY", binY);
    if (s == ePvErrNotFound) {
        binY = 1;
        setIntegerParam(ADBinY, binY);
    } else status |= s;

Ø   (I'm still struggling with whether to provide _RBV database records for all settings, and when to change the parameter and when to just override it).

It is almost always a good idea to provide _RBV records so the user can see the parameter value actually being used by the driver in case it differs from the requested value.  It is also possible to make the output record update to reflect the new choice by setting the info tag asyn:READBACK in the database.  Sometimes this is desirable and sometimes it is not.

Mark

From: Phil Atkin [mailto:[email protected]]
Sent: Thursday, January 14, 2016 11:57 AM
To: Mark Rivers; [email protected]<mailto:[email protected]>
Subject: Re: areaDetector: ADBinX/Y and ADSizeX/Y interactions

Thanks Mark.

Out of interest: in the case of the CMOS cameras you choose to ignore the error rather than force the binning value to 1, whereas if binning is set to less than one then you do change the value of the parameter.  Is there a 'philosophy' guideline you're applying there?  (I'm still struggling with whether to provide _RBV database records for all settings, and when to change the parameter and when to just override it).

Phil
On 14/01/2016 17:39, Mark Rivers wrote:
Hi Phil,

You are correct.

The units of ADSize are intended to be in unbinned detector pixels.  The ADProsilica::setGeometry is a good example.  Their API defines the readout region size in binned pixels, so the driver sets it to ADSizeX/ADBinX.  I can’t promise that all detector drivers have been written to follow this convention, but they should be.

Here is the code for the Prosilica driver.

asynStatus prosilica::setGeometry()
{
    int status = asynSuccess;
    int s;
    int binX, binY, minY, minX, sizeX, sizeY, maxSizeX, maxSizeY;
    static const char *functionName = "setGeometry";

    /* Get all of the current geometry parameters from the parameter library */
    status |= getIntegerParam(ADBinX, &binX);
    if (binX < 1) binX = 1;
    status |= getIntegerParam(ADBinY, &binY);
    if (binY < 1) binY = 1;
    status |= getIntegerParam(ADMinX, &minX);
    status |= getIntegerParam(ADMinY, &minY);
    status |= getIntegerParam(ADSizeX, &sizeX);
    status |= getIntegerParam(ADSizeY, &sizeY);
    status |= getIntegerParam(ADMaxSizeX, &maxSizeX);
    status |= getIntegerParam(ADMaxSizeY, &maxSizeY);

    if (minX + sizeX > maxSizeX) {
        sizeX = maxSizeX - minX;
        setIntegerParam(ADSizeX, sizeX);
    }
    if (minY + sizeY > maxSizeY) {
        sizeY = maxSizeY - minY;
        setIntegerParam(ADSizeY, sizeY);
    }

    /* CMOS cameras don't support binning, so ignore ePvErrNotFound errors */
    s = PvAttrUint32Set(this->PvHandle, "BinningX", binX);
    if (s != ePvErrNotFound) status |= s;
    s = PvAttrUint32Set(this->PvHandle, "BinningY", binY);
    if (s != ePvErrNotFound) status |= s;

    if(!status){
      status |= PvAttrUint32Set(this->PvHandle, "RegionX", minX/binX);
      status |= PvAttrUint32Set(this->PvHandle, "RegionY", minY/binY);
      status |= PvAttrUint32Set(this->PvHandle, "Width",   sizeX/binX);
      status |= PvAttrUint32Set(this->PvHandle, "Height",  sizeY/binY);
    }

    if (status) asynPrint(this->pasynUserSelf, ASYN_TRACE_ERROR,
                      "%s:%s: error, status=%d\n",
                      driverName, functionName, status);
    return((asynStatus)status);
}

Mark

From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Phil Atkin
Sent: Thursday, January 14, 2016 9:40 AM
To: [email protected]<mailto:[email protected]>
Subject: areaDetector: ADBinX/Y and ADSizeX/Y interactions

As I understand it, the ADSize parameters are intended to determine the dimensions of the _physical_ region of the sensor that is read out.  That's why the constraint imposed is

    ADMin + ADSize <= ADMaxSize

This means that the output array from an areaDetector driver should have dimensions given approximately by ADSize/ADBin for each dimension.

Is this correct?

Thanks,

Phil Atkin
--
[cid:[email protected]]Pixel Analytics is a limited company registered in England. Company number: 7747526; Registered office: 93A New Road, Haslingfield, Cambridge CB23 1LP

--
[cid:[email protected]]Pixel Analytics is a limited company registered in England. Company number: 7747526; Registered office: 93A New Road, Haslingfield, Cambridge CB23 1LP

--
[cid:[email protected]]Pixel Analytics is a limited company registered in England. Company number: 7747526; Registered office: 93A New Road, Haslingfield, Cambridge CB23 1LP

--
[cid:[email protected]]Pixel Analytics is a limited company registered in England. Company number: 7747526; Registered office: 93A New Road, Haslingfield, Cambridge CB23 1LP

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System