201003 error after reserving 9188 chassis

[_Bryan]

I have a program that uses an ethernet 9188 chassis and I want to check if it is connected and working when the program starts.  I tried a few differernt ways to do this and settled on reserving the chassis when the program starts.  If it can't be reserved I get an error and can put up a message and then close the program.  It seems to work ok.

But if I unplug (remove power) the 9188 and then plug it back in, wait 30 seconds or so to make sure it is running again and then run the program I get a 201003 error for an analog in task.  The chassis gets reserved properly and a digital IN task has no problems.  If I start the program again it starts fine with no errors.  I even tried putting a 10 second wait after reserving the 9188 thinking it just needed some time after being reserved, but I still get the error on the first run of the program.

Any idea why one task would be fine and another task is not able to access the same device?  Or is there a better way to check if the 9188 is ready?

Bryan

[SkyWalka]

This error is commonly related to a card interacting with a driver when there is still previous configuration information in MAX.  In your VI, are you using DAQ Assistant?

[_Bryan]

No I am not using the DAQ Assistant, I have a task setup that I am reading. 

I am not really sure I need to check if the chassis is in the system when the program starts.  The read will throw an error if the chassis is missing when the program starts anyway. 

[SkyWalka]

Does the error occur directly at the DAQmx Reserve Network Device VI?  The device name could be changing in MAX, causing you to retrieve the error during reserveration.

[_Bryan]

I can reserve the device with no problems.

I have one loop that reads digital input channels and another loop that reads analog input channels.  After I reserve the device the digital input channel task reads with no problems.  But the loop that reads the analog input task throws the above error.  I have them in seperate loops because the mA and TC cards (analog) are much slower than the digital.

[SkyWalka]

Sometimes 201003 can be associated with driver errors.  What version of DAQmx are you using?  If its older than 9.7.5, its worth a shot to uninstall your version and install 9.7.5 with the hardware disconnected.

[Tom_W_[DE]]

Hey Bryan-

There's a chance it could help, but I don't remember any recent changes that would have intentionally made a -201003 less or more likely.  So before you dive into a driver upgrade (DAQmx 9.8 is the newest released version as of today, by the way), I might offer a couple of other suggestions for troubleshooting.

You described a scenario in which you unplugged the chassis, essentially interrupting its communication with the host system.  There are some steps that I would recommend to ensure that the chassis and modules are accessible again, and they basically amount to Device Resetting the chassis (and making sure there are no errors) and then programmatically querying the DAQmx devices in the system (via the DAQmx device property node) and then programmatically Device Resetting each of them until there are no errors returned.

The Device Reset on the chassis is responsible for reconnecting the host and chassis from a DAQmx perspective and is also causes the modules to re-enumerate and show back up in the system.  The Device Reset on the modules is a fail-safe check to make sure that they actually came back and are accessible.

I posted some more background info and some tips in this thread.  Maybe it will help you get past this hiccup in your application, too.

I also attached some sample code I threw together for someone else that was running into an issue like this.  It Device Resets the chassis and looks for a certain count of modules to return.  You could augment it to look for specific modules (by name, serial number, etc) and to do the Device Reset or Self Test on the modules once they're back.

Hopefully this helps-

[_Bryan]

It is a fresh install of 2011 with drivers that came with the 2013 DVD.  I do not have the machine right now, so I will have to check the version when it is up and running again.

[_Bryan]

Thanks for the info Tom.  I will give it a try.