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 | 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 |
<== 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.