Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

nifslk.dll BSOD

I am experiencing a blue screen of death from nifslk, giving the error DRIVER_IRQL_NOT_LESS_OR_EQUAL. This is a repeatable error. When it occurs, labview hangs when executing a DaqMX read task, then i kill the labview executable, and unplug the usb cord to my daq hardware, and the blue screen occurs. I am using three USB-6009, one USB-9481. I am also using some other usb equipment including a GridConnect USB-CAN adapter, a usb-rs232 adaper, and a spectrum digital usb JTAG emulator.
0 Kudos
Message 1 of 23
(4,850 Views)
What version of the DAQmx driver are you using (and is it DAQmx or DAQmx Base), and what type of USB Host Controller are your USB devices connected to (accessible by using the Devices by Connection view in Windows Device Manager) ?

If you can, try connecting the NI USB devices to an external USB hub and the non-NI devices on either the root hub or another external hub.
0 Kudos
Message 2 of 23
(4,847 Views)

I just tried hooking the equipment up like you suggested, the ni stuff on one external hub and the other equipment on a different external hub. I am using NI-DAQmx version 8.0.0f0. Same problem exists.

 

As far as the USB devices in the PC, in Device Manager there is one " Standard Enhanced PCI to USB Host Controller" and 4 "Standard Universal PCI to USB Host Controller" Both of my external hubs show up under the "Enhanced one"

The controller has Device Instance ID of PCI\VEN_8086&DEV_27CC&SUBSYS_01AD1028&REV_01\3&172E68DD&0&EF
and hardware IDs of PCI\VEN_8086&DEV_27CC&SUBSYS_01AD1028&REV_01
PCI\VEN_8086&DEV_27CC&SUBSYS_01AD1028
PCI\VEN_8086&DEV_27CC&CC_0C0320
PCI\VEN_8086&DEV_27CC&CC_0C03

The USB root hub has device instance ID of: USB\ROOT_HUB20\4&4F1A976&0
and hardware ID of: USB\ROOT_HUB20&VID8086&PID27CC&REV0001
USB\ROOT_HUB20&VID8086&PID27CC
USB\ROOT_HUB20

I see that they have NI-DAQmx 8.3 out so I am going to to try to download that and see if it helps.

Message Edited by cfabien on 09-22-2006 02:07 PM

0 Kudos
Message 3 of 23
(4,836 Views)
Updated to latest DAQmx - 8.3 and still having the same issue, anyone have a suggestion?
0 Kudos
Message 4 of 23
(4,820 Views)
We should try to find out what in your application is causing the LabVIEW hang in the first place.  Unplugging the USB device isn't fully supported by the driver (see http://digital.ni.com/public.nsf/allkb/862567530005F09C86256674000B0431), so if you can avoid the hang then you should be able to avoid the crash as well by leaving the device plugged in.

Can you to modify your application to only use NI hardware and see if LabVIEW still hangs?  Also, if you can send me a copy of a simpler example VI which causes it to hang, I could look at it and see what about it might be causing the hang.
0 Kudos
Message 5 of 23
(4,807 Views)
Okay still having the problem. I have updated my motherboad bios and Chipset drivers to the latest from Dell, disabled hyperthreading on the processor. I made a small test application which also shows the problem. It's a simple sequence which reads multiple channel analog input waveforms 100 samples at 1khz from two different USB-6009s. It hangs on one of the DAQmx reads maybe 50% of the time I run the VI, totally locking up labview. The only way I can recover is to hit the stop button, then unplug the USB hub the NI devices are on which un hangs the system and shows the appropriate error for the devices being unplugged. If I plug them back in, they are recognized and I can do this over agian. Since I updated the DAQmx software, I haven't gotten a BSOD agian, but it still hangs.
0 Kudos
Message 6 of 23
(4,797 Views)
It looks like the application uses saved DAQmx Tasks to reads from both devices.  I noticed that there is no data dependence between the two reads.  If you chained the error clusters between the VIs (by wiring the Error Out indicator to the Error In control of the next VI), you may be able to avoid the hang condition without changing the performance of the VI.

Also, it is not essential, but if you will be reusing the same task several times in a loop or sequence, the performance could be improved by moving the task name constants outside of the sequence and loop.

Let me know if this helps.
0 Kudos
Message 7 of 23
(4,784 Views)
cfabe and I are good friends from high school, so I'll take this one

First off, I'm going to assume you have LabVIEW 8.0 since you were using DAQmx 8.0 to start with.  Correct me if I'm wrong.  Also note that LabVIEW 8.2 is out and you may be able to use that.  Also, LabVIEW 8.0.1 is out which provides fixes, but note that you should install this at the end of the day because it takes a few hours to do a mass compile.  These probably have nothing to do with your problem but I'm just letting you know they're out there.

Anyway, a few structural problems with your code:

- You are using a while loop with no execution timing and polling a boolean to get it kicked off.  This will suck too much CPU and may result in things being run multiple times.  Use an event structure

- You need to take a look at the full structure of DAQmx programs, see the Example Finder at Help >> Find Examples... >> Hardware Input and Output >> DAQmx >> Analog Measurements >> Voltage >> Acq & Graph Voltage-Int Clk.vi.  See how the Task gets created, started, read, and destroyed?  We need that timing.

- Sequence structures are generally frowned upon when not absolutely needed.  You are duplicating too much code.  For this, I propose a For Loop to pop out a couple of 2D arrays of data that we can then parse back out (or just display in a big indicator).

- Since you are using the same resource 5 times, we don't need to close and re-open it a bunch -- that's wasteful.  Let's loop around the same resource and just do 5 different reads on it.  This will also allow our error lines to get shifted back in with shift registers, so that the DAQmx Read knows not to goof around with the resource if there's already an error on the line.

Let me know if this program causes you problems.  I'm NOT a DAQ go-to but I know it enough...

In the meantime, everyone else can congratulate cfabe on his recent engagement! Smiley Wink

See ya!
berto

edit:  I'm a moron and forgot to attache the VI i made!

Message Edited by Berto on 09-25-2006 02:39 PM

0 Kudos
Message 8 of 23
(4,781 Views)

Thanks for the VI, berto. I tried running it and it's hanging on the DAQmx Clear Task.vi, sometimes it shows both executing sometimes only one of them, but it hangs labview until I pull the USB cord (yes I know, not supposed to... but it's either that or reboot, I can't even kill labview.exe) then after the cord is pulled it continues execution normally, even the error out of the Clear Tasks are "OK" It doesn't do this every time I hit 'GO', probably about 1 out of 4 will hang.

0 Kudos
Message 9 of 23
(4,774 Views)
Hmm, I'm not sure why that'd be happening.

What happens if you take the example titled Acq&Graph Voltage-Int_Clk.vi and put it in a big For Loop and run the entire thing 5 times (making you open and close the resource each time)?

What happens if you put a small 10ms time delay using the Wait Until Next MS Multiple VI in each For Loop iteration of my program?

Thanks,
berto
0 Kudos
Message 10 of 23
(4,767 Views)