Instrument Control (GPIB, Serial, VISA, IVI)
GPIB control of SR830 lock-in : read/write problem
Solved!
Hi
I'm using Labview 2009 SP1 and the Visa drivers to control a Keithley 6221 function generator and a SR830 lock-in amp. Basically my program sets the generator at a certain frequency and amplitude, sets some stuff on the lock-in, queries a few values, then reads data from the lock-in for a minute or so. This is then repeated at several different frequencies. This works well, except it hangs randomly from time to time, after having done several frequencies with no problem whatsoever. Today I discovered the amazing NI spy tool, so I've been able to pinpoint the bug ! Here is an output of the last commands before the bug (there is nothing else after line 63).
As you can see at line 53 I query the lock-in's frequency. However the reply (5623.46 Hz) only comes later, at line 57, which messes up the program. Following this section of the programme, I send a few more commands to the lock-in, which are ignored, and then the programme enters a while loop which is supposed to acquire a certain number of data points. This runs on infinitely as there is no data to acquire, and that's how I noticed this bug initially.
So my questions :
1) Why does this happen, and how can I avoid it ? I've also contacted the manufacturer of the SR830, but I have much faith in the great people on this board !
2) After line 63, in my program there are several more commands which are supposed to be sent to the lock-in, and then the while loop. The commands aren't sent, but Labview has to go through these to get to the while loop (which it does get to). So what exactly is Labview doing, and how/why does it go through the write commands without sending the data ?
Thanks !
Hi Albert
This is the relevant portion of code :
I can send you the whole programme if you want, but it's big and I have to tidy it up a bit ... The ERROR subvi comes from these drivers : http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=240C113D3165071BE0440003BA7CCD...
Based on the NI spy output, the problem is that following the "FREQ" command, it reads some data, but data that shouldn't be there, in this case "8."
Did you try to read more characters. Instead of 16 chars try to use the end character. Probably a cr or lf. If both are present use the last one, probably the lf.
I'll try to find the manual and some old software to check this machine.
Another thing you should try is to lower the bus speed. If you use Gpib open MAX, and set the speed to 1 microsecond. It is an old machine and should not be hurried.
Hi Albert
I think I've solved it. I use the "FAST2" mode for transferring data from the lock-in to the PC. This uses the lock-in's output buffers to transfer data, ie the same buffers used to transmit error messages, or responses to queries.
Between the moment when I read the last set of data and stop the data transfer, the lock-in has time to write a bit more data to its output buffer. This messes up the error readings, but only has a negative effect when the LIA status byte is set to 8 (ie reference unlock). When this happens, it shifts all the responses to the error queries, and the first "LIAS?" reads the answer to the "ERRS" query, and "FREQ?" reads the answer to the second "LIAS?" query. The unlock event happens when the function generator changes its frequency, but doesn't happen each time, which is what made it seem random.
So this is easily solved by just reading whatever is left on the buffer before proceeding. Strangely, this only works when followed by the "ABORT" driver, which basically just sends the "REST" command. This clears the data buffers, but from my understanding of what is written in the manual, these aren't involved in the FAST2 mode.
Congratulations. Nicely found.
I never used the fast mode but surely it looks good.
The reason for the reset is probably a real notification to the system that all is normal again.
For serial you can define the endcharacter that in serial has the same function as EOS in GPIB.
With GPIB it is not needed because of the EOS that has the same function. (I always call it EOS but officially I beleive it should be EOC)
Any VISA read on GPIB will finish at receiving that command.
Even if you ask for more characters. So ask for 40 characters and you will get all until EOS. (that is no data and is not placed in the receiving string)
