Measurement Studio for .NET Languages

cancel
Showing results for 
Search instead for 
Did you mean: 

ni daq device boot not ready

Solved!
Go to solution

   I worked with a PXI system some time ago that had a LabVIEW program in the startup folder so that it ran on bootup.  The program used NI Daq devices, and we found that we had to add a delay to the boot sequence to allow the NI hardware to be fully initialized before the LabVIEW program started or the program would throw errors.

   A similar thread is at

http://forums.ni.com/ni/board/message?board.id=232&message.id=6373&query.id=1481785#M6373

   My current issue is with a LV 8.6.1 program on Windows XP.  I'm using a USB6212 daq device.  I find that I have to allow a full 60 seconds after bootup before launching the program to ensure that the Daq works.  If I use a 40 second delay, it works most of the time, but not always.

   I would have guessed that this would be a fairly common issue.  Has anyone found a reasonable solution for this problem?  As stated in the link above, I would prefer not to use arbitrary waits.  I would rather have a way for the OS to start my program after all the hardware is ready.  But a reasonable alternative would be something like the user in the other thread worked out in C++:  have a loop that tries to access the hardware and keep looping until the hardware becomes available.  I don't think a simple Daq define channels call will work, though, since once the error occurs (in my case), restarting my program is of no use.  I have to unplug the Daq device and plug it back in, or reboot the computer before I can get it to work.  So I need some gentler probing, such as the "find resources" type of call he suggested.

 

Regards,

   DaveT

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 1 of 4
(4,061 Views)
Solution
Accepted by topic author Dave_Thomson

Hi Dave,

 

Just a quick suggestion. I haven't tested this, but you might be able to do something like this at the beginning of your code:

 

device_self_test.png

 

This loops until there is no error from the DAQmx Self-Test Device VI and then you can move on to the rest of your code. Again, I haven't tested this in a startup executable, but I think it should work. Let me know if this helps. Thanks!

 

Thank you for choosing National Instruments.

 

Aaron

National Instruments

Applications Engineer

http://www.ni.com/support 

Message 2 of 4
(4,050 Views)

Aaron,

   Thanks for the idea.  I was going to try something like that, but hadn't identified what call to make to the device yet.  I implemented your idea.  The first time I ran it, it seemed to hang up.  Not sure about that.  But I've run it numerous times since then and it does seem to work.  Tentatively, I'll call it a success.

   The remaining issue is this:  when this program starts and the NI drivers are not ready, it hangs.  Once the NI drivers are ready, this call returns and will either have an error or not depending on whether the device is present.  The reason this is somewhat important is that I added some time-out logic to my program.  It only tries to find the device for 1 minute before giving up.  There is a count-down showing how much time is left.  But during the 20 seconds that the NI drivers take to load up, the count-down is stuck.  Once the drivers load, this either errors out or finds the device.  E.g., the time-out is not quite useless, but it isn't as smooth as I had hoped.  (E.g. the user feedback is meanless while it is hung for the first 20 seconds.)

   I'll attach my VI in case anyone cares.  This one is basic and uses front panel defaults.  I'll be adding more features, using a .ini file to define which NI device to look for, allowing multiple devices to be required, defining the time-out, and defining what other program to start once this one has ended, etc.

 

   I really think NI should have a utility like this readily available.  I'm surprised more people don't have this problem with programs that are supposed to run at bootup.  In the near term, here's a modest solution.

 

Regards,

   DaveT

Message Edited by Dave Thomson on 02-03-2010 12:05 PM
Message Edited by Dave Thomson on 02-03-2010 12:07 PM
-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 3 of 4
(4,045 Views)

The hang issue was easily solved by using a second loop - one for the Daq call and one for the timeout.  My more complete solution is available on my website.


DaveT

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 4 of 4
(4,015 Views)