Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

multiple DAQ cards

I have four 6071E PCI cards connected with a RTSI cable in a pentium 4 1.8G system with 1G of DDR ram.  I'm running some DAQ software that was written in Visual C++ .net.  The system works perfectly fine as long as my aggregate rate for all cards combined is less than 2.4 M S/s.   The Software limits max aggregate rate for each card to 1M S/s and when the total aggregate gets above 2.4M S/s, the CPU remains at 100% and the Software becomes somewhat unresponsive and the result is inconsistent amounts of data from each card.  My question is:  are there any hardware restrictions that would not allow me to be able to acquire 4M S/s from these four cards?  It looks like the software I am using is not multi-threaded, would investing time in re-writing the software to incorporate multiple threads solve my problem?

0 Kudos
Message 1 of 13
(4,228 Views)

Hi,

 

Thank you for posting to the NI forums.  Are you using DAQmx – if so, what version of DAQmx are you using?  I would recommend upgrading to the newest release, Version 8.3.1, if you haven’t already done so.

 

If that doesn’t help, I think that the first thing to troubleshoot would be the RTSI line.  We want to find out whether this problem is due to a bandwidth limitation of the RTSI bus.  Try setting up four analog input tasks with the same number of channels per device as your current application.  Acquire at the same rate that you are currently using, but do not include any synchronization over the RTSI bus.  If you see the same performance decrease, then we’ll know it’s due to a bottleneck in the PC itself.  The biggest bottleneck would be from the speed limitations of the data transfer to the hard drive.

 

Please post back with the results of this test.  If you don’t see any improvement, please provide the following information.

 

  1. Operating System – if you are using Windows XP, are you using Service Pack II?
  2. Are you performing continuous or finite acquisition?
  3. What are the input ranges for your channels?
  4. Are you running any other applications during your data acquisition?  If so, try closing these down, and check to see if there is any performance increase.
  5. What is the speed of your hard drive?

 

I hope these troubleshooting steps help.  Please post back with your results.  Thanks!

 

Ed W.

Applications Engineer

National Instruments

0 Kudos
Message 2 of 13
(4,198 Views)
Hi,

Thank you for replying to my post.  I was using Version 8.1 drivers, then upgraded to Version 8.3.1 as you suggested and still had the same issues.  I also tried not using the RTSI bus and still had the same results.  I was concerened about the potential bottleneck of transfering data to the hard drive, so I removed the code that modified the data and wrote it down to the  hard drive.  Although this did improve the performance somewhat, I still had problems acuiring data across the four cards at 1M S/s.  I am using Windows XP with service pack 2.  I am acuiring data continuously based on a start/stop button event.  The input range for the channels is user configurable within the limits of the cards, but for my tests I have been -5/+5 volts.  I am not running any other programs during my testing and my hard drive is  a ATA-100 Western Digital. 

Thanks again for your input,
Mike
0 Kudos
Message 3 of 13
(4,170 Views)

Hi Mike,

 

Thanks for the update.  I’m not sure why you’re not able to achieve these sample rates.  I’ll setup a similar system here.  If I don’t see the same behavior, then we’ll know it’s something unique to your program; otherwise, there may be a bandwidth limitation on the cards or the PC.  I’ll post back ASAP with the results. 

 

Ed W.

Applications Engineer

National Instruments

0 Kudos
Message 4 of 13
(4,133 Views)

Hi Mike,

 

I was able to setup a similar system here, but I haven’t been able to reproduce the behavior that you’re seeing.  The main difference is that I used LabVIEW instead of Visual C++.  Although the CPU usage did rise to 100%, the system performed fine and did not become unresponsive.

 

If you’d like to keep troubleshooting this issue, please post back with an attachment of your code, and I can try running that here.  Thanks!

 

Ed W.

Applications Engineer

National Instruments

0 Kudos
Message 5 of 13
(4,111 Views)
wow, I didn't realize that I was away from this project for this long!  As is often the case, I sent an update to my customer and they finally got back to me with some issues so now I am allowed to continue work on this project.  So I realized that part of my problem stemed from the use of a queue to copy the data from the cards one sample at a time then poping that data out one sample at a time later.  I'm not sure why the guy who wrote this program thought that would be neccessary, but now I'm writing the data directly into files.  The CPU is still  running at 100%, but I am not experienceing the lock ups that I was seeing before.  However I am having issues with the files that each card writes to being different sizes, this only happens when I am running at my max rate of 1Mb per card. 

here is the code I am using, there are four of these ScanCallback functions, corresponding to the four cards in the system.   Do you think that I am just running into system limitations or is it a software thing?  Any feedback would be greatly appreciated.


System::Void Recording::ScanCallback1(IAsyncResult *ar)
{
    short buffer[100000];
    int j;
    if ( boolRecording || finish0 ) {
        try {
            scanData1 = rdrScan[0]->EndReadMultiSample(ar);
            for ( int i = 0; i < chanCounts[0]; ++i ) {
                for ( j = 0; j < rates[0]; ++j ) {
                    //que[0][i]->push((short)((scanData1[i,j]*2048)/gainFactor[0,i]));
                    buffer[j] = (short)((scanData1[i,j]*2048)/gainFactor[0,i]) + polarity[0,i];
                }
                fwrite(buffer, 2, j, files[0][i]);
            }
        }
        catch ( DAQmx::DaqException * ) {}
        ++tracker[0];
    }
    else {
        try {
        &