Trouble writing Trace Data into Rohde and Schwarz fsp7 spectrum analyzer

[fred engel]

I am having trouble writing Trace Data (8001 point arrays) to our R+S FSP7 spectrum Analyzer, to use its peak search facility. It works some of the time, and returns the peaks found. But seemingly at random, with particular data arrays, the instrument coughs up "instrument errors 113 (undefined header), 102 (syntax error), 350 (queue overflow) etc, and freezes my labview program. Other data arrays work fine, and there is no obvious difference between data that succeeds and that which fails. It repeatedly fails on the same data , and repeatedly succeeds on other data. I am suspicious of GPIB timing errors, since data which fails regularly, suddenly succeeds when I have NISPY running to trace the bus communications. I am assuming running NISPY slows down the GPIB slightly while it captures traffic, perhaps giving the GPIB interface (either on the FSP or on the PC?), or the internal operations inside the FSP time to transfer the 8001 point array without glitches. I may be wrong in this assumption. If it is timing errors, why does it only happen with particular sets of data and not with others? Could I have a slow GPIB card in my PC? It never fails on uploading the 8001 point spectra from the FSP to the PC, and only (repeatedly) fails when writing certain particular data arrays back into the FSP.

The standard RSFSP Write Trace Data.vi I am using is from the rsfsp.llb I downloaded in 2006, and I am assuming there is nothing more recent that might address this problem.

I havent found a way to slow down the transfer of the array to the FSP7

Can anyone help  or suggest further tests to isolate and identify the problem?

[Burban]

NI-SPY does slow down the timing of your program.  To fix these kinds of timing errors, you should insert a small delay between the Writes and Reads in your code.  This information is found in KB 3KPFP76K: Why Does My Application Only Work When NI-SPY is Running?

[fred engel]

Thanks Ben The 8001 point array gets delivered in a single hit by the RSFSP write data vi. I dont seem to get any opportunity to slow anything down within this. There may be a problem with the DLL inside? Is there a way you know of to modify or improve this? Do these DLL/ instrument driver vi's get written by NI or by Rohde and Schwarz? I cant understand why only certain data arrays consistently fail while others (with similar contents) never do. If it was purely a timing error, surely it would occur randomly. Any thoughts? Fred Engel

[Burban]

These instrument drivers are provided by Rodhe and Schwarz.  I am not familar with this particular instrument and its associated driver package, but you should be able to modify the VI's that come with the package to include a delay.  Just as a reference, the recommended architecture, which uses a Flat Sequence structure with a 200 ms Wait in between the GPIB Read and GPIB Write, can be seen in the LabVIEW example LabVIEW - GPIB.vi. This VI can be found by searching "gpib" in the Example Finder.