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,219 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,189 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,161 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,124 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,102 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 {
            scanData1 = rdrScan[0]->EndReadMultiSample(ar);
        }
        catch ( DAQmx::DaqException * ) {}
    }
    if ( boolArmed || finish0 ) {
        rdrScan[0]->BeginReadMultiSample((long)rates[0], scanCallback[0], NULL);
    }
    finish0 = false;
}
0 Kudos
Message 6 of 13
(4,025 Views)

Hi Mike,

 

Could you go into more detail about the different file sizes – what is the typical or expected file size, how much deviation is there between files, etc.?  If you’d like, you can attach the entire Visual C++ project as a zipped file, and I’ll try running it here.  This will show us whether it is something unique to your system, or if it’s just a software limitation.  If the latter is true, then I’ll try to offer some workarounds or recommendations to fix the behavior.

 

Ed W.

Applications Engineer

National Instruments

0 Kudos
Message 7 of 13
(3,983 Views)
Hi Ed,

Again thanks for replying to my message, I can't really send you the actual project that I am working on, however I have been working on a small test program that I can make a little more robust to illustrate my problem.  It will probably take some more time for me to get to that point, but while I'm doing that do you think it is possible for me to simultaneously aquire data and write to the disk at the rate that I am running?  I know that I have instances where I have recorded 256 channels at 15625 S/s successfully, but it is sporadic for that setup.  But a setup that results in "bad" data 100% of the time would be 40 channels (10 on each card) at 100000 S/s.  In that test, file sizes on a 10 second recording are as follows:
card 1: 2000 KB (per file, one file per channel)
card 2: 600KB
card 3: 0KB
card 4: 1400KB

so I am missing data from cards 2-4.....  

I will continue to work on my test program to make it parallel my actual project in terms of aquisition and recording data.

thank you,
Mike
0 Kudos
Message 8 of 13
(3,982 Views)
Hi Ed,

I have attached my test program, it is configurable up to the max specs of the cards, just be carefull that the # channels * rate doesn't exceed 1.25M, I didn't throw any checking in for that.  Right about now I am out of ideas as far as what to do here, any help or ideas would be greatly appreciated.

thanks,
Mike
0 Kudos
Message 9 of 13
(3,948 Views)

Hi Mike,

 

You may have reached a limitation of the hard drive’s bandwidth with this file I/O.  However, I’m still looking into your program – I’ll post back with the results as soon as I can.

 

Ed W.

Applications Engineer
National Instruments

 

0 Kudos
Message 10 of 13
(3,928 Views)