PCI-MIO16XE-50 with DAQmx; Reset traditional driver

[WM_John_Weeks]

I am developing a C++ application using DAQmx on Windows XP. I have two boards for testing- a PCI-6229 and an old PCI-MIO16XE-50. Whenever I run my application, I get an error back when I attempt operations on the MIO16:

-89130 Device not available for routing.

The 6229 works fine.

The solution is to go to MAX, right-click on Traditional Devices and select Reset. An alert tells me that the driver was reset, then I can access the MIO16 from DAQmx calls.

Although I have Traditional NI-DAQ installed, I haven't been using it. Why should I need to reset it?

I am using NI-DAQ 7.1; would this be fixed by upgrading to 7.4?

[JoeSavage]

There has been a recent (7.4 timeframe) fix for the PCI-MIO-16XE-50, but it has to do with DMA support under DAQmx, not the problem you're describing.

If you haven't been using traditional DAQ at all, I'm a bit stumped as to why you're seeing this problem. In the hopes that we can figure this out together, here's an explananation of what we did to make the Traditional DAQ & DAQmx drivers interoperable with each other:

Prior to DAQ 7.0, the behavior of nidaq32.dll was that when the DLL loaded, it would enumerate the configured devices, and initialize the driver code for each device. We changed this in DAQ 7.0 such that the device initialization wouldn't happen until the first API function was called to use the device. Also, we changed the device initialization code to call into DAQmx to disable the DAQmx driver for that device. Finally, we added code to re-enable the DAQmx driver when the Init_DA_Brds or Device Reset.vi was called (or when the "Reset Driver for Traditional DAQ" MAX menu option is invoked), or whenever the nidaq32.dll is unloaded from all processes.

So, you should only see the behavior you are seeing if the nidaq32.dll is loaded by a currently running process AND if a trad. DAQ API call has been invoked on the PCI-MIO-16XE-50 in that process. It makes sense that you're not seeing this behavior with the M-Series device, because it's not supported by traditional DAQ at all.

Can you double-check that there is not another process running on your system that has loaded nidaq32.dll? You can use the "process explorer" utility, available for free download from www.sysinternals.com, to search for processes that have nidaq32.dll loaded.

If you don't find anything, then this could be a bug. Since DAQ 7.4 fixed the DMA issue with the MIO, you'll probably want to get this version of the driver anyway, which may have resolved the issue (though I don't remember such a bug). If you can reproduce this with DAQ 7.4, we'll still have an unsolved mystery. In that case, let us know and we'll try to reproduce your problem here.

Good luck,
Joe Savage

[gus]

Hey John-

Can you give me the serial number for your 16XE50?

Thanks!
gus....

[WM_John_Weeks]

Joe-

Thanks for the explanation. It has jogged my memory...

The code I'm working on is an update of an older product that works with Traditional NI-DAQ. Due to a customer request, I had the older plug-in installed lately. When it initializes itself, it calls into NI-DAQ to make sure everything is OK.

My fault!

[WM_John_Weeks]

Gus:

As you can see, I have determined that the cause of my problem is me 🙂

My MIO16 is an oldish one. Serial number (in hex, as displayed by MAX) 0xA87955.

Thanks!