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: pilatus detecotr modify FileName problem
From: Mark Rivers <rivers@cars.uchicago.edu>
To: Matt Newville <newville@cars.uchicago.edu>, "tech-talk@aps.anl.gov >> tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Thu, 12 Dec 2013 16:02:00 +0000
The approach of sending the shorted possile NULL terminated string is what IDL and SPEC are doing as well, and we have had no problems with those languages.  In older versions of SPEC we had to convert the string to a byte array ourselves, in newer versions of SPEC this is done automatically.

Mark


________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Matt Newville [newville@cars.uchicago.edu]
Sent: Thursday, December 12, 2013 6:50 AM
To: tech-talk@aps.anl.gov >> tech-talk@aps.anl.gov
Subject: Re: pilatus detecotr modify FileName problem

Hongchunxia, Bruce, Nick,

Sorry, I see now that my second reply went only to Hongchunxia, not to
all of Tech-Talk.  Hongchunxia is using pyepics-3.2.1 which does
automatically detect and convert a Python string to Epics character
waveforms on put() and can do convert from character waveform to to a
Python string on get with an optional argument: caget(PVNAME,
as_string=True).   So Hongchunxia should not need to do this
conversion.

I believe the issue is that pyepics ca.put()  sends the shortest
possible NULL terminated string.  That is, with
    from epics import caput
    caput('MyDet:cam1:FileName', 'a string')

it will send the waveform [97, 32, 115, 116, 114, 105, 110, 103, 0],
even if the waveform has 256 elements.   My recollection is that this
is valid and the preferred approach, and it certainly works for us.
If I use command-line camonitor, this does shows only the new waveform
data.  That is
    from epics import caput
    caput('13IDEPS1:cam1:FileName', 'abc')
    caput('13IDEPS1:cam1:FileName', 'abcdefg')
    caput('13IDEPS1:cam1:FileName', 'abc')

shows
    13IDEPS1:cam1:FileName 2013-12-12 06:33:53.014812 4 97 98 99 0
    13IDEPS1:cam1:FileName 2013-12-12 06:33:59.512937 8 97 98 99 100
101 102 103 0
    13IDEPS1:cam1:FileName 2013-12-12 06:34:04.389271 4 97 98 99 0

Monitoring cam1:FileName_RBV shows exactly the same results.

But, we tend to stay up-to-date with versions of base and
areaDetector.  This definitely needs a somewhat recent version of
base, but I think Hongchunxia said they were using 3.14.12.2, which
should be fine, I think.   It's believable that a client program
(perhaps an older version of areaDetector?) would not handle this
properly if it is set up to monitor this PV, receives the shorter
array, and uses it to only set the first 9 elements of its internal
cache for a waveform.   I think a very old version of areaDetector did
have this problem, but it was fixed a few minor versions back.   It's
also possible (but less likely, especially for areaDetector) that a
client program would ignore 0s in a character waveform when converting
to a string.

Anyway, I'm not sure where the problem actually is, but my guess is
that this is the root of the problem.  It appeared (but wasn't
completely clear) that the MEDM screen showed a  cam1:FileName_RBV
that was longer (and had a suspicious space) than the value for
cam1:FileName.  I don't know if that could be that MEDM needs
updating.  Again, this has worked well for us for long enough that I
don't remember which versions didn't work.

Writing to the cam1:FileName_RBV field may be possible, but is a poor
workaround.  Any write to cam1:FileName will overwrite this.

Cheers,

--Matt Newville

Replies:
Re: pilatus detecotr modify FileName problem Matt Newville
References:
pilatus detecotr modify FileName problem 洪春霞
RE: pilatus detecotr modify FileName problem nick.rees
Re: pilatus detecotr modify FileName problem Bruce Hill
Re: pilatus detecotr modify FileName problem Matt Newville

Navigate by Date:
Prev: RE: Mclennan PM600 motor controller Mark Rivers
Next: Re: pilatus detecotr modify FileName problem Matt Newville
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: pilatus detecotr modify FileName problem Matt Newville
Next: Re: pilatus detecotr modify FileName problem Matt Newville
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 ·