IVI-C

[zeino]

I am trying to write an interchangable measurement program for Spectrum Analyzers. I have Agilent spectrums and Rhode& Schwarz spectrum so its important  to be able to switch between them in MAX. I know I should use Class drivers in my program and use logical names in th eprogram and install instrumet drivers for MAX to use,  but I don't know what to include in my header of a C++ program.  Is there any example that I can follow? The agesani also confused me . Can someone provide me with an example on how to start.

My 2nd question is how the agesani is use din an interchangable program?

I would appreciate if anyone could help me.

[juergenstraub]

dear zeino,

for further help could you please tell me which analyzers you are using. some for the r&s boxes has an compatibility mode for agilent?

i have no idea what you want to do, but this interchangeable ivi-c(om) stuff does only work good for power-supplies and things like that. for sophisticated stuff like specturm anlaysis. please be not too optimistic...

regards juergen

[NathanT]

Hello Zeino,

       Here are some resources to help you get started:

Using IVI Drivers to Build Hardware-Independent Test Systems with LabVIEW and LabWindows/CVI

Getting Started Using National Instruments IVI with LabVIEW or LabWindows/CVI

Since your end goal is interchangeability, I recommend that you only use the Extended Class capabilities that your instruments (and possible future instruments) support.  All IVI-compliant instrument drivers meet the Base Class capabilities.  For more information on the IVI specifications, please visit ivifoundation.org.

LabWindows/CVI includes some C Class Driver examples that might be worth looking at.

Cheers,

NathanT

[zeino]

Thank you Nathan and Juergenst for your reply to my Question.

I went and read the links and managed to execute the IVI commands for basic Spectrum analyzer using IVI in my Visual Studio 2008 program.. I used agesa (older version nt the ni one)  DLL for IVI-C and IVI DLL for spectrum analyzer and set the MAX to a logial name for my spectrum and all the 3 examples  worked fine on E4402B AGilent ESA.

Based on what I read before, the agesa driver should work for class complient commands on FSL-6 Spectrum and Agilent 9340 handheld that we have. Unfortunately FSL-6 comes with CVI at most not the IVI-C driver and I guesss I have to build the driver for it from the CVI driver.

I now have the following doubt on why even use IVI commands may be you can advise me on it:

Basically I don't see any generic power calculation commands in IVI manual like ACP( Adjacent channel power) or any channel power meagerments. If only basic commands is supported then most SCPI commands sent via VISA  layer would be sufficent and I would not need IVI for interchangablity. What I am doing now is to write all the device specific commands via the IVI class commands but I wounder why I should not use the SCPI equivalent commands. as far as I checked all the basic commands are similar under SCPI 1999 edition for both Agilent ESA and Rhode & Schwarz FSL-6.  I am I missing something about IVI usage and benefits for interchangability?

