Can't communicate with DAQ until after Self Test

[KathySKing]

I'm using a cDAQ 9188 with ethernet and every day I must go into MAX to do the self test before my application can communicate with it.

I get the following error if I have not done the self test after I have powered up:

 exception = {Error=-201003 Message="Device cannot be accessed.  Possible causes:  Device is no longer present in the system. Device is not powered. Device is powered, but was temporarily without power. Device is damaged.  Ensure the device is properly connected ... 

[Chris-G]

Does this happen only when you restart your computer? Are you turning on the cDAQ after the computer has fully booted up? Prior to self-testing, the device is identified in both MAX and in the Windows Device Manager (assuming you're running Windows), correct? If so, does the 9188 show up as fully detected in MAX (the little icon next to the device under Devices and Interfaces will be white with a red "X" if not)? A lot of questions, I know...

The first thing to do would be to reset the chassis. That might fix any configuration issues that may be causing the problem. Another thing to try is to update your DAQmx driver to the latest version, DAQmx 9.4 (found here at the NI driver page). If that doesn't do it or you already have the latest drivers, check to see that that the NI Device Loader is started and that it is automatically starting (see here for an article overviewing the NI Device Loader).

If these don't work, a final workaround would be to programmatically self-test the device at the beginning of your application (see here for an article about programmatically self-testing a device). If you do decide to self-test it programmatically, it would be a good idea to run the self test and then have the program wait a few seconds before running the rest of the code. This will allow a few seconds for the self-test to fully run and for the 9188 to reset.

Chris G

[Tom_W_[DE]]

Hi Kathy-

Does your chassis stay powered up all the time?  It sounds like you are shutting down your host each evening and then booting it again in the morning.

You may be interested to know that both the host (running DAQmx) and the chassis are aware of their connection status and attempt to keep a connection active at all times by corresponding via a 'heartbeat' message.  If either side of that communication isn't possible then the entire communication path between host and chassis comes into question.

If either side of the link senses a loss in connection (or if both do), then some action is required to re-establish communication.  In the case of the host-side losing its connection to the device (which a reboot would definitely qualify as), any driver operation will cause DAQmx to reinitiate communication. 

The challenge, I'm guessing, is that you are trying to perform DAQmx operations on the modules in your chassis.  In the case where a chassis is Added but not Reserved, or where the chassis has sensed a connection lapse, the chassis shows up as present in the system but modules do not.  So, in order to make your modules re-appear you end up having to Self Test, Device Reset, or otherwise interact with the chassis before you can program the modules again. 

There are cases where the driver will attempt to automatically Reserve and make the chassis and modules accessible, but if the chassis remains active while the host connection goes 'down', then there can be this sort of confusion between host driver and chassis.  If you could ensure that the chassis was powered down and rebooted around the time that the host machine was it *might* re-establish communication automatically.  But, as Chris mentioned, inserting a Self Test or Device Reset at the beginning of your application would be more of a fail-safe.

Hopefully this helps-

[KathySKing]

Yes. I've been powering down the entire test system nightly. I guess, on power up, the NI chassis gets powered up before the computer has fully booted. So I did add a device reset to the beginning of my application and that seems to have solved the issue. Changing the Device Loader to automatically restart on failure did not solve the issue.

Thanks for the help.

[JohnTheOne]

Hello 

I have exactly the same issue, but I am using Matlab software. Is there any way to run self-test on startup in Matlab? Or it would be beter to schedule LV program which run self-tec on windows startup. 

[JohnTheOne]

Hello 

I have exactly the same issue, but I am using Matlab software. Is there any way to run self-test on startup in Matlab? Or it would be beter to schedule LV program which run self-tec on windows startup. 

Marko

[JustJohn]

Hello JohnTheOne,

I am not too familiar with the process of programatically self testing our DAQ products with any 3rd party software, but I believe that scheduling a self test after your computer has fully booted would be a good workaround. This can be done in LabVIEW using the following guide posted in an earlier comment. 

http://digital.ni.com/public.nsf/allkb/124D580AE300335E86256FDD006CE798

If you would like to have this done programatically within your 3rd party code, it might be worth while to check out their forums to see if there are any proven ways to accomplish this. I have to believe there is a way to call a function from a different driver within the code itself. We however, are not well versed on this process. 

[aeastet]

Here is what I do to fix that problem: