Get power measurements from Spectrum Analyzer to Desktop

[djfc]

Hello all,

I'm new in LabVIEW and I need some help.

I want to developed a program that gets power measurements from two Rohde & Schwarz SA (FSP40) via Ethernet (TPC/IP) (I have two ethernet ports). 

What I want to do is more or less what FSx_recordplay does, but it just works for one SA. And I don't need to show graphics, I just need to store measurements into my PC.

It's supposed to be done in LabVIEW, but if someone knows another program that do that (it has to send instructions at same time) its good for me.

If you need some more information please tell me.

If someone has a suggestion or an ideia, I'll apreciatte a lot.

FSx_recordplay application note attached.

Thank you,

D.C. 

[juergenstraub]

Hi, what exact measurement do you want to do and which data do you need to get from the analyzer? Did you have had already a look at the examples for the R&S LabVIEW drivers: http://www.rohde-schwarz.com/driver/FSPLabVIEW.html

Maybe these are a good starting point?

If this doesn't help please contact the R&S application team via tm-applications@rohde-schwarz.com

BR juergen.

[JÞB]

Rohde & Schwarz do publish a LabVIEW instrument driver for this available from here.  It is not supported by NI and has a rather low rating.  This usually means it only partially supports the instruments functions or has flawed features that make it unwieldly or difficult to integrate.  It also fails to support ethernet connectivity.

HOWEVER, most of the commands will remain the same regardless of the bus so, this driver may make a sensable starting point in developing a drive to meet your needs.  Visit the IDN and browse some of the material out there to understand current best practices for dirver development before jumping into duplicating bad practices

Looking through the driver:  It is in fact bloated and filled with less than ideal driver development ideas   On the other hand it appears that the VI Documentation is reasonably good and the FSP-40 driver you need could be built and built to meet current standards for a VISA Plug-n-Play style ID by applying modern IDN development guidelines

[juergenstraub]

Hi, to get an understanding of the driver and its architecture, it's useful to have a look at the application note http://www2.rohde-schwarz.com/en/service_and_support/Downloads/Application_Notes/?downid=5727. Here you can find also hints how to customize the driver according your specific needs.

According to the driver documentation GPIB and LAN/LXI (VXI-11 protocol) are supported.

@Jeff

Off topic:

Did you know that this driver implements roughly 2000 SCPI commands (in fact all current R&S SA, featuring the latest firmware versions, including all personalities). This pushes the limits of the a "Configure-Action/Status-Data-Utility" structure which is suitable for DMM and power supplies, I think.

I'm really happy to get feedback on this driver how to cope with this complexity, please feel free to contact me directly via tm-applications@rohde-schwarz.com to avoid to hijack this thread.

BR juergen

 

[Albert.Geven]

Thanks for the link to the white paper. I still don't like the express vi in the attribute approach but also I'm impressed by the broad range of spectrometers supported.

In any case it is working.

[JÞB]

---

@Albert Geven wrote:

Thanks for the link to the white paper. I still don't like the express vi in the attribute approach but also I'm impressed by the broad range of spectrometers supported.

In any case it is working.

---

My reply to R&S

---

I should have figured you were at R&S.  Yes I did in fact find the driver to have quite a bit of functionality, IMPRESSIVE amounts of functionality.  Excuse me for being blunt but I will offer my feedback on the driver since you invited it.  From a pure software engineering appraisal it falls into the the classic anti-pattern of a "God Object" http://en.wikipedia.org/wiki/God_object.  That is exactly why it "pushes the limits of the a "Configure-Action/Status-Data-Utility" structure."  The IDN referral site lists buses supported as GPIB- you way wish to contact NI to correct this oversight. 

Now to cases:

The IDN and the Driver development guidelines were created to aid the test engineers and Technicians in rapidly automating tests and taking measurements.  Not every LabVIEW user can develop a driver but they've usually seen one or two and expect the instrument driver to handle a class of instruments similarly (exposing device unique features) and the "Configure-Action/Status-Data-Utility" paradigm aids the developer in getting quickly up-to speed on a new instrument or even on a new class of instruments.  Many instrument manufacturer follow the PnP Project style driver pattern and it has proved itself to be versatile, since it is rooted on the same principles that defined SCPI protocol, it just makes intuitive sense to the users.  The users understand the driver and do not need to be directed to a new whitepapers explaining how to use a new technology style driver that is divergent from proven technologies.  While generally a well reasoned technology (except for the God Class anti-pattern) it does not offer any serious advantage over the familiar.  IN FACT I would state it detracts from it because I would need to sort through the functions available for every R&S instrument to find, place and utilize the functions needed on My_Device- Distracting and there is no good way to filter it without adding several layers of sub-palettes.

Now, there are improvements that can be made to the existing Driver development guidelines. Personally, I believe every PnP Project Driver should be required to have a Soft Front Panel, and the quality of examples should be upped for showing a "Basic" measurement to taking the time to show an "Inst-Acquire-display-analyze Loop with user events. 

I'll admit another thing to you- I've avoided R&S equipment in the past.  Not because of poor performance (I believe the specs you publish and am impressed with the performance) but because of the difficulty of integration and automation.  I was surprised to see the driver rev 1.0 originated in late 2008.  I've been a bit late picking up that any driver was available and am glad I stand corrected.  You (R&S) seem to have finally understood that the test and measurement front line workers are now using LabVIEW- and it will continue.  I applaud your commitment to improving the ease of integration for your equipment.

[djfc]

Thanks for your information.

Actually a didn't know drivers from R&S.

It can be a good starting point.

Thanks,

D.C. 

[juergenstraub]

Hi D.C.,

if you do start the development using the rsspecan LabVIEW driver, feel free to contact me in case of any questions provide me with any feedback via emial to tm-applications@rohde-schwarz.com).

BR juergen

@Jeff: To not hijack this thread again, I sent you my comments to you post via a private message. Thanks for your understanding.

[JÞB]

---

@Albert Geven wrote:

Thanks for the link to the white paper. I still don't like the express vi in the attribute approach but also I'm impressed by the broad range of spectrometers supported.

In any case it is working.

---

Seems to be contagious!
Agilent's press release form yesterday

Takes the God driver to new territory.  (Synchronization must be a challange since the Script nodes appear to be blocking )

[Albert.Geven]

Hi Jeff 

This link worked well, I like this approach from Agilent more than the express vi approach from R&S.

But only to develop and play with a driver. The real universal instrument driver will never exist!

The best idea until now is a project style driver from IDN.