.net continuous input closer to real-time

[Jordi Serres]

Hi!

After reviewing the examples, I realize that the way NI library implements the continuous reading is by reading chunks of data one after another.

My application needs to gather data in real time at the same time it is shown on screen, and I wonder whether ther is a way of sampling in a better way.

I already make use of a dedicated thread for data gathering which only takes care of reading and storing the data. There is another thread that reads the buffered data in order to move it to the UI.

My point is that by using myTask.Timing.ConfigureSampleClock and MyAnalogInReader.BeginReadMultiSample, which provides an AnalogCallback delegate, at a sample rate of 4000 measures / s, the output I observe is of 1400 measures/second. Around a third of the expected output!

I know that Windows is not the better opsys to perform real time measurements, but I did expect some more performance in the .net threaded environment. I thought that starting up a task like this, involving an internal clock, it would be reliable enough to get 4000 samples in a second, and I'm centainly dissapointed such a low performance.

Or maybe I (hopefully)  am missing something?

[JaimeC]

HI,

I think it is normal you only arrive to 1400 samples per second, this rate depend on the system, code, programs running, OS, etc... so there is no any information we can officially say as maximum average rate, but I think 1400 samples/second is ok... Someone explained that maximum software based single point with a USB card was around 3 Khz....

If you need this single point exact measurements you should go to a Real Time system.

Here you have results about tests with Real-Time SW/HW single point acquirements:

http://zone.ni.com/devzone/cda/tut/p/id/5423

Hope that helps,

[Jordi Serres]

Thanks for your reply, Jaime.

Nevertheless, the paper you point me to shows labview data, and I guess that using measurement studio the results would differ of those presented in this paper.

The hardware I'm currently testing is a 4 GHz / 2Gb dual processor computer with an NI 6023E and all I need is to be able to read a 100Hz square wave to later on display the result on screen using another dedicated thread that coninuously renders the result using Direct-X technology (the fastest I know of).

Maybe I was wrong assuming that the internal clock in the NI board would take care of not losing any sample, or just a few, provided that the command to start the next read is issued right next to the read from the stream containing the measures read in the previous call, like in the following snippet:

abytMeasures = mobjTask.Stream.ReadRaw(mintSamples

);

mobjAnalogInReader.BeginReadMultiSample(mintSamples, mobjAnalogCallback,

null);

Okay. The code might be interrupted in between the two sentences, thus adding some delay I could cope with, but the results suggest that there is more software than hardware involved in the operation, and that would explain the slowliness I observe. Probably I was wrong thinking that  the BeginReadMultiSample command was the responsible for triggering the start of the read operation entirely relying on the NI board internal processor and timer, leading to a closer to null overhead for the computer CPU.

Maybe reading one sample at a time and triggering the read operation through a software clock would be a better approach to accomplish my goal?

[adamhb]

How many samples are you reading at a time on the host PC?

Using an PCI-6221 M series board I am able to sample 6 channels at 10 kHz if I only perform a read 10 times a second (i.e. 1000 samples per read).

The code segments are:

myTask

.Timing.ConfigureSampleClock("", 10000, SampleClockActiveEdge.Rising, SampleQuantityMode.ContinuousSamples, 1000);

myReader =

new NationalInstruments.DAQmx.AnalogMultiChannelReader(myTask.Stream);

daqmxReader.BeginReadMultiSample(1000, dataReadyHandler,

null);

I find this works fine on a P4 2.4 GHz PC with Windows XP, 1 GB ram. However if I try to do too much GUI updating or plot all the samples the GUI response is not able to handle it.

[JaimeC]

Hi,

There is a difference because from I understand from Jordi he wants to acquire single points. That is one point each iteration. Then this should be somek ind of software timed where the program controls the acquisition. And in that case it depends of how much code/programming u got after the acquisition to determine how fast u can go (your rate depends of the time the code/PC takes from one point acquisition to the next one).

As u said if u perform a continous buffered operation you take blocks from memory and the maximum rate is determined by the ADC converter of the board. Then your maximum rate is specified by your DAQ board,