NI-DAQmx Run-time Engine

[Mihill]

Is a run-time version of the NI-DAQmx v8.6 driver available yet? I'm distributing an application from LV 7.1 that requires DAQmx and want to include this as part of the installation. I found run-time packages for v8.3 but I'm using v8.6 in my development work so hate to switch to an older version. Are there any compatibility issues in using v8.3? Thanks.

Art

[Mihill]

Just found some information here http://zone.ni.com/devzone/cda/tut/p/id/5606#toc7 about this issue. Says that 5 different versions of the run-time can be downloaded, but no link is given. Directions are also given for customizing the run-time deployment from within LV 8. Anyone know where these 5 versions are located for download and are they compatible with LV 7.1?

I could build an installer in LV 8 just for the NI-DAQmx driver. Would this add a lot of un-needed "stuff" to my install? I've created test installers from LV 7 that install only a batch file for testing and they are 32MB! The way each new release tends to grow, I guess this could be >100MB from LV 8? Any thoughts are appreciated. Thanks.

Art

[Paul_C.]

Hi Art,

I would recommend just building an installer that includes the NI-DAQmx runtime of your choice.  You could even make your own DAQmx runtime installer application by including only including the DAQmx runtime in the additional installer list.  I'm afraid we don't currently have the DAQmx 8.6 Runtime engine installers available on our website.  In regards to the size of the application, this all depends on the size of the application and what things you include.  The DAQmx runtime engines are much smaller than the full install, but still require a decent amount of space.  If I remember correctly, even the smaller runtime engine is over 150MB.  Please let me know if you have any additional questions or difficulties building the installer.

I hope this helps,
Paul C.

[Mihill]

HI Paul,

Thanks for your suggestions. Just prior to receiving your response, I had in fact tried to build just an installer for the daq driver from LV 8.5. The problem is that it forces the project to be saved before it will create and installer and then proceeds to include the empty project and the LV runtime engine. In my case, I named the project test and the installer created c:\test on the target and installed the LV runtime as well as the daq driver. I also ended up with a regiestered application - test. Once I manually uninstalled test, I had the result I wanted, but too long a path to get there.

I bit the bullet and migrated the code from LV 7.1 to LV 8.5 so that I could build a comprehensive installer. Generally, things turned out well. My biggest question is why the application builder / installer insists on putting both LV 8.2 and 8.5 RTE on the target. I want, and expect, only LV 8.5 RTE. I'm have installed and am running off of the 3rd Q release for the NI developer suite. Why is 8.2 RTE loading and how do I correct this?

Another strange result is that my daq device and channels do not show up in MAX. I included the level 5 daq driver and MAX in my installer as well as the hardware configuration. The application works ok, and if I manully import from my *.nce file then I get a warning that my device will be replaced. Is this normal? The GPIB controller shows up as normal. The only thing that seemed odd during installation was that the daq driver didn't complete installation after restart because I forgot to plug in the daq device cable. Afterward it seemed ok.

I also have a couple of bugs with the application builder / installer. I converted my LV 7.1 build script and made needed changes. I see the following behaviors.

1) I have setup a file to install into a subdirectory. Every thing works ok except when I subsequently go back into the Installer Properties window and go to the Source Files. I see two problems. First, in the Project View my files are in the correct locations, but the icon for the one in the sub-directory is switched with the very last one in the list. Second, in the Destination View the next-to-the-last file from the Project View is the one shown in the sub-directory while the file that should be in there is listed directed below it in the list (but not in the sub-directory). Everything installs to the correct location, but this maked it very confusing to edit the installer.

2) Whenever I use the Build All command, the application builder fails with the following error. If I start the build individually from the Properties window, then the build completes successfully.

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 1 occurred at Copy in AB_Engine_Copy_Error_Files.vi->AB_Application.lvclass:Copy_Error_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488:  Command requires GPIB Controller to be Controller-In-Charge.

C:\Program Files\National Instruments\LabVIEW 8.5\user.lib\errors\McPherson-errors.txt

Thanks again for help.

Art

[Paul_C.]

Hi Art,

I don't believe there is anyway to avoid the installation of the "test" folder.  You don't have to include the LV runtime engine however or a vi.  You can have a empty project with just the DAQmx runtime additional installer.

In addition, the LV 8.5 should be the only runtime that gets installed if that is all you have selected in the additional installers tab.  Are you sure that this was the only thing selected and that the LV 8.0 Runtime wasn't already installed on the target machine?

I'm a little confused about your statement about your devices not showing up in MAX.  You state at the end that after you plug in the daq device cable that it seemed ok.  Does that mean that you're now able to see the device in MAX?  If not are the devices showing up under device manager?  If you are able to see the device in device manager but not in MAX, I would recommend taking at the document found here.  Play close attention to step number 2. 

