Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

nipalk.sys crash bsod

All of my Labview 7.1 vi's with signal generation crash, causing a bsod.

stop: 0x0000007e (0xc0000005, 0xf760bd68, 0xeb847b38, 0xeb847838)

nipalk.sys - address f760bd68 base at f75e9000, DateStamp 4223992d

Checked windows website, this bsod is associated with a memory access violation.

I'm running Labview 7.1 with nidaq 7.4 on XP SP1 with a Daqpad 6016. The vi's were functional on this system. All automatic updates are turned off (no internet access anyway). Ran a vi with signal generation successfully, hit the stop button. Restarted vi and crashed. Vi now crashes every time I run vi.

Any ideas?


Austin
0 Kudos
Message 1 of 10
(9,392 Views)
Hi Austin-

This particular stop code may also result from a problem with a device driver in Windows XP. Your driver may have become corrupted for an unknown reason, so I would suggest uninstalling NI-DAQ 7.4 and reinstalling with a new installer available at this location: NI-DAQ Version 7.4 for Windows 2000/NT/XP

If this method is unsuccessful, please post your version of NI-PAL as listed in Measurement and Automation Explorer under My System>Software>NI-PAL.

Thanks-
Tom W
National Instruments
0 Kudos
Message 2 of 10
(9,376 Views)
I have already uninstalled / reinstalled ni-daq 7.4 with no success. I have version 1.9.0.0 of NI_PAL.

I can get the vi to run if the update rate, scan rate and duration are set to minimize memory usage. It appears that the vi completes the signal generation and write, then fails reading the data.
0 Kudos
Message 3 of 10
(9,364 Views)
Hi Austin-

Thanks for checking on the NI-PAL version- it seems you are definitely up to date on that end.

Can you please explain what you mean by setting the various parameters to "minimize memory usage?" I am still researching possible causes for the error- if you could provide a small portion of the code you're having problems with I would like to try to replicate the error here.

I would also suggest that you attempt to run the code on another machine. In reading about this blue screen on the Windows website I saw that it can also be associated with faulty or damaged memory in the PC. Please try to run your application on a seperate computer to see if we can isolate the issue to the first machine or if this seems to be a problem with the driver or other software.

Thanks-
Tom W
National Instruments
0 Kudos
Message 4 of 10
(9,339 Views)
I've included one of the problematic vi's. I don't think it will run without a handful of sub vis, but the structure should be reproducible. This vi analyzes a servo actuator step response. I can often avoid crashing by reducing the update rate (analog out) to 1 sample/second and/or reducing the acquisition rate to less than 100 samples/second. The crash seems to occur when the data is read from the buffer (analog in).

As far as testing on another computer... We only have 1 license to Labview 7.1, can we intstall on a 2nd PC for troubleshooting purposes (I would need email approval to pass on to our IT group)?

Thanks
Austin Mueller
0 Kudos
Message 5 of 10
(9,311 Views)
Running the "step response" vi with a simulated instrument in max does not result in a crash. Everything runs as expected. Does this indicate that the drivers are OK?
0 Kudos
Message 6 of 10
(9,308 Views)
Austin-

This definitely seems to indicate that the driver and code will work fine. I'm leaning towards a hardware problem with your computer.

I'll check on the issue of the single license and get back with the result.

Thanks-
Tom W
National Instruments
0 Kudos
Message 7 of 10
(9,286 Views)
Hi Austin-

In order to work out the licensing issues it would be helpful if we could correspond privately by email. Would you mind if I emailed you directly?

Thanks again-
Tom W
National Instruments
0 Kudos
Message 8 of 10
(9,260 Views)
Yes, you can email me directly. However that may not be an issue.

Today, through a set of unordinary circumstances I connected the Daqpad to different USB port on the Laptop. The vi ran at about 150 Hz update rate. When set at 300 Hz, the vi stopped with an error message that the update could not keep up with that rate. An error message a vast improvement over system failure.

Never one to let things be, I switched the Daqpad to the original USB port, sure enough the BSOD and system crash are back. It seems to me that this is a driver issue, possibly conflicting drivers installed on each USB port?

The crash and fix were repeatable (3x each). I upgrading the memory from 512 MB to 1GB in hopes of improving the update rate performance.

Any ideas on removing reinstalling the Daqpad without losing global channels?
0 Kudos
Message 9 of 10
(9,256 Views)
Hi Austin-

That is very strange behavior. It almost sounds like there may be a problem with your USB hub or drivers. Are these two ports on the same hub? Also, which error message did you see once the device was running on the second port?

You can save your DAQmx Configuration data in MAX by selecting File>Export and saving the file to your hard drive. These can them be imported back once the device is reinstalled.

Can you give me a bit more info about your computer, motherboard and USB hub if possible? I would recommend that you make sure that your USB drivers and BIOS are up to date.

Thanks again-
Tom W
National Instruments
0 Kudos
Message 10 of 10
(9,218 Views)