I know that one benefit of IVI would be that it keeps track of Spectrum state and avoid extra commands and if used with instrument driver (That I don't have for FSL) it will check range ... Is that all it can do for me. Can you advise me on this? Am I missing something?

Thanks again for your help.

[zeino]

I think I understand now. Correct me if I am wrong. SCPI is just a syntax. If the SCPI based commands are similar between my various Spectrum Analyzers its based on the concept made by IVI and the vendors. Still I can use the SCPI based commands and VISA  protocol for the IVI complient class  instead of using IVI driver and be sure that they will execute in all same class instrument (e.g. Spectrum Analyzer  ) Am I correct?  In that case I do not need the DLL's and the MAX or any driver installed? Is this correct?

[Dennis_Knutson]

I don't think you quite understand.

SCPI is just syntax and was adopted to make instrument commands more readable. For example, prior to SCPI, you might set a range for a DMM with the command 'R3' but with SCPI, you would use 'SET:RANGE 10VDC. Most instrument vendors adopted SCPI but each instrument from different vendors has different features and the syntax rules are not extremely strict, the command set for an instrument from vendor A will only be similar to a command set for an instrument from vendor B. You will often find that the command sets for different models of instrument from the same vendor will vary by quite a bit. Due in part to these differences, several instrument vendors got together and proposed IVI as a solution. A set of common features would be defined for common types of instruments (i.e. scopes, meters, power supplies, etc.). An IVI driver would have those common features as calls and internal to the driver, would use the instrument specific commands. With SCPI syntax if that is what the instrument used but SCPI is not required or necessary. For example, a PXI DMM from NI can be used with the IVI DMM class but the actual commands sent to the instrument are not SCPI. You associate an instrument specific IVI driver in MAX to an IVI class driver. To use a different instrument, you just associate a different instrument specific IVI driver. You have complete interchangeability as long as your program uses nothing but IVI class driver calls. If, in your program, you call directly into the instrument specific driver or issue a command that is unique to a particular instrument, you have now lost interchangeability and to use a different instrument, you would have to modify the program.

As you have already found, the IVI class functions do not include a lot of the more advanced measurement functions that some instruments have. Instruments and the measurements that they support change at a rapid pace. The IVI Foundation  does not and it takes years of discussions to agree on what each class should include and after the initial class is adopted, more years of discussions to agree on changes.

So, you have to decide whether your application can be performed with the somewhat generic measurement functions defined by IVI or if you want to use advanced features and a different program for each instrument.

[juergenstraub]

hi zeino,

as you see this ivi stuff is"not like in the advertisement..." (pls. get rid of this interchangeable promises- it simply doesn't work)

i personally strongly recommend you to use VXIpnp as proven technology.

pls. note following this is from R&S point of view:

simple solution: Use the RsSpecAn VXIpnp driver which supports FSL and FSH (R&S counterpart to your agilent handheld) so you have interchangeability for free! The RsSpecAn (R&S spectrum analyzer) driver supports officially FSH with next major release (Beginning of Q2/2009).

The driver covers 100% of the FSL instrument functionality (and is going to for FSH). btw. you can start development immediately using C++ and Visual Studio and the current dirver version and just upgrade the driver in Q2/2009 for official support of FSH -> no changes in source necessary at that time.

sorry, but i see no other chance to be interchangeable (without programming the same stuff for Agilent and R&S boxes.)

hope that helps.

regards juergen

[juergenstraub]

pls note the RsSpecAn driver will support only the latest FSH4/8 handheld generation. http://www2.rohde-schwarz.com/product/FSH4/8.html

regards.

[NathanT]

      There are numerous companies out there that are successfully using IVI-C for their interchangeable test applications.  In some cases a Hardware Abstraction Layer is used "above" the IVI-C Class drivers so that Instrument Specific Capabilities can be interchanged (contingent upon the actual instrument capabilities of course!).

      Will your application be a single test station that will only be used for a couple of years?  Or will it be a test system that is replicated many times and/or is planned to last longer than the lifecycle of the current instruments?  The second case is where interchangeability is a very nice feature to have and is probably worth the extra effort that would be required to have the IVI-C driver for your instrument developed or design and implement your application specific Hardware Abstraction Layer.

     Zeino, please tell us more about the needs and scale of your application. If you have any questions about developing your own IVI-C Instrument Specific Driver, please email instrument.drivers@ni.com.  

Cheers,

NathanT

[zeino]

This platform would be for testing transcievers along with their Serial controler. Currently there is one working only on GPIB and HP 85xx (8590, 8594, 8595, 8596)  E series which are not SCPI capable. Also it is HPIB and uses GPIB32 and NI-VISA 3.0  together (Odd as it seems it works fine) and uses HP E series device specific commands (ACP, ACPE, CHP, ....)  Which doesn't have equivalents in SCPI version of the Agilent 4402 (the newer series). Basicallu calls the low level VISA commands.  Basically the tests will outlive the instruments and also the bus type and I suggested the boss to use IVI along with full capability of VISA (BUS interchangability and resource detection) to achieve that. 

In order to use the interchangability concept I  am implementing the device specific commands like Adjacent channel power and all power and noise measurements  in the software at the moment. I can compensate for the errors  or do exactly what the Spectrum would do (considering Resoultion bandwidth, Video bandwidth and the span and the log averaging erros ...) . I am hoping when using the base class functions I would not need to  change the drivers in MAX and stick to the agesa driver that I have already installed as I guess (logicaly) any driver would send the same class complient SCPI to the instrument (This is what I hope for now) til I learn how to build IVI-C DLL's from CVI drivers for FSL)  . I will use the logical name approach in IVI to build a software as generic as possible and learn how to build the IVI-C driver from the given FSL drivers and switch the drivers in future. 

What my company needs is a generic software that can work with any Spectrum. They wish to be able to replace any spectrum whenever they see a good offer or whenever they need. For this purpose I don't see that I can even stick to a class of spcetrums. 

The multiple BUS  (FSL on TCP/IP and new signal generators on USB and the rest of the Spectrums on GPIB and the Device itself on ASRL) defenitely pushes me to use VISA but I feal a bit guilty pushing for IVI  for now. I am not sure anymore IVI is the solution although I like the commands that are simple and clear to use instead of multiple VISA read and writes.

Thanks for the link on Hardware abstraction layer. I will read it ASAP.