I have to reconnect to my DAQ device every time I start my computer... Why?

[JosephQ]

Hello, I am Ricky, a process engineer intern at a company. I am still a novice at LabVIEW and NI MAX. We have one cDAQ9181 set up to pneumatics and another set up to an encoder. Now, every time I start my computer the pneumatics box is already connected, as expected. However, the encoder one is not. When I click on it in the sidebar, it is found and connects, but the encoder itself does not connect until I perform a self-test. These devices have stayed plugged in and connected overnight, and yield no other issues -- they should be connected as soon as the computer is on. Does anyone know what is going on and/or how to solve this? I can try to provide a picture if necessary.

Thank you for taking the time out of your day to offer some valued help! -Ricky

[natasftw]

Have you tried adding a programmatic self-test to your code?  If you do this, it should self-test the device when the code starts and keep you from taking this extra step.  Otherwise, you generally want to start your computer before you start your cDAQ.  Either of these options should get around the issue you're seeing.

[crossrulz]

USB?  You might want to check your USB power settings.  By default, Windows likes to enable a power saving feature where it will turn off the USB hub power.  This has caused a lot of problems with people using USB DAQ for long tests.  But you can disable this feature by going into the Windows device manager and going into the USB hub settings.

[Yamaeda]

If the computer goes to Sleep it'll power off USB ports, causing thie becaviour. I have quite a few similar problems with some test stations since not all customers wants to use a separate energy profile for test equipment ...

/Y

[JosephQ]

I just tried the Reserve and Self-Test VIs. The problem there is that the device is not recognized as connected until I open "Network Devices" on the sidebar of NI MAX.
It is important to note that I am using ethernet for the boxes, my apologies for omitting that part.

Are there any more ideas?

Thank you all for your thoughts! -Ricky

[chipsahoying]

Curious...is your computer directly plugged into these devices or are they on the same subnet? Or are they further removed?

[JosephQ]

All of the devices (computer, DAQ boxes) are connected to a switch, which is connected to the wall for an ethernet network connection. 

It is important to know that the same kind of DAQ box is plugged in right alongside this Encoder one, and only one of the two identical boxes gives us this issue.

[chipsahoying · Accepted solution]

I did some research, and it is very well possible that this is expected behavior.

Prior to being able to run NI-DAQmx tasks on a network cDAQ chassis you must reserve the chassis to the current host system. Through the 'testing' you are doing, I believe this is also reserving the chassis. When a cDAQ chassis and PC lose communication due to the system powering down, the chassis will have to be reserved by the host system again. 'Sleep mode' could also be an issue because most PC systems disconnect or power down ethernet after a certain period of inactivity. To avoid having to go through NI MAX to reserve the chassis, you could use the "DAQmx Reserve Network Device.vi" which will reserve the cDAQ chassis to the system calling the VI.

[JosephQ]

I did have the Reserve VI in, but since there is the main device and the subdevice underneath it in the tree, I reserved the 'subdevice' (pardon my amateur terminology) in addition to the main one and it seemed to work despite an error message. I think it may have been solved but I will wait and see if it works again tomorrow. Thank you for all of your help!

[JosephQ · Accepted solution]

Update: After a few tests it has been found that I need to reserve and self-test a couple of times before it is successfully recognized -- putting those VIs in a while loop conditioned to "Continue if [the error is] true" should be a quick fix! -Ricky