DAQmx Error Windows: Ever Seen This?

[robweaver]

On several occasions my group has seen the following error window appear when running an executable built with LabVIEW (2009 or 2010).

Prior to getting this window there were at least 10 other windows with "Resouce Not Found: <DAQmx VI name>.vi" error messages. The executable was installed via an Installer that was built with drivers included: Run-Time Engine, DAQmx App Dev Support, DAQmx Core Runtime, DAQmx MAX Config Support, MAX...

Also, the "Require Development System" was not checked in the Installer properties. And it's important to note that the Installer was built in the same manner that we build other installers and it did not do this on all of the installs, only a select few.

No warnings during installs and install appeared to work fine. The startup VI opens after this dialog with a broken arrow.

A complete uninstall of DAQmx and then a reinstall of the application from its installer (includes DAQmx) seems to fix the problem, but this can be a HUGE waste of time for my group and our users.

Has anyone seen this? If so, what might be the cause of it?

Thanks in advance,

Rob

[enderWiggin10]

Hi Rob,

This issue can be caused by several things.  Sometimes the driver is not correctly linked to the EXE.  It could be that you developed using one version of the DAQmx driver, and then deployed using another.  It could be that the hierarchy of your VI is not properly laid out.  Perhaps mass compiling the project files before building could help out with this.  Also, users have tried to make the EXE debuggable and to wait for debugger on launch and this has helped out.  Finally, can you try to use 8.x file structure for the hierarchy?

Best,

[enderWiggin10]

Further, did you indicate taht you installed the EXE on a machine that already had DAQmx installed, and it did not work.  But after uninstalling, and then isntaller the driver vrsion that corresponded to the isntaller's driver version it did work?

Best,

[robweaver]

Adam,

Thanks for the feedback. What's been hard to understand about this is that it's been unpredictable.

Further, did you indicate taht you installed the EXE on a machine that already had DAQmx installed, and it did not work.  But after uninstalling, and then isntaller the driver vrsion that corresponded to the isntaller's driver version it did work?

To clarify: the way I've fixed this is to uninstall DAQmx from the PC, which also uninstalls my application. Then I re-run the installer for my application, which includes DAQmx, and after that reinstall it no longer gives those errors and runs normally.

It could be that you developed using one version of the DAQmx driver, and then deployed using another - I don't believe this is it, because I used the same disks to create the installer that I used to install LabVIEW (using 2010 by the way).

 It could be that the hierarchy of your VI is not properly laid out - I don't believe this is it, because this error does not occur on all machines this application is installed on, also can you elaborate on what you mean by this and how it could be affecting my problem?

Also, users have tried to make the EXE debuggable and to wait for debugger on launch and this has helped out - can you elaborate on what this might be doing to help? and this is a pretty large application of 500+ VIs and I'd like to avoid making the EXE debuggable.

Finally, can you try to use 8.x file structure for the hierarchy - I'd prefer to keep it as 2009 layout because I called several VIs dynamically and build the path to these VIs relative to my MAIN, what might be the benefit of switching to this layout? because as I mentioned this doesn't happen on all machines.

Thanks,

Rob

[enderWiggin10]

Hi Rob,

To clarify, the question concernign the uninstall of DAQmx fixing the issue was getting at whether or not you had DAQmx installed on your machine before running your installer that also tries to install DAQmx.  the logic behind this is that if you indeed did have DAQmx isntalled before, it migh tbe better not to have it installed, and let your installer install the proper version of the DAQmx driver.

Best, 

[robweaver]

Adam,

Not having it installed could be an issue because we don't have control over what version are on our users machines prior to the install and we'd prefer to let installer update the drivers as needed to avoid the user going in and uninstalling components.

Rob

[enderWiggin10]

Hi Rob,

Thank you for the reply.  I understand that this is not a desireable solution.  however, this would help us to find the root cause.  If it is indeed a problem with having a previous of version DAQmx installed, then we can work to address this problem.  If this is not the problem, then perhaps the issue could just be within the installer.

Best,

[JÞB]

OK I'll chime in.  I'm shooting in the dark here but the line "does not happen on all machines" points toward a conflict between the machine and DAQmx.  Makes me think of the DAQmx HID bug.

Seth B reciently posted an KB article "Why Do Certain USB Devices....." with this quotation

"While many HID devices have the potential to cause this problem, we have confirmed that common HP and Apple brand keyboards and mice can cause this issue.  Versions of NI-DAQmx affected include 9.1.0, 9.1.1, 9.1.5, 9.1.6, 9.2.0, and 9.2.1.  Additionally, any driver that uses NI-DAQmx, such as common Modular Instrument drivers (e.g. NI-SCOPE, NI-DMM, and so on) will be affected"

It may be worth the effort to install DAQmx 9.2.2.  Or if that is unacceptable there are PATCHES for most recient DAQmx versions.   Here