EPICS Controls 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  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: [Scopes] BMP image record??
From: Rod Nussbaumer <[email protected]>
To: Pavel Masloff <[email protected]>
Cc: EPICS Tech Talk <[email protected]>
Date: Wed, 02 May 2012 14:05:50 -0700
I hit send before reading the whole question...

There are two timeouts for 'in' commands:

ReplyTimeout is the max time to wait for the first byte.
ReadTimeout is the max time to wait between any subsequent byte(s).

Once the data begins to flow, the read will should not terminate until either the record has filled (NELM), or a ReadTimeout period elapses. I don't recall what the default ReadTimeout is, but that is the value which will ultimately terminate your read. You do not need to make either timeout long enough to capture the entire file from start to finish.

I don't think you can use the %#s converter, nor can you terminate the read on any particular byte, including \n, as these can be valid bytes in a binary-formatted stream such as an image file. Scanning as string data types in EPICS stops after 40 characters.

> Remember you proposed setting a big timeout and a "" separator? Will
> that work?

I think you are referring to the protocol snippet that I copied, but my only intention was to highlight the nature of the format converter. The other parameters were just copies of the original, from you I think. You may have to determine empirically what the longest gap in the data stream is, and use a ReadTimeout just slightly longer than that. If you turn on asyn's traceIODriver, you should be able to post-process the verbose IOC shell data to determine something about the timing of incoming data. For a large file transfer, you will probably have to capture the output to some kind of log file, and use a script to analyze the results.

   ---  rod.



Pavel Masloff wrote:
Sorry, is nnn a number of expected bytes/characters? I haven't found any
explanation on the %c converter with this option on the official
StreamDevice web-site.
My incoming image has a variable length from 10kB up to 46kB. So in my
case how should I write the protocol? Maybe until the \n character?
Remember you proposed setting a big timeout and a "" separator? Will
that work?

I have also found the %#s converter. Perhaps, try this?

I am using RS232 rather than GPIB, but I wait ~ 10 seconds to get a
14-20kB file when getting the image by means of Python.

On Wed, May 2, 2012 at 7:32 PM, Rod Nussbaumer <[email protected]
<mailto:[email protected]>> wrote:

    The %c converter should do it, along with a 'width' number of
    expected characters (nnn in the example below). If this is to read
    an unknown number of bytes, then the 'nnn' quantity will result in a
    timeout to terminate the read. You would want to use @readtimeout to
    set some reasonable number for that timeout.
    I've used this method for reading binary formatted scope waveforms
    where the number of bytes in the waveform is known a priori, but
    never for reading a block of unknown size. There does seem to be an
    as yet unresolved performance issue in streamDevice when the asyn
    port driver is linuxGPIB, in case that is your architecture. I ended
    up using a bare asyn record with DTYP=asynOctetCommandResponse to
    solve it, coupled with a subroutine record to strip off an un-needed
    header and perform a converison to multi-byte words.


     > PrtScr {
     >      InTerminator = "";
     >      ReplyTimeout = 15000;
     >      out "HARDCOPY START";
     >      in "%nnnc";
                ^^^^

     > }

       ---   rod.

Replies:
Re: [Scopes] BMP image record?? Eric Norum
References:
[Scopes] BMP image record?? Pavel Masloff
RE: [Scopes] BMP image record?? Mark Rivers
Re: [Scopes] BMP image record?? Pavel Masloff
RE: [Scopes] BMP image record?? Mark Rivers
Re: [Scopes] BMP image record?? Pavel Masloff
Re: [Scopes] BMP image record?? Rod Nussbaumer
Re: [Scopes] BMP image record?? Pavel Masloff
Re: [Scopes] BMP image record?? Rod Nussbaumer
Re: [Scopes] BMP image record?? Pavel Masloff

Navigate by Date:
Prev: Re: [Scopes] BMP image record?? Rod Nussbaumer
Next: Re: [Scopes] BMP image record?? Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: [Scopes] BMP image record?? Rod Nussbaumer
Next: Re: [Scopes] BMP image record?? Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·