VISA read timeout, all data received

[ThomasGutzler]

Hi,

I'm connecting to a Rigol DZ1000 Oscilloscope via USB and using the :DISP:DATA? ON,0,PNG command to grab a screenshot. Reading out the data in blocks of 65535 bytes until there is no more (see attached vi).

This normally works fine but yesterday I was getting a timeout error. I fired up IO Trace and got this:

> 783.  viRead (USB0::0x1AB1::0x04CE::DS1ZA201305475::INSTR (0x00000001), "#9000045852‰PNG.......", 65536 (0x10000), 45864 (0xB328))
> Process ID: 0x000039C8         Thread ID: 0x00001760
> Start Time: 13:13:54.1169      Call Duration 00:00:10.4323
> Status: 0xBFFF0015 (VI_ERROR_TMO)

You can see that 45864 bytes were received, which is exactly what was specified by the binary data header (45852 data bytes + 11 header bytes + 1 termination char)

I dumped the reply string into a binary file and set the scope to run so it show something else on the screen. Sure enough the error went away. I also dumped a good result into a file. Then I tried to figure out what the problem may have been but I didn't get anywhere. Any ideas? Sure looks like a bug in VISA read or perhaps an incorrectly escaped reply from the scope?

It's very easy to "convert" the reply into the screenshot - just remove the leading 15 bytes (4 bytes from WriteBinayFile and 11 bytes from the scope header). And yes, both data files display just fine as PNG. I don't think PNG does internal checksum so byte errors would be hard to spot.

Any ideas what could have caused that timeout?

[crossrulz]

I recommend you make a new VI to use the data block protocol.  Here's the code I use for this.  In short, you send your query command and read the # and the first number.  This tells you how many bytes are in the "size" section.  So you read that many bytes and convert that to a number.  This will now tell you how many bytes are in the actual data.  So read that many bytes and then 2 more to act as the termination character.  Now a key here is you need to turn off the termination character so that you don't have to keep trying to read more data due to a data value just happening to match the termination character.

[ThomasGutzler]

I see where you're coming form @crossrulz, but if the presence of a term char in the data was a problem, why am I getting exactly the right amount of bytes?

Edited August 6, 2020 by ThomasGutzler

[Rolf Kalbermatter]

9 hours ago, ThomasGutzler said:

I see where you're coming form @crossrulz, but if the presence of a term char in the data was a problem, why am I getting exactly the right amount of bytes?

Because your logic is not robust. First you seem to use termination character but your binary data can contain termination character bytes too and then your loop aborts prematurely.

Your loop currently aborts when error == True OR erroCode != <bytes received is bytes requested>. Most likely your VISA timeout is a bit critical too?

Also note that crossrulz reads 2 bytes for the <CR><LF> termination character while your calculation only accounts for one. So if what you write is true, there still would be a <LF> character in the input queue that will show up at the next VISA Read that you perform.  

As to PNG containing checksum: Yes it does, multiple even! Each data chunk in the image data is compressed with the zlib deflate algorithme and this contains a CRC32 checksum!

Edited August 6, 2020 by Rolf Kalbermatter

[ThomasGutzler]

Ok, I obviously got fooled by the abstraction of the VISA driver.

The reason why my initial code "works" is that I never enabled the Term Char. Without looking up the details of the communication protocol over USB I'm assuming that it contains some sort of "message end" that isn't a term char but is understood by VISA. Otherwise, I'd be getting timeout errors on the 65535 byte reads.

Nevertheless, I have changed my reads to the suggested method (but without term char enabled) and queried the scope using the old method until I got another timeout. And there is no timeout using the new method. This makes no sense to me knowing term char is disabled.

Finally, regarding the 1 byte vs. 2 bytes at the message end. All messages I'm getting end on "0A" but not "0D0A".