LabVIEW Driver Import Wizard does not recognize IVI class

[Makoto]

This is a related post to thread

http://forums.ni.com/t5/LabVIEW/LV-Driver-Import-Wizard-generates-wrong-64bit-call/td-p/2000437

I noticed that most of IVI-C drivers, which is created with Pacific Mindworks Nimbus can not be detected for its IVI class, when converting the IVI-C driver .fp file with LabVIEW Instrument Driver Import Wizard 2.0 (use with LabVIEW 2011).

For example, if converting AgN57xx IVI driver (Agilent N5700/8700 series DC Power Supply) with the Wizard in Advanced Mode, the 4th page of the Wizard says the driver to be imported looks like VXIpnp driver ! But the driver is in fact an IviDcPwr class.

I tried to reverse-engineer about how the Wizard detects the driver's IVI class. So I noticed that the Wizard is checking if the <prefix>.h contains the following #include lines.

#include <ivi.h>

#include <ividcpwr.h> // or can be any other class header file

However, for most Nimbus-generated drivers, the .h file does not contain such lines, but simply has the line:

#include <IviVisaType.h>

The Wizard simply sees <ivi.h> line to recognize the driver is IVI rather than Plug&Play.

The Wizard simply sees <ividcpwr.h> line to recognize the driver is IviDcPwr class rather than custom.

(similar for other classes too)

In fact, by customizing the .h file to have these 2 lines, the Wizard has detected that the driver is IVI and of an appropriate class as default.

Is it LabVIEW's spec?

I wonder if why the LabVIEW Instrument Driver Import wizard sees that lines rather than checking the IviConfigurationStore.xml content, where the driver detail is described.

Makoto

[Charles.Tac]

Hi Makoto,

I believe the behavior of LabVIEW Driver Import Wizard is exactly what you mentioned above. Maybe it looks a little bit inflexible to you. But considering that the only feature of this tool is focused on converting a C driver to LabVIEW driver, and it should be able to run on any enviroment without any depencency limitation (e.g. install IVI Shared Components or ICP before using this tool...).  So some user may run it on a machine even without IVI ( no IviConfigurationStore.xml either). That may be the resason it just parse the C driver in text to determin the driver type and IVI classes.

Actually, the problem you wondering is a compatibility issue between Nimbus and Driver Import Wizard. I am also hoping it would be fixed in the next version of LDIW.

Thanks,

Charles

[aTammy]

Hi All,

I just find the C-Driver generated by NimBus do not have class driver information in .c, .h, fp and sub files.

Maybe we could parse configStore.xml to get the driver class, but not all the drivers would provide the related info in this xml(Normally the xml file is updated in installation phase).

As we already provide a workaround for such drivers(By selecting driver class manually), I think it's better to keep it as it was.

[Makoto]

Thanks for the reply.

I know that I can explicitly select a specific IVI class rather than leaving VXIpnp when importing an Nimbus IVI-C driver, and off course I know the Import Wizard is covering not only IVI-C but legacy VXIpnp and other CVI instrument drivers.

And as for me, this "manual select" work-around is accepted. But as a instrument manufacturer that provides IVI drivers, I think many driver user will operate the Import Wizard in Basic Mode, which will leave the detected driver type as is. The resuled driver is still accepted because the LV wrapper operates normally, but in this case, many of IVI-defined and IVI-class-defined VIs will have default icon, making the user get confused.

I think I can't decide which tools (Import Wizard or Nimbus) is the true cause for this issue. It might be Import Wizard issue that only checks <prefix>.h without seeing ConfigStore.xml. And it might be Nimbus issue that never embeds #include <ivi.h> and <other ivi class .h> lines in <prefix>.h when machine-generate.  (At least Nimbus 2.x does not embed these #include lines, and insertion by hands will be prevented by Nimbus when rebuild. I dont know Nimbus 3.x fixes this because I dont have it yet.)

Anyway it may be better that step-by-step instruction for the Import Wizard describes this pit-fall.

Makoto

[aTammy]

Dear Makoto,

Your consideration makes sense.

How about this:

a) We provider a step to parse the configstore.xml if failed with include parsing, but users may be required to enter the driver session name.

b) We add some notes in fp converter to notify user about changing the driver class manually and get the driver class info from driver provider.

Which one do you think is better?

[Makoto]

aTammy-san,

Thanks for the reply. I think the solution [a] is better but I have one issue on this.

>>but users may be required to enter the driver session name

I think it is bit strange query for the user. As for Session Name, it only exists after the user has created a virtual instrument entry (Logical Name) in NI-MAX, so it is probably absent when importing. If you are talking about Software Module instead, you can assume that it surely exists and the name is same as <prefix>. So the user does not have to explicitly specify the Software Module name because the Import Wizard already knows the name once after the user selected an .fp file.

