Writing LabVIEW wrapper for IVI-COM driver

[Makoto]

Hi there,

I am writing a LabVIEW wrapper for an IVI-COM instrument driver. The IVI-COM driver does not have IVI-C interface. COM operations go well from wthin LabVIEW 6.0 but, I can't see how to typecast between Automation RefNum and VISA or IVI Session (Instrument Handle). Also I can't see how to keep reference count of object instances between multiple VIs.

For instance, my Initialize.vi creates a COM object instance and acquires COM interface on it. Then it also has to return the pseudo handle from the Instrument Handle output connector for subsequent VIs. Also other VIs have to take Instrument Handle input, typecasts it to COM interface, then access the same object instance.

My questions are:
1) How I should ty
pecast between COM interface and Instrument Handle. I tried Variant-Data conversion, Typecast, and Automation Refnum, but they did not go well.

(2) How I should keep the reference count of the COM object between VIs. Once an object has been instanciated in Initialize.VI, its life has to be kept untile the application invokes Close.VI. And the COM interface pointer (Automation Refnum) has to be able to passed between VI's Handle IN/Out bridges. As I debug my COM object in Visual C++, the object is created when Initialize.VI creates the object. But the object is soon destroyed when the operation of Initialize.VI finishes.

Is there any good solution? Otherwise, is it easier to write an IVI-C wrapper, then ask LabVIEW to machine-generate the LabVIEW driver conversion? Or, do you have a plan for the future LabVIEW release that will have the capability to convert IVI-COM drivers to LabVIEW wrappers?

Thanks
Makoto

[Dan_Mondrik]

Makoto:

I do not know the answer for what you should do here. I do know, however, that you should *not* cast the COM interface handle to a VISA or IVI instrument handle in LabVIEW. The reason is that the IVI handle is really a VISA handle, so LabVIEW knows something special about how to treat them. A COM interface handle is not the same thing and this could cause LabVIEW to get confused and possibly crash.

Hope this helps,
Dan Mondrik
Senior Software Engineer, NI-VISA
National Instruments

[gagi1]

Hello Makoto,

I am glad to hear that you are developing LabVIEW wrappers for the IVI-COM instrument driver. I would like to point out that in any development environment, it is easiest to use an interface that is native to that environment. While a C interface and a COM interface are best in C and Visual Basic respectively, a native LabVIEW interface is best in LabVIEW. LabVIEW users expect a higher-level abstraction that lets them focus on their measurements, and insulates them from the details of a COM interface. The VI wrappers should serve this purpose by hiding the COM details from users as much as possible.

Let me now try to answer your questions:

Question #1: How should I typecast between COM interface and Instrument Handle?

Why would you like to switch from the ActiveX refnums at all? Do you see an end-user benefit?

In the current version of LV, you cannot completely hide the fact that you are using COM. In particular, users will need to see the ActiveX refnums. You cannot cast ActiveX refnums to or from IVI refnums. If your end user is interested in having a high-quality, standards-conforming IVI instrument driver that works well in LabVIEW, I would suggest you to first create the IVI-C wrapper and then create a LabVIEW wrapper on top of the IVI-C wrapper. However, if you don't mind exposing COM to your end users, you can replace all IVI refnums with ActiveX controls (wires just change to green) and be up and running fairly quickly.

Question #2: How to keep a COM object instantiated between VIs?

I'm not sure what causes your object to be destroyed, but I am assuming that you probably want to interactively run the "Initialize" VI, then interactively run a VI to take a measurement. IVI and VISA leave their sessions open when the VIs go idle. ActiveX doesn't. Basically, in normal programmatic usage, there shouldn't be a problem, but the problems occur in the interactive usage. If you want an interactive solution, this is yet another reason to create IVI-C wrappers.

Question #3: Is it better to first create an IVI-C wrapper before creating a LabVIEW wrapper?

There are many advantages to first creating an IVI-C wrapper then creating an LabVIEW wrapper. Besides the above-mentioned interactive support, an IVI-C wrapper provides features such as the IVI Logical Name control in LabVIEW with its drop-down selection. While IVI-COM and IVI-C both allow programmatic control over your instrument, they do it in different ways. A COM-based approach typically introduces a hierarchy of programming objects with attributes, methods and sub-objects. COM programming requires understanding and navigating through the instrument's object hierarchy. LabVIEW, on the other hand, was designed to make it easy for non-programmers to control their instruments without needing to understand complex object-oriented structures. A good LabVIEW instrument driver focuses on the end user's measurement domain, not on the details of how the instrument is programmed.
You can use existing automatic conversion tools such as the CVI Function Panel Converter built into LabVIEW to produce a well-structured driver.. NI has tools to update LabVIEW help from C help and clean up your LabVIEW code. Another advantage is integration with other NI products such as class drivers etc. Finally, you would provide C support to users whom C interface is more native to his/her environment.

To correctly create an IVI-C wrapper does require some work. You'll need to handle some issues, such as data type conversion (BSTRS to C String, etc.) , and resource management issues relating to handing COM library and COM interfaces from multiple threads.

I hope this helps!

Regards,

Vesna Jadric
Instrument Drivers/IVI
National Instruments