LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Compiling dyanmic VI's which call DAQ into EXE

We are seeing a wonderful but unexpected thing while compiling our application in LV 8.5.  We have a large application which we sell and among the measurement hardware we support is DAQmx.  However, we do not want users to have to install DAQmx if they are not using NI Hardware which is usually the case (As it would add hundreds of megabytes to the installer).  To deal with this, we dynamically load and call VI's which in turn call DAQmx vi' only if the user is using DAQ hardware (therefore there will not be a dependency on DAQmx if the user is not using DAQ hardware)
 
In the latest release of our software, we are moving away from a source code distribution to a single large executable distribution.  We now are putting all dynamically called VI's onto a single block diagram "All Program VI's", and including that VI in the build under the "Always Included" VI's.  The exception was the VI's which utilize DAQmx.  Testing seemed to indicate that including them caused the executable not to load if DAQmx was not installed (complaining about missing DLL's).  I could have sworn that I saw this a month ago.  However, yesterday, I added them back to the "All Program VI's" as a test (I wanted to see how many dll's it complained about needing and maybe just rip a subset of DAQmx dll's).  I compiled the EXE, installed it on a blank WinXP machine with LabVIEW runtime 8.5.1, and it loads and runs without problems (though the DAQmx using vi's are built into the executable, they are not
 
The only thing I can think of is perhaps last month I was trying to load "All Program VI's" dynamically at startup (I remember playing with that idea) which was causing dialog boxes asking for DAQmx DLL's to pop up.  Or that the runtime engine 8.5.1, acts slightly different than runtime 8.5.
 
Based on what we are seeing, we are considering shipping our application (which has a user base of over 1000) with the DAQ-using-VI's built directly into it.   Can someone at NI confirm that I'm not crazy and that this really does work?  The risk is that I'm overlooking something and we wind up shipping a product which has an unexpected DAQmx dependency to a thousand customers.
0 Kudos
Message 1 of 4
(2,913 Views)

typo (I had to cut and paste several times due to an odd bug in the NI forums)

"I compiled the EXE, installed it on a blank WinXP machine with LabVIEW runtime 8.5.1, and it loads and runs without problems (though the DAQmx using vi's are built into the executable, they are not  loaded with VI server if the user is not using DAQ hardware and apparently, becuase of this there is no dependency on DAQmx being installed)

0 Kudos
Message 2 of 4
(2,912 Views)
*bump*  anyone?
0 Kudos
Message 3 of 4
(2,880 Views)

Hi Thomas,

 

Your method should work.  As long as the DAQmx VIs are never loaded into memory, they will never ask for the DLL.  You can also include all of the VIs individually instead of including them in a catchall VI (if you load that VI, you will load every sub VI into memory).  

 

Ultimately, you need to make sure you thoroughly test your installation and your main application to ensure that it never loads a VI with a dependency on DAQmx in the cases where DAQmx is not installed.  As long as you are certain of this, you should be fine. 

Regards,

Jeremy_B

Applications Engineer
National Instruments
0 Kudos
Message 4 of 4
(2,875 Views)