07-20-2011 08:36 AM
Hi all,
I am trying to record lockin measurements with an SR830 when changing a voltage. I have several different VIs with different voltage sources and setups that all show the same problem. My VIs usually set the Voltage wait for a delay about 3 times the Time constant and then read a value via SNAP or OUTR. This works quite well, apart from the fact that the values seem to be transferred to 3 to 10 instances later, than when the actual query was sent. For example if I stop a measuremnt and restart it I will first record the last 3-10 values of the previous measurement before the new values are recorded, so all my curves end up shifted as a function of voltage. I tried resetting the buffer (REST) or increasing the wait time, but that does not seem to work. Any Ideas how to avoid this problem and be sure the value received is actually taken at the time of the last query?
Thanks for your help...
Dominik
07-21-2011 04:22 AM
Hello Dominik,
I would suggest you try flushing the buffer so as to ensure that there is no data left in the devices memory before starting another measurement. This however seems to be a short fall with the device and not with LabVIEW, perhaps you should review what commands the device has available to it and ensure there are no built in functions that allow you to flush the device’s buffer.
Hope this Helps!
07-21-2011 05:04 AM
I tried flushing the device buffer with the REST command, with no success.
I also tried VISA and GPIB VIs, with no difference.
It seems though that the problem gets worse the longer a Labview is running. So if I do not restart Labview for 2 days, I get about 10-20 values delay, if I restart every hour the problem is manageable and its 0-1 value delay.
Is there a way to flush the receiving GPIB buffer on the computer side?
07-21-2011 06:19 AM
Hello Dominik,
Yes you can flush the buffer on the computer side, I have provided you with a VI snippet as to how it works. If you have any questions regarding to the Buffer flush function there is a forum post here that explains it.