Re: [Scopes] BMP image record??

[Rod Nussbaumer <bomr@triumf.ca>]

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 <bomr@triumf.ca
> <mailto:bomr@triumf.ca>> 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.