04-13-2006 01:59 PM
04-14-2006 01:34 PM
Hello Pavan,
You do not mention the error you receive when you try to run the application at
10MHz. I expect that you are running into buffer overflows. This
typically happens when you try to sample at rates that high and save the data
to disk. This is because of the slow transfer rates of hard drives. You
would require transfer rates of approx 20MB/s per channel (10M samples/second *
2Bytes/sample = 20MB/s), or 60MB/s for 3 channels.
If you stop writing the data to a file, you should be able to read the data at
that rate.
Regards,
Jesse O.
Applications Engineering
National Instruments
04-14-2006 01:42 PM
04-14-2006 01:50 PM
Pavan,
When using the parameters "Dev1/ai0:2, 1MS/s", you would only require
6MB/s which is within most hard drive data transfer rates. When running
at 10MHz, you require 60MB/s which is most likely faster than your hard drive
an handle.
Regards,
Jesse O.
Applications Engineering
National Instruments
04-14-2006 03:02 PM
04-17-2006 12:12 PM
Pavan,
The typical way to achieve a faster transfer rate to disk is to setup a raid
system (usually raid 0 with 4 drives). There are some things to keep in
mind when setting up a raid system. First, when from you DAQ card you are
transferring approximately 60MB/s from your PCI card to your RAM. You
then read that buffer with c# and store that data on a hard drive. If you
purchase a PCI raid controller, you are sending that data back along your PCI
bus requiring 120MB/s total along your PCI bus. The theoretical maximum burst
rate for a PCI bus is 132 MB/s. Most systems are not capable of transferring
this fast, and you system might not be able to keep up with 120 MB/s.
The other option is to have a system with two PCI buses, or one with a PCI bus and
PCI express bus. We also have an alliance partner that specializes
in high speed stream to disk solutions. Please see the following
Knowledgebase here.
If you are interesting in one of their solutions, please verify with
them that their driver supports your device in .NET.
Finally, when streaming to disk make sure that you have binary file
selected or you will require much more than 60MB/s when streaming to disk.
Regards,
Jesse O.
Applications Engineering
National Instruments
04-17-2006 02:08 PM
04-17-2006 04:30 PM
Pavan,
I apologize for the mix-up. When I was looking at the code I assumed that
LogData function actually saved the data to file. In this example, all
the data is saved to memory then saved to file.
Now if you have 1GB of memory, and you are only saving data to RAM, it will
only take a couple seconds (approx 16) for 1GB of memory to be filled with this
acquisition. This is assuming that windows and all other applications are
taking up no RAM. The more space each application is taking the less time
before you fill your memory. If it was my system I would get approx 3-4
seconds of data before I ran out of memory. I assume the problem you are
having now is associated with this. As soon as you run out of RAM and
start to use your hard drives swap file you run into the hard drive speed
limitation. For 1 minute of data, if you saved it all to RAM you would require 3.6GB of
memory. You should be able to run this application for very short periods
of time, or change the acquisition mode to finite and only acquire a small
amount of data (a couple seconds).
If you comment out the the LogData line in the AnalogInputCallback
( LogData(data); ) method and the line CloseFile(); in the stop button callback I
would expect that your application would run successfully. This would
allow the acquisition to take place without putting all that data into memory or saving any data to a file.
If you change the application to save to disk during the acquisition, you will
encounter the problems I mentioned before. Streaming directly to disk, or
using a raid controller on a separate bus, is probably your best options for
acquiring that much data at 10MHz.
Regards,
Jesse O.
Applications Engineering
National Instruments
04-17-2006 05:02 PM
04-17-2006 05:04 PM