How to use VISA Read in a neat way

[Jon Sjöstedt]

Hello all!

I am using VISA to communicate with instruments. I read the response from a query (say *IDN?) using VISA Read. Lets say that the response is (for no particular reason) larger than some read byte count that I specify (Say 5). To read the whole result, I do "VISA Read" many times. Is there a way to know when the complete buffer is read without waiting for a read time out?

(Comparing "byte count" and "return count" wont do it. Every time the instruments bufferd data size is equal to my static read count, I would think that there is still more data to read, and I would still have to handle a timeout error)

Any ideas?

[ASTDan]

I like using VISA events. You can create a VISA event on a carriage return. When a carriage return happens (or another event of interest) you can read all available data on the buffer.

I have found this a very stable way of reading serial data

Hope this helps

Dan

[Jon Sjöstedt]

I am afraid that it does not work for GPIB (or in a general case). I am currently using the SRQ-event to wait for STB

[TobyD]

QUOTE (Jon Sjöstedt @ Nov 10 2008, 08:07 AM)

I am afraid that it does not work for GPIB (or in a general case). I am currently using the SRQ-event to wait for STB

Take a look at http://www.ni.com/support/gpib/max/tips95.htm' target="_blank">this article. It talks about using termination characters for GPIB reads and writes (you can do something similar for serial ports). If you have a port setup with a termination character, you can tell it to read 200 bytes, but if it hits the termination character after 15 bytes it will stop. If your instrumentation supports this it is a nice way to read in one response at a time.

[shoneill]

QUOTE (TobyD @ Nov 10 2008, 06:18 PM)

Take a look at http://www.ni.com/support/gpib/max/tips95.htm' target="_blank">this article. It talks about using termination characters for GPIB reads and writes (you can do something similar for serial ports). If you have a port setup with a termination character, you can tell it to read 200 bytes, but if it hits the termination character after 15 bytes it will stop. If your instrumentation supports this it is a nice way to read in one response at a time.

If you're certain the termination character is being sent, telling the VI to read a silly large number of bytes (999 for example) then the VI will only terminate after whichever one of these three things happens first

1. 999 Bytes are read

2. Timeout is reached

3. Termination character was read (Independent of the number of bytes until that moment).

Shane.

[Jon Sjöstedt]

shoneill:

You're pretty close to the problem that i am thinking of. Your solution work for queries with short data lengths. Problem arises if, for example, a large signal analyser sweep is fetched. Ofcourse one could still set read count to "integer maximum", but the solution is ugly and smells brute force problem solving style.

To me the ultimate solution would be to read STB over and over again and check the MAV-bit and read more data from the output buffer when MAV is still high. This does not work properly (probably due to problems reading STB and nothing else).

Guess this post doesnt add much...

[shoneill]

QUOTE (Jon Sjöstedt @ Nov 11 2008, 12:34 PM)

shoneill:

You're pretty close to the problem that i am thinking of. Your solution work for queries with short data lengths. Problem arises if, for example, a large signal analyser sweep is fetched. Ofcourse one could still set read count to "integer maximum", but the solution is ugly and smells brute force problem solving style.

To me the ultimate solution would be to read STB over and over again and check the MAV-bit and read more data from the output buffer when MAV is still high. This does not work properly (probably due to problems reading STB and nothing else).

Guess this post doesnt add much...

Well I guess most messages are shorter than the byte limit....

I'm a bit rusty, but assuming the termination character gets returned along with any text on the port.....

It would also be possible to check the received string for

