VISA Reads and Writes (queries)

[agill]

Hello,

I've been sending SCPI/GPIB commands through VISA write functions in LabVIEW (7.1.1).

I'm confused on how to send queries.  I undestandy you have to write the query to your instrument using a VISA WRITE (and fill the write buffer with the SCPI query command), and then you need to read it back using a VISA READ command.  However, it is unknown to me the number of "bytes to read" to pass to the Visa READ command.   

Is it simply just the "byte count" returned from the VISA WRITE command?  OR, should there be some documentation that would tell me how many bytes to read.  If so, I haven't found it listed with my SCPI commands.

Luckily, I know what type of sinks I am using.  For example, in the case of reading a single I32, I've been passing 4 bytes to the read command, hard coding it in.  However, that doesn't count for overhead, such as header info...  Please help clarify this.

Then the follow up question: Then that following data is put in a string.  How do I get the appropriate data out from the string?  Let's make it simple and use an I32.  Do I just typecast the string?  Or do I use "convert decimal string to number" vi?  From my research, both ways are applicable?

Thanks in advance.

Edit:

I posted this in the hardware boards.  It probably belongs here.

Message Edited by agill on 07-20-2006 11:52 AM

[BrianInTheForest]

I use the VISA Interactive Control tool located in MAX under Tools>NI -VISA to see how many bytes my Visa Read returns.  You might need to do some parsing of the data depending on what you want.  Most of my reads I use the  Fract/Exp String to Number Function.

Brian

[Dennis_Knutson]

You do not wire the return count from the VISA Write to the byte count of VISA Read. The return count is just the number of bytes actually and has no releationship to the number of bytes you can expect back. From your user manual, you can get a rough idea of how many bytes to expect but you can safely wire some large number to the byte count without any problems. The VISA Read will automatically terminate when the instrument asserts EOI and that is automatically appended at the end of the message. So, if you specify 1000 bytes to read and the instrument sends 10, all you will get back is 10 bytes. Your only danger is in specifying too low of a byte count.

For the string conversion, I prefer to use Scan From String. Type cast is not appropriate in most cases. Type casting the string '5' to a U8 for example, will not give you the value 5. It will give you decimal 49 which is hex 31 which is the ASCII representation of the character '5'.

[agill]

So then what is the purpose of "byte count" from the Visa Write?

[Dennis_Knutson]

It's mostly just for informational purpose. You'll seldom see it wired to anything. I'll use it occasionally during debug. There might be occasion when you are sending a very long string. Most instruments have a limited buffer size so if you get an error from the instrument, you can check this to see if you've written too long of a string.

Message Edited by Dennis Knutson on 07-20-2006 01:23 PM

[agill]

Oh, thanks for your help again, Dennis.

I didn't realize you can safely wire a large amount to the Visa READ terminal.  That makes things a lot easier for functionality testing.  Thanks a lot! 🙂

[unclebump]

Another useful VISA property node is the Number of Bytes at Port.

http://zone.ni.com/reference/en-XX/help/371361A-01/lvinstio/visa_bytes_at_serial_port/

[agill]

Problem is, that's serial.  Actually, in general, the LV documentation/examples on VISA Reads/Writes all deal with serial operations.  Quite inconvenient, as it's hard to find serial ports on modern day computers (notebooks).

Message Edited by agill on 07-20-2006 02:19 PM

[agill]

Another follow-up question:

In this tutorial: http://zone.ni.com/devzone/conceptd.nsf/webmain/4d2fbf082ed2412a8625716b006c796b

They have nothing wired to the "bytes to read" terminal of the Visa READ VI, and it is still supposed to work.  Is leaving the "bytes to read" terminal blank equivalent of wiring a large number to the "bytes to read terminal?"

I also noticed that they terminated the ID query with a newline \n...  I don't explicitly do this in my commands.  Should I?  I've seen examples of other drivers that don't use the newline char code.  The documentation that I'm using doesn't mention using the newline char either.

Thanks again for your help.

[Dennis_Knutson]

I have no idea why the example doesn't have the bytes to read wired up. Afaik, you have to wire something there or it will default to 0.

The CR or LF character is often required to terminate the commands with serial instruments. Serial instruments lack a well-defined standard like 488.2 that says that a talker or listener use EOI. However, some GPIB instruments (especially older ones) don't exactly follow the standard and may require a command be terminated with a different or additional characters. You may also see some drivers written like this to make them compatible with both GPIB and serial versions of the instrument. You can set a VISA property to do this but some programmers may choose not to do that (or may not be aware of the other technique). A GPIB instrument will usually ignore the extra character if present.