08-24-2011 05:16 PM
Hi,
I'm using LabVIEW version 7.1 with an SR510 lock-in amplifier connected through GPIB-488.2. I've gotten past most of the hurdles, the device appears in MAX and I can send and recieve data using the VISA test panel. My main goal is to be able to have a VI where I am continuously asking the SR510 to output a voltage number while the data recieved is then saved in a .txt document and graphed as a function (simple x-y). The issue I am having is that the SR510 will not take more than one "q" command to output data. I can clear the settings of the lock-in with a "z" command, and then give it a "q" command and it will output correct information but if I try to run it continuously I get an error. I've tried using variations of the same "q" command (e.g. adding a needed carriage return, \r, \n) but none of them produce any different results. I should also mention that this issue only occurs with the "q" or output data command. Other write/read commands can be issued multiple times in rapid succession without any issues. I would be greatful if anyone had any advice as to why this might be occurring. Also I apologize if some of my terminology is incorrect as I was only just introduced to LabVIEW a few days ago.
Thank you for your time,
Sal
08-25-2011 05:39 PM
If you are brand new to LabVIEW, I would recommend looking at the VISA/GPIB shipping example to familiarize yourself with the different functions and how they interact. Go to Help»Find Examples... to open the example finder. The GPIB example is located in Hardware Input and Output»VISA»GPIB-VISA.vi.
When you say " I can clear the settings of the lock-in with a "z" command, and then give it a "q" command and it will output correct information but if I try to run it continuously I get an error." do you mean that you try and continously give it a "q" command and then a "z" command and it errors, or you just give it a "q" command? It may be possible to alternate between a "q" and "z" command inside a while loop to continuously output and then clear the settings and output again. It may also be that this device is not capable of continous output. I would check the user manual to see if this kind of operation is possible, and if so how to accomplish it. Let me know how it goes and if you have any more questions.
09-09-2013 08:13 PM
Hi
I connected SR510 throught RS232 and I have it problem too. I can get data from SR510 by using 'q' command ( also add <cr> ) in while loop. But it has problem. I set the delay time in VISA WRITE is 300 ms and the data return is perfect. But I need more data than that. And I set the dalay time down to 200, 100 ms, the data return is worse and I cannot get anything from this data. So anyone can help me to get data faster than 300ms??? Thank You.
So I attach my vi.
09-09-2013 10:49 PM
Your program has clear places that you can improve. Get rid of the sequence structure. It does not add any time but it's use is just silly.
Do not initiaze the port with each iteration. Do do use VISA Bytes at Serial Port. Do not use Write to Measurement File in the same loop. Use a producer/consumer architecture where the file write is done is a separate loop.
What you would be left with is a VISA Write and a VISA Read. However fast that will execute is probably the limit of the instrument.
09-10-2013 12:02 AM
Now i use 'W0' command to set the time interval between write and read to 0 . After that, i set the delay time to 20ms and use 'q' command. I get the data. Is 20ms the limit of this instrument ???
09-10-2013 12:04 AM
The limit of the instrument is going to be stated in the manual. If you have not made the modifications to your program, you may not have reached the instrument's limit.
09-10-2013 05:40 PM
Not directly Labview related, but one aspect you might not be considering is the operation of the SR510 itself.
If you set a time constant of 300 ms, for example, this is simply the time constant of the filter you're using. There is then a scaling factor for the Reserve setting and Filter Rolloff. So, if you set a 300 ms time constant with a High Reserve and 24 dB/Oct rolloff, the actual acquisition time is about 3 seconds (or 10x the time constant). If you simply want an amplitude and phase result, then polling the device faster than that might generate the problem you're describing. In effect, you'd be trying to read a port before there is data ready to be read.
Just a suggestion ...