PCI 6527/PCI 6602 Hardware resource conflicts

[agchino]

Hello,

I'm running into a problem with my motherboard and a comination of NIDAQ cards.  Normally I have all 6 PCI slots filled with various cards, I have narrowed the problem down to some combination of 2-3 cards.  I can install a PCI-6527 card and a Commtech-Fastcomm ESCC-PCI card into various combinations of PCI slot positions, some combinations the OS will but just fine.  Some combinations the OS will come up and show 50%+ cpu utilization in the Idle Process, attribuated to interrupt handling.  When a good combination is found I can then install a PCI-6602 card and the utilzation problem shows back up.  I have not iterated through all the combinations of the 3 cards yet to see if there is some combination that works, but it appears there is a resource conflict.  I have installed NI-DAQ v 7.4T, and have the latest drivers for the Commtech card.  I also have one more ESCC-PCI card that needs to be installed, so this may become more nerve wracking.  I do not have the ability in the BIOS to manually set PCI assignments.  This is on a fresh install of Windows 2000.

Thanks

Message Edited by agchino on 09-02-2005 03:03 PM

[Doug M]

agchino,
I'm not quite understanding what you mean by "utilization problem" -- the Idle process should normally be at 90+% with nothing running.  Are there any error messages? Do the cards show up in Measurement and Automation Explorer? Can you communicate with the boards?  I would try only installing National Instruments boards first, make sure that is working, then add in the Commtech boards.
 
Also, you may want to migrate to the NI-DAQmx driver if you are currently using the Traditional driver.  It is more robust with a much easier programming paradigm.  It can be downloaded for free on our website.

Doug M
Applications Engineer
National Instruments

[agchino]

Yes the idle is taking up 90%+ of the processor time, but if you go to the tab that says "Performance" the CPU Usage consistentaly stays above 50%.  I used a 3rd party tool that broke out what the system idle process was doing, and it was spending most of it's time servicing interrupts.

Yes the cards show up in the explorer, I can communicate with the boards using the in house app we developed for this system.  There appears to be no functional problem with any of the boards during this condition.  I just used the explorer to connect with both boards and the "test resources" button returned that both passed.

I have not downloaded mx because we used Visual C++ to integrate some NI-DAQ API's into an application we developed.   I have not taken/had time to look into whether using mx would break our application or not.

[Doug M]

If you already have an application that uses the Tradtional NI-DAQ C API, you would have to rewrite the code that uses the DAQ function calls, as DAQmx function calls are quite different.  I would definitely recommend using NI-DAQmx for future applications, however.

If things seem normal with just National Instruments boards installed and the issue arises when you put in the other boards, I would contact the vendor of your other boards.  As far as setting IRQs in Windows 2000, I believe Windows does it automatically, and ignores what the BIOS settings for IRQs are.  See the following Knowledge Base. 

Aside from this it seems that the boards are working -- interrupts are obviously needed to communicate to devices but as far as what may be going on at the process level or how the other boards may be affecting this is more an operating system issue.