The IVI-3.17 Installation Requirement Specification - section 5.1.4 requires that an "IVI-COM driver packaged with IVI-C wrapper" shall create a Software Module entry with IVI-C's <prefix> name.  Nimbus-based IVI-COM/IVI-C hybrid drivers are this type.

So finally, I think the following approach is appropriate.

After the user selected a <prefix>.fp file (and then Import Wizard estimates .h, .sub, and .dll),

(1)1st Try:

Parse <prefix>.h for if #include <ivi.h> and other class .h lines are included.

If any included, decide the driver is IVI, decide appropriate class if any class .h was included.

If not, go to 2nd Try.

(2)2nd Try:

Look for the Software Module entry named <prefix> in the Configuration Store XML.

If any found, deeply parse about what Published API for IviDriver IVI-C, IviDCPwr IVI-C, etc... are supported.

If Software Module was not found, leave the driver type VXIpnp.

In any cases, the manual select for driver type should be available for the case that the Import Wizard could not detect correct type.

Regards,

Makoto

[aTammy]

Hi Dear Makoto,

Thanks for your kindly feedback!

Only two things:

1. As the software module name could be different with the prefix(That's why we have a prefix field in softwaremodule), and we could be lack of configStore settings, such solution could only cover part of the senarios.

2. Parsing xml would lower the effciency, bring in extra effort and might break our original design.

We will try to contact Pacific Mindworks to find a balanced solution.

Your suggestion will definitely be under consideration.

Thank you again for all your comments!

[Makoto]

aTammy-san,

>>

Only two things:

1. As the software module name could be different with the prefix(That's why we have a prefix field in softwaremodule), and we could be lack of configStore settings, such solution could only cover part of the senarios.

<<

Yes I know there is Prefix property under Software Module, and they could be different. So general approcah might be better to iterate Software Modules collection and check each one and its Prefix name to see if it matches with the desired <prefix> name. As for Nimbus drivers as I have seen, the SoftwareModule name of all drivers does match with Prefix. Plus NI-made IVI-C drivers (created with CVI) and our (Kikusui) hand-made IVI-COMs with C wrapper (created with VC++/ATL) will not step on the 2nd try because they all have #include <ivi.h> lines. But as for legacy Pnp and CVI drivers that do not have <ivi.h> lines, it will step on the 2nd try with no success, so better to consider for that case...

>>

2. Parsing xml would lower the effciency, bring in extra effort and might break our original design.

 <<

Yes it will take more time by scanning the XML through the Ivi Configuration Server engine. But the FP-to-VI import work is only one-time for the user, so I think it will be accepted if taking a couple of seconds more.

Makoto

[Makoto]

Hello,

I have another issue on Import Wizard 2.0 when importing a Nimbus-based IVI-C wrapper.

-- Condition is LabVIEW 2011 32bit, using 32bit IVI driver

At the Import Wizard (Advanced Mode) 4th page, we can see the "Shared Library or DLL" shows <prefix>_32.* as default. This is fine when importing a VXIpnp and IVI-C drivers that have DLL file name with _32 suffix. But all 32bit drivers created with Nimbus do not have the bitness suffix (such as <prefix>.dll). This means that the Import Wizard will only search the DLL with the <prefix>_32.*  wild card match.

(IVI 3.1 spec says 32bit IVI-C drivers can be either <prefix>.dll or <prefix>_32.dll, where as 64bit DLL shall only be <prefix>_64.dll.)

The default _32.* DLL wild card does not work for finding the Nimbus IVI-C DLL, so the user has to specify the exact DLL file name by clicking BROWSE button. (Bad points are the file open dialog by BROWSE often can't finish selecting the correct DLL with OK button, and specifying more generic <prefix>*.* wild cards directly on Shared Library or DLL textbox will not work.  No way other than manually ***TYPING*** the exact DLL name.)

When the next update, is it possible to fix this part so that both with & without _32 DLL names can be searched without problem?

Thanks

[Charles.Tac]

Hello Makoto,

I used to think Import Wizard 2.0 cannot manipulate the <prefix>.dll file as "Shared Library or DLL". But I finally figured out how to indicate the <prefix>.dll format file in the prompted file selecting dialog. I admit the behavior of the dialog is a little bit weird and confusing.

1. When you select the <prefix>.dll file first time in the dialog (e.g. hp34401a.dll). The dialog will display "*.dll" in file name and OK is not function.

2. But if you try to click another files and then click the hp34401a.dll again. Both the file name display and OK button are correct in function.

3. The wizard "Shared Library or DLL" editor also has a correct file name after that.

It will be great if these tips would be helpful and looking forward to know if you have any issue when trying them.

Thanks,

- Chenchen