On Apr 29, 2014, at 12:34 AM, Dirk Zimoch <[email protected]> wrote:
Hi Peter,
Maybe you are using a too old version of StreamDevice?
For most devices, I try to read first 1 byte with ReplyTimeout and then the rest with ReadTimeout. For serial and socket this works fine. But GPIB devices must be addressed to talk and then deliver complete messages. If I now ask for only 1 byte, the GPIB driver reports overflow. (Unfortunately it does not store the message in some local input buffer where could pick it up later.)
Thus I have modified StreamDevice to handle GPIB devices differently and read larger messages. I have changed that behavior quite some time a
BTW: At the moment, I am working on a more flexible solution, because there are other devices, that behave similarly without having a asynGpibType interface (e.g. usbtmc). Progress is slow however because of lack of time.
The asyn USBTMC driver does read large blocks from the device and buffers them for later delivery to higher level code. This results in an extra copy operation but provides more flexibility in the size of transfers requested by the higher level code. So StreamDevice should work as-is since the USBTMC driver semantics match those of serial and socket devices.
Also, the USBTMC driver properly reports ‘end-of-message’ conditions so the higher level code can use that in place of, or in addition to, terminator characters to detect the end of data.