Creating an "IVI session" using COM

[f28]

I am trying to program NI's RFSG from a COM client with LabVIEW acting as the COM server.

An niRFSG initialization vi requires as one of its inputs a wire of type "resource name (IVI session of class niRFSG)". Passing the resource name as a string (e.g. "pxi1slot2") doesn't work because of type mismatch. Which COM component can I use in my client to create an object of type "resource name" from its human-readable name?

Where is information like this documented?

Thanks!

[Paul_C.]

Hello f28,

Generally speaking, our RFSG requires that you pass the resource name that is aliased in Measurement and Automation Explorer (MAX).  In LabVIEW, you should have no problems wiring a string into the initialization with the device alias ("pxi1slot2").  Theres quite a bit of information that can be found in the NI RF Signal Generators Help file.  This can be found by going to Start » Programs » National Instruments » NI-RFSG » Documentation.  Once in the help file you can navigate to Programming » NI-RFSG C Function Reference » niRFSG_ini.  This has some more detailed information on the resourceName.

I'm also a bit confused on what you mean by using a COM client with LabVIEW. Could you provide more details?

In addition, which device are you using?  Version of LabVIEW? 

Regards,

Paul C.

[f28]

I am using a PXIe-5673 vector signal generator with Labview 8.6.1 and NI-RFSG 1.4. I cannot use the instrument driver's C interface directly because I am writing a 64-bit application and the driver is 32-bit.

My appilication (currently being prototyped in python) calls labview via COM when it needs to access the RFSG or other NI hardware or use the functionality provided by some labview toolkits. That is, my application is a COM client that interfaces with labview COM/ActiveX server via labview's LabVIEW.Application dispatch.

I am running into problems when I call, for example, "..\instr.lib\niRFSG\niRFSG.llb\niRFSG Initialize.vi". According to context help, that vi defines the "resource name" control as being of type "resource name (IVI session of class niRFSG)". It is my understanding that labview internally cast the value of that control to string before passing it to the driver.

Even though NI's device drivers only require string logical names to get hardware handles, using controls of type "resource name (IVI session of class niRFSG)" in place of strings to identify instruments is standard practice in labview. It makes sense because (I think) that type's front panel control allows using a drop-down menu for device selection. However, this complicates calling vis externally via COM. It is my understanding that the vi exposes the parameter "resource name" to COM as type "resource name (IVI session of class niRFSG)" and if a COM client provides a string instead the COM glue has no way of knowing how to convert it to the appropriate type, resulting in a type error.

One way to solve this problem is to create an indicator of the appropriate type, get its value from a COM client, try to guess its structure and create native objects compatible with the labview data type in question. For example, after some experimentation and picking through vis my best guess is that type "resource name (IVI session of class niRFSG)" is a structure consisting of a string, which is the logical name, and an integer, which is the driver's resource handle. The problem is that getting such information is a bit of a pain and I still have no idea what is the proper way to use such structures. For example, specifying an arbitraryhandle when opening a device seems to work fine so far, but I don't know if it will cause problems later on.

My questions are the following. Where can I find documentation on the structure of higher-level datatypes in terms of basic datatypes. Where can I find documentation on how to use such higher-level datatypes properly (e.g. concerning the handle values I mentioned). Whether Labview has some generic facilities that allow construction of higher-level data types from low-level components (generic in the sense not requiring creation of a new vi for every required type conversion and preferrably available in labview's COM interface rather than a vi). Lastly, what documentation should I have read to know where to look for answers to the above questions.

Incidentally, I have a question about datatype nomenclature in labview. For example, the type "resource name (IVI session of class niRFSG)" is displayed in context help with the parenthesised part in grey, so there are two parts to this type. What do you call "resource name" and "IVI session of class niRFSG"? Is the former the instance and the latter the type, or something like this?

Thanks!

[Chris_G. · Accepted solution]

Hello f28,

Your assertion that LabVIEW automatically casts the strings passed into the resource input of VIs which use a device’s resource name is correct, and can be noticed by the little red “coercion” dot which appears at that VI’s resource name input terminal. 

So, we must find a way for you to take strings from Python and make them “IVI session of class niRFSG” data type.  I believe that [Class Prefix]_InitWithOptions from the IVI Function Tree would get you the correct data type, but I am not completely sure (possibly something for you to try out).  Unfortunately the C API and LabVIEW API are the only ones that are documented for IVI (unless you also have Measurement Studio for .NET installed).  So, I think that the easiest (and less research-intensive) way of going about this would be to just create other VIs which will convert strings to the appropriate IVI class for you.  Attached is one such VI, which is just composed of a String Control and an IVI Class Session Indicator.  The indicator’s class was selected by right-clicking on in, and selecting Select IVI Class » IviRFSigGen » niRFSG.You could possibly use this VI (and other VIs for other IVI-specific classes) instead of calling directly into the COM component.  It may be a little easier since it looks like you are already calling into VIs in order to use the RFSG driver.  Would this meet the requirements of what you are trying to accomplish?The guide to the IVI documentation should be installed on your machine under Start » Programs » National Instruments » IVI » IVI Driver Help.  Like I mentioned though, nothing about COM in here, but LabVIEW and C instead.

Also, you should beware that calling into the RFSG library from LabVIEW will not circumvent the fact that the driver is a 32 bit DLL at its core… In other words, calling it from LabVIEW will not make it a 64 bit application any more than calling the C API… unless I am missing something here…

[f28]

Thanks for clarifying the documentation issue.