Experimental Physics and Industrial Control System
Perhaps Dirk or someone else could add an 'IEEE-488 Block Data' input converter to StreamDevice. This is one of the few places where the old 'devGpib' EPICS support is more capable -- see the TDS3000 EPICS support module for an example of how this works. It provides a mechanism for reading blocks of binary data by prepending a simple header containing:
1) The character '#'
2) A digit 1-9 specifying the number of digits in the following number
3) 1-9 digits specifying the number of bytes in the following block of data
4) The data
For example, a binary waveform containing 12000 bytes might have the header '#512000' or '#9000012000'.
I'm not sure if it would help in this case of obtaining an image dump from the device, but it would make things like scope waveform captures a lot easier.
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.
>
>
--
Eric Norum
[email protected]
- Replies:
- Re: [Scopes] BMP image record?? Pavel Masloff
- 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
- Re: [Scopes] BMP image record?? Rod Nussbaumer
- Navigate by Date:
- Prev:
Re: [Scopes] BMP image record?? Rod Nussbaumer
- Next:
RE: asynPortDriver callbacks to I/O Intr, how to propagate an error? Mark Rivers
- 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
- Navigate by Thread:
- Prev:
Re: [Scopes] BMP image record?? Rod Nussbaumer
- Next:
Re: [Scopes] BMP image record?? Pavel Masloff
- 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