I have written a Labview program (attached) so that two function generators (Keithley 3390's) are driven at slightly different frequencies. The two frequencies feed into my experiment and I detect out at the difference frequency using a SR830 lockin amplifier. The program itself is designed to sweep the two function generators together and also sweep the difference frequency, this produces some 2D maps of the data. For the most part it works except there are always the same staircase pattern (see pdf). This is nothing physical as we do not see it when sweeping manually.
I have done a series of tests myself to see if I can narrow down the problem:
-Increasing the number of points taken by the lockin does not change the staircase patterns.
-The staircases always appear in pairs hinting towards a problem with the Keithleys not the lockin.
-Increasing the number of frequency points increases the number of steps seen in the staircase pattern.
-Changing the program so that it runs the other way around also reverses the direction of the staircase pattern also hinting at a memory problem.
-The staircase is not seen in the HFM part of the image but only on the right because the right hand image was taken at a higher sensitivity, again hinting that it is something to do with the frequency generators.
But I can't pinpoint the problem.
Any help on this matter is appreciated,
PDF was not attached.
Any chance that part of the Keithly code contains a non-reentrant subVI that stores values in an uninitialized shift register between calls, and that is causing the data intended for one instrument to "cross-talk" with data intended for the other instrument?
Lock will not help if one of the internal VIs is non-reentrant and uses shift registers to store the data (Functional Global Variable).
In such case both devices will share some code and data storage. The devices will overwrite or corrupt the data by writing to it and read incorrect values out of the storage.
I took a look at your code and actually what worries me is the milisecond to wait time. Are you sure the devices have enough time to output the correct frequency? Did you check it in the documentation of the generator? What I would suggest is to send the command to set the frequency usign SCPI and use *WAI or other way to be sure the command is executed and the output frequency is set up correctly.
The typical wait time is usually set to around 100-200 ms between frequency steps, this should be enough time to write to the instrument and change the output seeing as the Keithly can perform an automatic frequency sweep in 1 ms.
I will use your suggestion of *WAI after the frequency change, this should speed up the program rather than waiting an amount of time that is crudely set, thanks.
Does the instrument driver not already implement SCPI at a low level?
If I was to use "VISA Clear" at the end of the loop should this erase all previous iterations in the shift register?