IVI - Programmatic Developer Interface (API) - Need clarification

[rdog]

Just getting into IVI for an old test app we have...

Can anyone give me a quick run down on the "Programmtic Developer Interface (API)" or PDI as I will call it, referenced in Figure 1-1 of the LW/CVI Instrument Driver Guide? Here is what I'm getting at:

- An Instrument Driver PDI is hardware independent right? The functions of the PDI don't have the hardware prefix (like, FL45_Init)...instead it is generic (like DMM_Init). Even if I'm using IVI, I don't need to refer to this either...(for example IviDMM_Init)...right?
- Obviously the whole intent is to avoid relinking when I change hardware correct?
- In order for the above statements to be true, does my instrument have to have an IVI class? If I have some proprietary hardware that I will change out over the years, I should be able to create a PDI just like my DMM that will allow me to change that out too? Or should I create my own custom class?

It doesn't seem like the Instrument Driver Guide gives me a clean image of what my application developers will be looking at once I create the driver. I understand there will be a function panel...but what the guide is suggesting is way more detail than I want them to have. I want to restrict their awareness to the PDI - high-level APIs like DMM_MeasureVDC, DMM_Measure???, etc.

[JLS]

Hello,

The API you are referring to refers to the set of functions you expose to define your instrument driver, for use by application developers, for example, functions such as Initialize with Options, Configure Measurement, Read, Close. If you prefer to have a higher level of abstraction, you can certainly wrap the IVI driver you write with higher level operations (underneath would be mutilple driver calls presumably. Perhaps the best way to see this is to download a standard driver; you seem to be interested in DMM's so I would recommend downloading the IVI driver for the hp34401a (you can do so from http://www.ni.com\idnet); if you get the CVI version you'll be able to see the structure of the function tree as well as the source code. After downloading the driver you should find all the source files as well as an example in your C:\Program Files\IVI\Drivers\hp34401a folder. If you are developing a DMM, then to make it IVI compliant you won't want to define your own DMM class, since you won't be able to use the DMM class driver which is defined for functionality with DMM instruments with IVI specific drivers; the class driver of course is what gives you interchangeability among instruments in the same class. If your custom hardware truly does not belong in a predefined class, it is possible to develop your own custom class driver which could then theoretically address the needs of the different versions of the custom hardware you mentioned developing; if you decide to go this route you should email instrument.drivers@ni.com and request some code snipets. If you strongly feel that a class of instruments for your customer hardware should exist as an IVI defined class, you should be in touch with the IVI foundation; a good place to start is http://www.ivifoundation.org/. In any event, if you are not working with an instrument in a defined class, you may consider developing a more simple driver. If you are going specifically for interchangeability, state caching, or simulation, then you have sufficient incentive for developing an IVI driver.

Repost if you have further questions; hopefully you have a better idea of how to proceed to get familiar and started.

Thank you,

Best Regards,

JLS

[rdog]

JLS, Thanks,

I understand the API from the perspective of the driver (like you said...config, initialize, etc.). I guess I'm not understanding why there is NOT a higher level of abstraction. Why would I want to use the instrument driver interface directly; if I change out my DMM or Fgen a year from now then I would have to alter my application code...simply because my function names will change from "hp34401a_" to a "ag3458A_"? Why does all the documentation (NI, and IVI.org) direct us to couple the device name to our API (i.e. Prefix_)? Doesn't this defeat the purpose of the driver.

With regards to custom equipment, I don't think I would need to formally define a new class with IVI. The equipment is basically an I/O hub to test a device under evaluation. But it would be nice to define the basic device driver needs with a known standard...so I was researching IVI.

Third and final...I was kind of exploring the capability of IVI to control other IVI drivers. The documentation seems to tout this as a "limitless" capability of IVI. What I'm getting at is I have a rack of test equipment controled by a LabWindows/CVI application. Some test equipment is connected to the PC via GPIB and other equipment is straight DAQ. Would it make sense to define an IVI driver for my rack that controls and interacts with all subsystems? I'm thinking this approach would optimize my compartmentalizing and info-hiding of all the instrument and custom equipment details. That way...when I change out a DMM my rack driver doesn't care...it just cares that instrument has the same functionality as the last one.

[JLS]

Hello again,

The interchangeability across hardware in a given class is done through the class driver. The idea is that you configure an IVI logical name in measurement and automation explorer for example, and then associate a specific driver session with that name (such as an hp34401a or

[JLS]

Hello,

The last message was cut off... here's the whole thing:

"Hello again,

The interchangeability across hardware in a given class is done through the class driver. The idea is that you configure an IVI logical name (such as MyDMM) in Measurement and Automation Explorer (MAX) for example, and then associate a specific driver session with that name (such as an hp34401a or ag3458A), in addition to indicating the specific hardware resource name (such as GPIB0::5::INSTR). You can then use this logical name as a specifier for class driver VIs, and your program will communicate with your instrument through the class driver, which of course uses the specific driver underneath. When you switch hardware, you can literally use the same program, and all you have to do is change the logical name (which presumably you have quickly configured for the new hardware) or modify the driver session in MAX used by the current logical name to reflect the specific driver and resource name for the new instrument. Recall that a class driver for an IVI defined class of instruments exposes functionality which, as defined by IVI, all instruments in that class should provide. So, this is the level of abstraction provided by IVI, and you are of course able to use IVI drivers, wrap them if you will, in order to achieve higher levels of abstraction so that the conventional driver functions are note exposed, and your preferred single-VI style API can be used by application developers.

If you didn't have a chance, the links in the previous post are helpful in describing some of this as well, and the email address noted for development help (especially class driver development) should be helpful as well!

Thank you, and repost with any other questions!

Best Regards,

JLS

[rdog]

JLS...OK...That was the missing piece I needed. I've been wading through the documentation and hadn't seen the MAX connection. So I can preface the APIs however I want...if I set the logical name accordingly. I use the class driver for the interchangeability and if I have a custom piece of hardware, I'll need to create my own custom class AND specific driver. Thanks for the help.

rdog

[JLS]

Hello,

Yes, no problem, and we're on the same page 🙂 And if your custom hardware supports the operations already defined in a given IVI class, you could theoretically just write a specific driver which implements those operations on your custom hardware, and use that already defined/written class driver with your specific driver.

Best of luck and repost if you have any other questions!

JLS