Questions / Concerns with the Application Builder / installer
1)  I would recommend making a product suggestion about this and submitting it.  Our R&D team takes these product suggestions very seriously and they might have overlooked this part.  In the bottom left corner of the page found here, you can click the feedback link to submit feedback on our products.


2) Do you have multiple installer's set to be built under the build specifications in the project window?  It looks like the error has something to do with the path: C:\Program Files\National Instruments\LabVIEW 8.5\user.lib\errors\McPherson-errors.txt.  Is it possible that you other another installer build that is causing the problem?  I have tried the build all button on my project with just one installer and everything went smoothly with no errors.

I hope this helps,
Paul C.


Message Edited by Paul C. on 12-13-2007 01:38 PM

[Mihill]

Hi Paul,

Thanks for your suggestions. I submitted a product request for the Builder/Installer problem as you recommended. We are also in agreement about the result of creating just and installer for the daq engine and since I converted to LV8, this isn't an issue for me any longer. So let's cross these off the list.

As far as the LV 8.2 engine not being on the target, I can assure you with 100% confidence that it was not there. I have never used 8.2. I launched it after installation to make sure it would run and did not get back to version 8 until 8.5 had already been released. I decided to make the jump all the way to 8.5 and that's where I have been for about 10 days now. The LV 8.2 run-time engine is not checked in the Installer. Is it possible that some reference to LV 8.2 remains after installing the Q3 LV8.5 update?

Now to the daq; when I said it works ok, I simply meant that the application runs as it should. Which means I didn't haven't an arguement for tracking this down rather than shipping the system - which is what happened. We're on to the next one and I will have to try things on a nearly identical system. The daq device never showed up in MAX. I didn't think to check in Device Manager and now the system is gone . . . I'll be sure to check if this behavior repeats on the next system.

Finally the Build All error; at the time I only had one Installer setup. It includes all the needed drivers. I have since created a second Installer just for the Application. The full installation is just too big and slow to work with for last minute changes and debugging. After installing LV8.5, I simply copied our custom errors file from LV 7.1 to LV 8.5. I think this should work ok, and I would expect something other than a path error if there was a problem with this file. Maybe something is strange from the LV7.1 build script conversion and I should assemble a new project. I've had this issue from the beginning and I also found that the panel of a sub-vi was not loaded and had to move all of my sub-vis from Dependencies into virtual folders to solve the problem. Perhaps other small issues are lurking that I haven't been able to put my finger on yet.

In summary, if you could give some ideas on a solution for LV 8.2 runtime engine installing, that would be great. I'll carry on with the daq and Installer issues. If I get any new information, I'll post it. Thanks.

Art

[Hani R]

Hi Art,

The LabVIEW run-time engine 8.2 may be necessary for other installers that you include.  What Install Type did you select for the DAQmx intstaller (Full, Runtime, Runtime 1, etc)?   What other installers are you including in the build?  Is the main problem of including the LabVIEW 8.2 run-time engine the size of the installation/installer? 

[Mihill]

Hani & Paul,

Thanks for your help. I have continued working on these issues as time allowed. My problem with the explosive growth of the installer is the greatly increased time it takes me to build, burn a cd and run the test installations. If everything worked perfectly the first time, then I could live with it. But an additional 20 minutes per cycle isn't tolerable.

Here is the progress I have made.

1) By selecting different additional installers (without any source files added to my test project), I find the following:

NI-MAX loads LV runtimes 8.5 and 8.2

NI-488.2 2.5 loads LV runtimes 8.5 and 8.2

NI-VISA runtime 4.2 loads LV runtime 8.5

NI-DAQmx 8.6 (runtime 4) loads LV runtimes 8.5, 8.2, 8.0, and 7.11

2) The build error that I receive when building my application occurs only the FIRST time I attempt to build it after opeing the project. The message is that my error file cannot be found. By simply running the build again, the error goes away.

3) The problem I had of not seeing my DAQ device loaded into MAX using export/import as part of the installer, appears to be due to the level of the NI-DAQmx runtime that I chose. I started with level runtime 5 that doesn't have support for MAX. Somehow the hardware information made it into MAX (or some lower level) which allowed my application to run, but not show me the device or channels in MAX.

I don't see anyway around having NI-DAQmx loading all of these runtime engines, so I'm going back to our old method of having the GPIB card and driver setup and operational and the daq installation and driver setup and operational before the application installation. For convencience, I would like to combine everything into one installation and have control of the drivers in use but the price is simply too high. If you have any other suggestions, I love to hear them. Thanks.

Art

[Hani R]

Hi Art,

Certain components of the DAQmx run-time engine (or other run-time installations that include additional installers) are dependent on different versions of the LabVIEW run-time engine.  I've been told by the developers that the additional installed components are necessary dependencies.  The only way you could reduce the size of the installation would be to play with the installation level.  To provide feedback directly to the developers, I would recommend filing a product suggestion for the DAQmx run-time engine.