On May 2, 2012, at 2:05 PM, Rod Nussbaumer wrote:
> 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.
>
>
