1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: areaDetector: ADBinX/Y and ADSizeX/Y interactions |
From: | Mark Rivers <[email protected]> |
To: | "'Phil Atkin'" <[email protected]>, "[email protected]" <[email protected]> |
Date: | Thu, 14 Jan 2016 18:10:21 +0000 |
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]]
Thanks Mark. On 14/01/2016 17:39, Mark Rivers wrote:
-- |