Who has had a PCI-DIO-32HS card fail, ever?

[Euler's_ID]

I've looked through the forum somewhat and I've found little concerning the card itself failing.  For instance, I found something about the card failing due to driving it with a TTL high before it was powered, but that was about it as far as actual death of the card.  Hence, I'm wondering if others besides myself, and therefore my design using the PCI-DIO-32HS, have killed or had the death of a PCI-DIO-32HS DAQ card and what was determined to be the root cause in your case(s).

Also, by chance, did your card's death also take down the PC such that it wouldn't POST (Power On Self Test) until the card was removed?

Thank you all.

[JVP]

Hello Euler's ID,

This post should actually be in the Multifunction DAQ (found here: http://forums.ni.com/t5/Multifunction-DAQ/bd-p/250) generally you will have a better chance of getting the right people to respond to your post because this is a Multifunction DAQ card.

So what was the particular issue that you saw or in your case what caused the card to fail?

Regards,

JVP

[Euler's_ID]

I don't have a root cause yet, only evidence from which to direct my troubleshooting efforts.  I experienced error number -10461 after some hardware was disconnected and reconnected when calling upon legacy DAQ-based software which had previously been functioning fine.  This error wouldn't stop occurring so the PC was eventually rebooted, but the reboot failed to POST.  POST would not resume until the DAQ card was removed.

What's interesting is the new DAQ card required removal from both that PC and another lest the PC not POST again.  However, an older version (G) of the new DAQ card (H) allowed the PC in which it was installed to recover after the -10461 error.

Hence, as I see it, the -10461 error was either cause or effect of a PCI-DIO-32HS Rev H death.  The quest for answers continues.     

[JVP]

Hi Euler's ID,

   I have done some research for this particular error with the DIO boards, and there is an article related to your issue:

Error 10461 with Older DIO Devices and DAQmx

Before you do the updates that are suggested in the previous article, I would like more information from you.

1) Was the PCI-DIO-32H working previously?

2) Did you do any driver updates or anything of that nature prior to the error -10461?

3) What is version of Traditional DAQ installed on your computer?

4) Do you know when this error occured, what was going on in your system or code?

Regards,

JVP

[Euler's_ID]

1. Yes, the new card was functioning fine -- the design seemed to work whenever called upon until the error popped up which took out the card.   

2. No, I was using the same NI software and system (for this design) software throughout.

3. I see this question as not having bearing in that I experienced the error on both the design's PC and the development PC.  LabWindowsCVI wasn't installed on the design's PC, only the 2010 Runtime Engine so I could run the legacy software, while at the same time the development PC, which does happen to have LabWindows installed, was not used to create the legacy software.

4. No, I do not know what was happening at the exact time of the error, and I am also not the author of the legacy software -- I'm just using it.  (If it helps, I think the software was created using LabWindowsCVI 6 way back when.)

[Euler's_ID]

I think I left out an answer.  I'll try to answer the question this way:

NILWCVIRTE2010. exe gave me the runtime engine

TDAQ740.zip installed traditional DAQ

These were installed after installing NI-DAQmx (8.9 I think) and installing the PCI-DIO-32HS (Rev H) DAQ card.

Hopefully the above breaks some code for you with respect to your research.  For me it was all just a means to an end, and NI directed me to install these to get things to work for my purpose.    

[JVP]

Hello Euler's ID,

Basically, the error that you received as mentioned in the previous post's link (Error 10461 with Older DIO Devices and DAQmx) is a known issue using Traditional DAQ with DAQmx 8.8, 8.9 and 8.9.5. This issue has been fixed in DAQmx 9.0 and later. If you can install NI DAQmx 9.3 these symptoms you have mentioned should disappear. Please let me know if this solve's your issue.

Regards,

Jignesh P

[Euler's_ID]

First, the issue has not been resolved yet. I still have boards dying. At $1500 a pop, this issue needs to be resolved.

I was mistaken about two things said earlier: 1) The G card has now failed; therefore, the recovery was a fluke, and 2) I thought 8.x was installed in the design's PC, but as it turns out it has been 9.x. (The version numbers are tough to remember. Sorry. I think it's 9.1.7.) Is there a known issue with that one also?

What I really want to know is why the original board I returned to NI failed. I want to know specifically what slot contacts are holding up the PC, keeping it from performing its POST? I don't want to hear any more suggestions for installing version x.y.z. without also having a specific reason for why it should work. These cards are too expensive. There's something very wrong with this design such that I can't keep the DAQ card alive using Traditional DAQ software that has run for years. The system works until (it seems) you think the problem's been resolved, and then whammo! An esoteric error number in a window is thrown up. (It's not just one error. The error can change as you try in vain to avoid cycling power as the only way out of the now dead software.) You can't run the software past a button click due to the error window, but yet the PC itself works fine...unless you cycle the power: NO POST.

What on earth in this design could be killing these cards? The PCI slot was tested via substitution with a video card and there was no issue found. I just can't keep the DAQ card alive. Help! Trying version x.y.z of the driver is not a good enough solution. Running software should not just out of the blue blow up a DAQ card and cripple the PC only at power-up. Rather, there should be an error, some incompatibility indication before the card is dead. Frying a $1.5K card...eventually...is not how you find the source of an incompatibility issue. Like I said, HELP!

I'm suspecting the software is creating a bus contention somehow which doesn't end in an error but, rather, an internally shorted IC, where I'm guessing it's the large NI ASIC just above the card edge due to the considerably noticeable heat generated while the PC tries to POST, a short that is undetectable except that the software stops working, but nevertheless a short that won't let the PC continue its POST if power is removed and then reapplied to the PC. It's like the software has had a "sacrifice(PCI-DIO-32HS, legacy_sw);" function embedded into it that only gets called under certain circumstances, circumstances that involve the power-up sequence of a PC. Help!