LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

serial write and read only reads if command is written 3 times

I'm very new to this, so I may be missing something fundamental. I'm using the generic basic serial write and read VI to communicate with an SR830 lock-in amplifier, and for some reason I can only read from the instrument if I write the querying command three times. For example, if I attempt to write and then read with "*IDN?\n" as the input, I get a timeout error on the read. However, if I use "*IDN?\n*IDN?\n*IDN?", then I read the correct output. I checked in the VISA test panel to see if any attributes change before and after running the command three times, but I didn't see any changes. Any thoughts?

0 Kudos
Message 1 of 23
(4,740 Views)

Can you post your VI? My initial guess is that you may have your string format incorrect for sending the linefeed. (i.e. you may be sending a string as a regular string instead of \ codes.)

 

Either that or you may have an incorrectly configured read timeout.

0 Kudos
Message 2 of 23
(4,720 Views)

Ok I've attached it here. I don't think that's the problem, though. It will read if I write "*IDN?\n*IDN?\n*IDN?\n" in '\' Codes display mode or if I write:

*IDN?

*IDN?

*IDN?

in normal display mode. Also, in the VISA test panel, it will work if I write "*IDN?\n*IDN?\n*IDN?\n", or if I query 3 times with just "*IDN?\n". In the latter case, the first two queries will time out during the read and then the third will work. About one out of every 5 times I try that, it will work on the second query, but it never works on the first. I have the timeout set to 2 seconds, but I've tried as much as 15 seconds with no difference.

0 Kudos
Message 3 of 23
(4,711 Views)

Looks like you've got the wrong termination character. If you're configuring a termination character then you don't need to repeat it in your string to write. Some devices don't like receiving two termination characters in a row and can drop into an error state. I think you want to use 0xA as your termination character, not 0xD.

(i.e. term char = 0xA, String to Write = "*IDN?"

0 Kudos
Message 4 of 23
(4,708 Views)

I was using 0xD as the termination character since that's what the instrument terminates its output with so I can put in an arbitrarily high number of bytes to receive but it will stop reading after \r. But even if I change the termination character to 0xA and then specify that it should read 50 bytes (the size of the proper *IDN? output), it still takes three times for it to read. This is the case whether I send *IDN? or *IDN\n, and is the case whether or not I have "Send End on Writes" enabled.

0 Kudos
Message 5 of 23
(4,701 Views)

The fact that you're seeing the same issue with the VISA test panel is a bit worrisome. Have you tried using a terminal program such as puTTY to see if it really is a number of queries issue or whether it is a slow device response time issue?

EDIT: It also looks like the instrument has an option to display the serial queue on the display panel. You might want to check that out and see what characters are actually making it to the device.

Message 6 of 23
(4,694 Views)

@Taki1999 wrote:

Looks like you've got the wrong termination character. If you're configuring a termination character then you don't need to repeat it in your string to write. Some devices don't like receiving two termination characters in a row and can drop into an error state. I think you want to use 0xA as your termination character, not 0xD.

(i.e. term char = 0xA, String to Write = "*IDN?"


The part I highlighted is NOT correct.

 

He enabled the termination character using the VISA configure and that enables it for VISA Reads.  It does not affect the concatenation of a termination character for the data being written.  There is a totally separate property node that does that.  I never recommend using it.  I recommend what he is doing now which is to explicitly include the termination character as part of the Write.

 

Where your statement may lead into the correct answer is with the repeated command.  A device that receives commands too rapidly, such as getting three IDN? commands in a row, it could cause an error in the device because you basically "jam it up", with additional commands before it has had a chance to process the first one.

 

However if forcing 3 commands in a row is sometimes forcing it to respond, but one formatted command is not, then something else is wrong.  Perhaps it is the wrong termination character.  Reading the manual should clear that up.

 

 

Message 7 of 23
(4,679 Views)

Have you tried using the already built LabVIEW driver?

http://sine.ni.com/apps/utf8/niid_web_display.model_page?p_model_id=1536


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 8 of 23
(4,674 Views)

The termination character is indeed specified in the manual. The instrument accepts 488.2 formatted commands with \n (0xA) termination and sends output with a \r (0xD) termination character. I enabled termination characters and get the response described above (reads correctly with three commands written, does not with only one) whether I specify 0xD and leave the bytes read at something larger than the output or specify 0xA and specify 50 bytes. Is there another way to configure this? I've tried every permutation of "Send End on Read/Write", "Read/Write End Mode", and termination character with no luck, but I may have missed something.

 

I don't think the device response time is the issue, since when I send the triple command, it reads the output promptly (<< 1 sec).

 

I used the instrument display to check whether it is correctly receiving the commands, and indeed it shows "*IDN?\n" (or the same thing three times) depending on how many times I send it. Thanks for pointing this out, though - I wasn't aware of this useful feature!

 

Regarding the suggestion to use the existing driver, I was trying to figure out a workaround for the RS232 port so I wouldn't have to drop $700 on the GPIB-to-USB adapter. But of course, only the GPIB driver exists, so I'm trying to make my own interface since I don't have to do anything more complicated than tell the lock-in when to start taking data, read the buffer, then clear the buffer.

 

Thanks to everyone for all the help and suggestions so far - I'm really stumped!

0 Kudos
Message 9 of 23
(4,657 Views)

Let's dig into the manual...on page 5-2 (94), there is a clear message: "The OUTX i command should be sent before any query commands to direct the responses to the interface in use."

 

In the driver I linked to earlier uses the following command for querying the ID: "OUTX1;*IDN?;"  See that OUTX1?  You should use OUTX0 instead to set the output port to use the RS-232.

 
 

GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 10 of 23
(4,637 Views)