Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

NMI parity error with PCI-6229

Solved!
Go to solution

Currently, I am trying to get a PCI-6229 to work with one of our lab computers. We will be using LabVIEW 8.5.1 with DAQmx 6.7.1 to program the card. Using our proprietary measurement VI, the computer will crash at some point (not really reproducibly) with a blue screen saying "NMI: Parity Check / Memory Parity Error". All self tests and NI examples (shipped with LabVIEW) perform okay however.

Most likely, this problem is not a RAM-related issue (tried MemTest, different memory chips, different memory banks). Also, the computer's PCI bus works fine otherwise (for other acquisition cards for example). Quite annoyingly, the card appears to do a fine job in an older, slower computer. Might that be something to look at? Or are there any other ideas?
Our workstation is a Fujitsu-Siemens Celsius M460 with BIOS version 6.00 rel. 1.09 running Windows XP (32-bit version). The software to be used with the card is LabVIEW 8.5.1 with DAQmx 6.7.1.

0 Kudos
Message 1 of 10
(6,237 Views)

Hello,

 

It's quite surprising that you could communicate with the PCI-6229 actually.

Indeed, this device is not supported by the driver version you installed. You can find the list of every devices supported by each DAQmx version in a Readme.

So, I advice you to uninstall DAQmx 6.7.1 and install instead DAQmx 8.7.2 that you can download here

 To uninstall the driver, go to Add/remove Programs and choose National Instruments Software. Here you can choose what you want to uninstall/repair, then remove the PCI 6229, install the last driver, and set your DAQ device after in his PCI slot.

 

It should solve your problem.

 

Laurent P.

National Instruments

0 Kudos
Message 2 of 10
(6,231 Views)

Hi Laurent,

 

sorry to have mislead you; of course I meant DAQmx driver version 8.7.1, not 6.7.1. We can try 8.7.2 as suggested by you, however to my understanding there were no changes/fixes in 8.7.2 considering the PCI-6229.

 

Maybe I should also tell that our software was developed using LV 7.1 and has been converted to 8.5.1 afterwards. Do you expect problems from this procedure?

 

Thanks for your help.

0 Kudos
Message 3 of 10
(6,209 Views)

Hello,

 

so the problem doesn't come from the Driver, but probably from your program, if I may.

Indeed, I've just experienced the same behavior with a VI using 2 tasks. The first one was AI task and the second one was a counter task, which needs the AI.sample clock for the rate. (see in attachements)

This is just an example, but it proves that the error may occur because of the programming style.

So, the best way to help you is that you send me the VI which produces the bluescreen in attachments, or even a few VIs in a zipfile.

 

Have a nice day,

Laurent P.

NI Switzerland

0 Kudos
Message 4 of 10
(6,196 Views)

Dear Laurent,

 

it is comforting to hear that you can reproduce the problems we are experiencing here. My understanding of DAQmx drivers is that it should never be possible to crash the whole system by a mere programming error. Is that correct or am I mistaken?

 

AnywayI am attaching a screenshots of the problematic VI and another one where I changed some things. Currently, I do not really understand why the one VI crashes and the other one does not. Apparently, the crash failure only becomes apparent on some computers whereas on others, our VIs run perfectly okay. Do you have a suggestion on what particular parts of the VI to look at?

 

Thanks very much for your help.

 

Kind regards,

Lutz

Download All
0 Kudos
Message 5 of 10
(6,172 Views)

Lutz,

 

You are correct. Even if you have horrible DAQmx coding style(which your VI does not) you should not be able to crash the whole system.  I would like to try and reproduce the behavior.  Could you attach the actual VIs for which you put pictures above?  I can put them into LabVIEW myself if they are not available, but if you have them handy it could save some time.  I tried to reproduce using the simplier VI that Laurent posted above, but didn't get the crash.  My guess is that we are seeing some race condition that is only exposed if the timing is just right.  This theory seems to be confirmed by the fact that you don't see the same behavior on an older computer.

 

Unfortunately I don't think NMI errors dump any memory so it is hard to debug without reproducing the behavior.  How often does the behavior repeat?  Is it 1 in 10 times you run the VI, or 1 in 100 times?  Or is it every time?

 

