load daqMX on start

[falkpl]

I have run into a small problem with an application I am distributing to the medical community which relies on data acquisition and the daqMX drivers.  The compiled version of the application dakes 10-12 seconds to load (looks like it froze) I have isolated it to the load time for the daqMX drivers.  My current and hopefully temporary work around is to dynamically load the main vi dynamically from a splash screen so the wait is less noticable since the user has a nice picture letting them know that the application is indeed loading.  Is thate a good method of loading the daqMX part of the application when the OS loads so when the application launches there is little or no latency?  Am I the only one with this problem?  Again this is only a problem in the built version of the application.  It is not very feasable to dynamically load parts of the daqMX dynamically since this is a major code overhaul.  Would some deamon daqMX process solve this (loads on OS startup)  should this be a build option if this is a widespread problem. I have few compliants about Labview but I am not too happy about this issue.

Paul

[Ryan_V[DE]]

Paul,

Is this the load time when the application is launched, or in the first call to the DAQmx driver? If it is the latter, one simple solution could be to call a single DAQmx VI, such as DAQmx Reset Device. This would cause the driver to be loaded into memory before the first time you try to acquire data.

Is your splash screen loaded on startup of the computer, or of your application? Your current solution does sound like a good one, though 13 seconds does sound a little on the long side. How fast is this computer?

I also like your idea about the DAQmx process/daemon loaded at startup, keeping the driver in memory. This could be something as simple as the reset device method above, which then loops and sleeps without termination. I'll check around to see if I can come up with anything else.

Hope this helps,

[falkpl]

This issue is isolated to loading the daqmx drivers and is only a noticable problem in the compiled version.  The machines are 2.8GHz P4 solely dedicated to the prototype application.  The splash screen calls the main application dynamically where all the daqMX code is called.  This is a problem everytime I load the application (it quits after completion so all vis will unload from memory).  I would like to know the easiest method of keeping daqMX drivers in memory and loaded with startup of the OX (WindowsXP) like a daqMX daemon?should this be an option on the installer if this is a real problem (not just isolated to a stupid error on my part).  Is this documented anywhere?  I did not have such issues when I had run traditional daq applications in a compiled form.  Thanks for the help.

Paul

[Ryan_V[DE]]

Paul,

I've restarted my computer and run DAQmx executables that I have written, and it has never taken more than 2-3 seconds to load the entire application. I've also asked around, and everyone agrees that this is an unnecessarily long load time. How is it that you narrowed down this time to the time it takes to load the DAQmx driver? Might there be anything else that could be causing the application to load slowly? Have you tried building an executable from a shipping example, and benchmarking its load time? Have you defragmented your hard drive lately? As not many people have seen this behavior, I doubt it is a viable option to allow DAQmx drivers to be constantly loaded into memory. Please feel free to fill out a Product Suggestion if you feel that this is an important addition to the driver. Otherwise, I would either use the existing method of dynamically loading DAQmx VIs, or implement the daemon that you mentioned earlier.

Regards,

[falkpl]

I know this is not a hardware issue since I have installed the executable on several different machines (about 10 all P4 many brand new so defragmentation should not help).  I also know that it is not an issue with the non daqMX part of my code since I implemented a dynamic call and the runtime engine and splash screen load rather fast (1-2 seconds).  So it is only when I get to the section of code which has the daqMX subvis, when the are first loaded into memory, the application stalls when loading.  If I rerun the application (press run arrow if I leave it visable and don't close the application after running) additional executions show no delay.  I am using daqMX 7.3 and Labview 7.0 the data acquisition is a PCI 6602 counter/timer card.  Again i do not see any slow response when running the application under the development environment (vi load into memory fast).  I am not sure why this is slow I have been very careful in the architecture of the application and it runs with no known bugs but this delay of the loading is not acceptable since it is being tested in the medical community for use during radiotherapy and the doctors will not have the patients (no pun intended) to wait for the application to load if they dont have to.

Paul

[Ryan_V[DE]]

Paul,

All my work lately has been with LabVIEW 8.0 and DAQmx 8.0. I'll try to rebuild an application on a machine with DAQmx 7.3 and LabVIEW 7.0, but I don't remember any exceptionally long latencies back then. This would at least let you know if upgrading would help the load time. Have you tried building a simple shipping example into an executable? How long does it take?

Regards,

[Ryan_V[DE]]

Paul,

Are you trying to load any global channels in your initialization code? If so, how many? Or are you trying to create a large number of chanels? Either of these could slow down the loading of your code.

Regards,

[falkpl]

All tasks and channels are created on the fly depending on the settings saved in a preference file, the file is loaded and 8 tasks are created and 8 channels are also created all are various counter events (some input some output).  I do not use any global tasks all the code is writen with daqMX vi and no express vi's are used.  I installed daqMX 8.0 today, the code runs slow still no improvment but also no issues with the upgrade.

Paul

[Ryan_V[DE]]

Paul,

So are these settings loaded / created during the splash screen when you experience the delay? If so, does the delay change if you execute them elsewhere? Also, how does a simple DAQmx shipping example perform when built as an executable?

Regards,