1. Size (if it's 999 Bytes long, chances are there's more data to be read

2. If the last character in the received string is the termination character

Concatenating the strings should be easy enough after that.

Nothing ugly about it.

Shane.

[denknutson]

QUOTE (Jon Sjöstedt @ Nov 11 2008, 03:34 AM)

shoneill:

You're pretty close to the problem that i am thinking of. Your solution work for queries with short data lengths. Problem arises if, for example, a large signal analyser sweep is fetched. Ofcourse one could still set read count to "integer maximum", but the solution is ugly and smells brute force problem solving style.

To me the ultimate solution would be to read STB over and over again and check the MAV-bit and read more data from the output buffer when MAV is still high. This does not work properly (probably due to problems reading STB and nothing else).

Guess this post doesnt add much...

The whole idea of polling anything strikes me as an extremely inelegant method. With GPIB, there is ALWAYS a termination character. With 488.2 instruments, it HAS to be EOI. Setting the number of bytes to some arbitrary number has long been an established method. It is certainly much faster than trying to guess the number of bytes and doing some polling. When an instrument has 10 bytes to return, specifying 1000 bytes for the VISA Read has identical behavior to specifying 10.

For queries that might return large data sets, the instrument will often return a header of known size. This header can be read and the number of bytes in the remaining data can be parsed out. Looking at some of the existing instrument drivers will be of great benefit.

[jdunham]

QUOTE (shoneill @ Nov 11 2008, 05:42 AM)

It would also be possible to check the received string for

1. Size (if it's 999 Bytes long, chances are there's more data to be read

2. If the last character in the received string is the termination character

VISA will return different error/warning codes in the error cluster for the different situations you are discussing.

[shoneill]

QUOTE (jdunham @ Nov 11 2008, 09:48 PM)

VISA will return different error/warning codes in the error cluster for the different situations you are discussing.

Ah, that's true indeed.

I actually used to wonder about the warning from a VISA read to the tune of "The amount of Bytes read was equal to the amount requested, there may be more to read". I used to think Duh!, stupid computer but now (After all these years doing RS-232 interfacing) I actually understand why that warning is there. I've always had to deal with Instruments returning either fixed-length replies or short replies, so I never ran into the real-world case that a reply needed more than one VISA read to accomplish.

Thanks for that flash of insight... :ninja:

Shane.

[jdunham]

QUOTE (shoneill @ Nov 11 2008, 02:12 PM)

I actually used to wonder about the warning from a VISA read to the tune of "The amount of Bytes read was equal to the amount requested, there may be more to read". I used to think Duh!, stupid computer but now (After all these years doing RS-232 interfacing) I actually understand why that warning is there. I've always had to deal with Instruments returning either fixed-length replies or short replies, so I never ran into the real-world case that a reply needed more than one VISA read to accomplish.

Well I think it's a lame way for VISA to give you that information. It would be better to have a boolean output for "TermChar found?", but that's what you get with an API developed by an industry committee. I guess it's fine if you use RS-232 just like GPIB (which is the intention behind VISA) but if you use RS-232 for other devices, you frequently don't get termination characters, and you have to jump through some hoops to get that working with VISA (NI: If you don't believe me just look at the forum topics on this).

[shoneill]

QUOTE (jdunham @ Nov 12 2008, 03:10 AM)

Well I think it's a lame way for VISA to give you that information.

:thumbup:

[TG]

QUOTE (jdunham @ Nov 12 2008, 01:10 AM)

Well I think it's a lame way for VISA to give you that information. It would be better to have a boolean output for "TermChar found?", but that's what you get with an API developed by an industry committee. I guess it's fine if you use RS-232 just like GPIB (which is the intention behind VISA) but if you use RS-232 for other devices, you frequently don't get termination characters, and you have to jump through some hoops to get that working with VISA (NI: If you don't believe me just look at the forum topics on this).

I agree with that.

I have never been able to get away with using termination character on any serial instrument I had to make a driver and having it be 100% reliable

and I have done plenty of them on all kinds of instruments, very few of which give a short consistant response that you can count on.

[David Boyd]

QUOTE (jdunham @ Nov 11 2008, 08:10 PM)

Well I think it's a lame way for VISA to give you that information. It would be better to have a boolean output for "TermChar found?"...

Let me add a "me, too!" reply to this. Like others who have responded, I've written VISA serial code for countless devices (sometimes it's an instrument, sometimes it's the UUT) where the single-character termination simply does not apply. Invariably I end up with some sort of looping, scooping, bytes-at-port?/shift-register/string-appending/match-pattern/splitstring... ...you get the idea. All because the reply from the device has a two-char termination sequence, or some DLE-escaped format, or the checksum follows the term sequence, or the message starts with a length byte, or they use a CRC16, or any one of a dozen variations on the theme. I've long wished for a VISA extreme makeover that would include advanced pattern matching built in to the API. I don't have a clear vision for exactly how it would work, but I trust that those clever folks at NI would come up with something very useful...

Until then, I just have fun writing drivers for the stuff nobody else wants to take on. Which isn't so bad.

Dave