Thanks for bringing this to our attention,

 

Neil S.

Multifunction DAQ Product Support Engineer

Research and Development

National Instruments

 

0 Kudos
Message 6 of 10
(6,129 Views)

Dear Neil,

 

thank you for attending our DAQmx problem.

 

I have attached to this message the two VIs I was referring to in my last post. The nocrash.vi currently works well -- no crashes, no errors. Unless the crash.vi actually crashes, it gives an error message (-200284 @ DAQmx Read (Analog 1D Wfm NChan NSamp).vi:6) saying "Some or all of the samples requested have not yet been acquired." Around one in three or four times however, the crash.vi will provoke an NMI bluescreen (provided that you adhere to identical "usage procedures" after a fresh restart of the OS).

 

I am also suspecting a race condition. However, up to now, I have not been able to figure out where exactly I should draw my attention. As you already pointed out, the NMI bluescreen does not leave any debug information behind.

 

Kind regards,

Lutz

Download All
0 Kudos
Message 7 of 10
(6,108 Views)
Solution
Accepted by topic author lutzp

Dear Lutz,

 

I could reproduce the bluescreen, and modified your program so as to avoid the race condition. What is happening actually is that you would like to time 2 tasks with the AOSampleClock as source before that the AO Task has started.

When programming as in the example I sent you (see VI in attachments), you shouldn't face this bluescreen problem anymore. However I recognize that such a thing mustn't happen even when "bad" programming... I will inform the Development so that it will be corrected with the next DAQmx driver version.

 

Merry Christmas,

 

Laurent P.

National Instruments
0 Kudos
Message 8 of 10
(6,046 Views)

We have a 6221 M series card attached to a BNC 2110, and we are using Labview 8.6 with the latest DAQmx drivers installed (should be 8.8) and the computer is running Windows XP.

So the purpose of my vi is to measure the number of pulses from a PMT (this is currently not connected to the BNC box) in a defined time period (typcially this would be every 5ms), and to then repeat this for a set number of time (typically this would be 100,000 times).  In order to do this with our current card I have 3 tasks running.  One task is using one counter to measure the number of pulses from the PMT.  Originally I had another task using the other counter as as a timer in finte sample mode. This, however, would not work since this tasked actually required the use of two counters (not the one I thought it was).  Thus with some help (actually a fair bit of help in the form of this part of the vi being bascially written for me with only a few minor variations) a solution to my timing problem came about.  This involves two tasks within a while loop, but it might be easier to just check out on the code how this was achieved.

My problem is that when I try to run this vi I get a bluescreen with the following words:
hardware mulfunction
NMI: Parity check/Memory Parity error
The system has halted.

I have to then restart the computer.

Now in the attached vi I have two wires entering the while loop.  One is a DBL wire and this corresponds to a value that can be found within the DAQ Output Parameters cluster as Dwell Time (ie it is an indicator).  The integer wire corresponds to the number of points we want to measure and it is a control value.  Now I have tried replacing the locations of where these wire connect to as constants (in case the problem was the wires entering the while loops), but I still got the bluescreen.  So I am not sure what is happening here.

 

Any help would be appreciated, I have also attached the vi.

Message Edited by scottum on 04-18-2009 10:05 PM
0 Kudos
Message 9 of 10
(5,698 Views)

I have same NMI parity error msg with blue screen Hardware Malfunction sys halt. My board is PCI-MIO-16XE-10. Interface with MTS Tensile test frame with multiple simultaneous test channels. The computer is a Lenovo small tower Think Centre with 2.4 GHz dual core processor, 2 gig ram. OS is XP pro with service pack 3.

 

System works normally except for these blue screen crashes. Crashes began about six months after the Lenovo computer replaced an older Dell OPtiPlex which never had this issue.

 

We have tested the ram, reseated everything. I have downloaded and installed the latest driver from the NI website. Still crashing.

 

Will appreciate any help you can provide.     bob.schmidt@henkel.com

Thanks

0 Kudos
Message 10 of 10
(4,948 Views)