NIDAQ

[wa5ycg]

I have a large LabVIEW 7 application that was designed to run on several different hardware data acquisition platforms.  I recently added a set of NI boards as one of the choices to run the application on.  I added traditional NIDAQ to the new project and eveything worked great.

During an upgrade of the application (EXE only) of a previous customer, who is using a non-NI hardware platform, the application starts giving errors because there are a host of nidaq libraries that the new EXE cannot find.

QUESTION:  Does this mean that I have to load NIDAQ on all of the other installations (that don't use the NI boards) in order to get the software to work?  Is there some LLB or DLL that I can link that will resolve the unresolved references so that the old customers can run the new software (even though they do not have the NI hardware)?

Steve Hope

[Dennis_Knutson]

I imagine you would have the same problem if you had a customer with only NI boards and didn't have the drivers from the other vendors installed. The daq functions for the other boards also probably have a Call Library Function Node in them and if the dll is missing, those VIs would start giving errors. What you should do is call the daq functions dynamically. If every daq function was in an external llb or folder instead of statically linked in your main exe, then you would only open the functions needed based on some setting (i.e. an ini file for example).

[wa5ycg]

Dennis:

I think that I understand, but no, the other platforms do not require any dlls to be included in the Ap Builder and in the install.  If the functions are called, they execute.  If they are not called, they don't crash!!!  I presume that this means that their internal VI's are compiled and in the application (their I/O VIs) not linked to some external library that must be loaded.  The Ap Builder does include LVANLYS.DLL, but I think that this is an NI library for something other than I/O.

So, is there a way to get the NI I/O functions included at compile time to not require these (30 or so) DLLs or is there some easy way to convence the Ap Builder to include the right DLL's in the build?  Or do I need to install NIDAQ on all the other systems?

Steve

[Dennis_Knutson]

You don't mention what the other platforms are but I assumed that they were some other type of daq board that used a dll. If they don't call a dll, then I suppose they might be using a CIN and a CIN is a bit different. Aside from doing what I recomended and calling the DAQmx or traditional DAQ functions dynamically, you don't have many other options with 7.0 aside from installing the NI driver. I've never tried it but I suppose another option would be to write a CIN that in turn calls the NI dll. Since you can include the CIN's lsb with a VI, this might work.

[wa5ycg]

The most important of the other vendors is Measurement Computing.  We use their Universal Library for LV.

Why aren't the NI VI's for these functions included in LabVIEW when I compile using the Ap Builder?  If I understand correctly, the only options are 1) Load NIDAQ on all the machines, or 2) Dynamically call these libraries.  How do I do that?  Can you send me an example?

Steve

[Dennis_Knutson]

I can't look at the Measurement Computing library as they make you pay for it so I'm not sure how they are calling the functions in their library. You should be able to look inside them to see what they are doing. My guess is that they've written a CIN to interface to their DLL instead of using the Call Library Function Node to directly interface to it.

The VIs for data acquisition are included when you do a build but every one has a call library function node and if the dll is missing, the VIs are broken. Here's a simple example of calling a VI dynamically. There are other shipping examples.