Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Zero length length requests, EPICS upgrades, and cothread
From: Matt Newville <newville@cars.uchicago.edu>
To: Emmanuel Mayssat <emayssat@outlook.com>
Cc: EPICS mailing list <tech-talk@aps.anl.gov>
Date: Mon, 16 Dec 2013 19:08:45 -0600
Hi Emmanuel,

On Mon, Dec 16, 2013 at 6:37 PM, Emmanuel Mayssat <emayssat@outlook.com> wrote:
> I use cothread and pyepics.
> Cothread is also a dependency of the PythonQt MASAR which is developed (and
> therefore probably used) at NSLSII
>
>> That is, if we know that elements NORD through NELM-1 are not valid
>> data then it seems better to not return them, unless the user
>> explicitly asks for it. Then again, I think it would be preferable to
>> have uniform behavior. Looking forward to hearing what the best
>> approach should be...
>
> To complicate things a little, let me just say that there is a mental model
> (intuitive model) that both implementations  should (maybe) conform to.
> caget on a waveform should return NORD elements
> caput $waveformPV $value should return an error (wrong syntax) or set the
> waveform to a size 1 array
> caget(waveformPV,count=N,fill_value=-1.234) returns N elements where the
> first few are from the waveform (NORD elements) and the rest is filled with
> fill_value. Count can be greater than NELM, if count is -1, then returns
> NELM elements.

That seems reasonable.   Simply returning NORD values unless
explicitly asking for a particular number seems OK to me too.  If a
specific number is asked for (even if exceeding NELM), it's probably
preferable to always return number asked for.  Having an optional
fill_value seems reasonable.  Is this an acceptable re-statement of
your rules:

   caget(pvname, count=0)    return NORD values, no matter what NORD is.
   caget(pvname, count=-1)   return NELM values
   caget(pvname, count=N)   return N values, even if N > NELM

default is count=0.

I'm not sure I understand the what the problem is with
    caput pvname value

How can you tell that what the user wrote is not what the user
intended?  What if you want to write a 1 element array to a waveform?

> *About changing behavior and upgrading software*
> I occasionally read that people are afraid to change the behavior of their
> software because "they are going to break their accelerator". Personally,
> when I upgrade, I do major QA. Additionally I allow for partial/progressive
> deployment . In an upgrade, I expect (minor) issues and am ready to rollback
> the upgrade if required.
> In my view, changes are perfectly acceptable if you get closer to the mental
> model, i.e. make you software more intuitive and programmer-friendly. What
> may not be acceptable is when core developers of "collaborative" software
> stops their improvements because they are told that the intended changes
> would break their accelerator. As a result, the entire collaboration is held
> hostage.
> Obviously it helps if the changes are documented in the release file.

I agree.

I don't really have a strong opinion on what the behavior should be,
but it does seem like there is some confusion here.  It would be
helpful to clarify what the canonical behavior should be for all CA
clients.

-- 
--Matt Newville <newville at cars.uchicago.edu> 630-252-0431

References:
Zero length length requests, EPICS upgrades, and cothread michael.abbott
Re: Zero length length requests, EPICS upgrades, and cothread Andrew Johnson
Re: Zero length length requests, EPICS upgrades, and cothread Matt Newville
RE: Zero length length requests, EPICS upgrades, and cothread Emmanuel Mayssat

Navigate by Date:
Prev: RE: Zero length length requests, EPICS upgrades, and cothread Emmanuel Mayssat
Next: RE: Mclennan PM600 motor controller Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: RE: Zero length length requests, EPICS upgrades, and cothread Emmanuel Mayssat
Next: RE: Zero length length requests, EPICS upgrades, and cothread michael.abbott
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·