timing problem application using DAQmx functions

[MSR]

Hi all,

While (Condition)
{
 <Code>
 DAQmxReadAnalogF64 (AIN,1,10.0,DAQmx_Val_GroupByChannel, AnalogIn, 1, &NumberOfSamples,NULL)
 
 <Code>
 DAQmxReadDigitalLines (Handle, 1, 10.0, DAQmx_Val_GroupByChannel, &BitValue, 1, &NumberOfSamples, NULL, NULL)
 
 <Code>
 DAQmxWriteDigitalLines (handle, 1, 1, 10.0, DAQmx_Val_GroupByChannel, &BitValue, NULL,NULL)
 
 <Code>
 DAQmxWriteAnalogF64 (Handle,1,1,10.0,DAQmx_Val_GroupByChannel,&Voltage, NULL, NULL)
 <code>
}

All I need is to read only one sample value from the analog and digital In channels and write only one sample value to the analog
and digital out channels.

My application needs to while loop to execute around 1000 times per second. When I run the code I found my while loops executes
around 190 times/second only. (I takes around 6 millisec for one iteration of the while loop).

When i commented all the DAQmx function and hardcoded the values (for my calculations) my entire while loop executes very fast
and it executes around 1050 times/second. (around 0.9 millisec for one iteration of the while loop)

Then I uncommented the all the last three DAQmx functions ie., DAQmxReadDigitalLines, DAQmxWriteDigitalLines, DAQmxWriteAnalogF64

and when i executed the code the loop executed around 500 times/second (around 2 millisec for one iteration of the while loop)

When I uncommented the remaining function DAQmxReadAnalogF64 (The first one) once again the loop execution is around only
190 times/second.(around 6 millisec for one iteration of the while loop)

My question here is what is the execution time for the DAQmxReadAnalogF64. Why there is a big difference int the
execution timing just for the one read function.

Is there anything i can do to improve the execution time of the code.

When I analysed the DAQmx functions i found there is another function called as DAQmxReadRaw.
If I use this function for DAQmxReadAnalogF64 will there be any significant improvement in my exectution time.

I am kind of new to DAQmx drivers. Any help/suggestions would be of great use to me.

Regards,
Sridhar

[JGS]

Hello Sridhar,

I am just starting with NIDAQmx and cannot give an answer to your question on ReadAnalog64 characteristics.

However I am building an application that reads a single sample from 3 ai-lines and - after processing these 3 - updates a single ao-line. And it seems to work far beyond the 1k frequency. For this, I assumed that I had to start with minimizing task programming overhead. So my approach is:

1. Start a task for analog input, continuous acquisition, using a buffer (8k), overwriting unread samples, and define a function when N(=1) samples are acquired

2. Simular define and start a task for analog output.

3. In the callback function for N samples, I retrieve the most recent available sample and process this.

So there is only once the overhead for the tasks,including starting the tasks. Both analog input and analog output are running continuous until I select a stop-button. 

Note that the processing is not synchonous with the actual rate of internal-clock data acquisition. I set this at a value slightly higher than needed. And I use a simple counter to display once in a while the actual processing frequency. With output to the screen it is only a few hundred hertz; with only output to analog task it becomes beyond 1 kHz.

Most of the code is from the examples for daqmx / analog in / voltage. Because one of the function requires an even number of samples, I had to expand the number of ai to four channels. Some of the code for creating the analog input is:

DAQmxErrChk (DAQmxCreateTask("",&gTaskHandleInput));
DAQmxErrChk (DAQmxCreateAIVoltageChan(gTaskHandleInput,chan,"",DAQmx_Val_Cfg_Default,min,max,DAQmx_Val_Volts,NULL));
DAQmxErrChk (DAQmxCfgSampClkTiming(gTaskHandleInput,NULL,rate,DAQmx_Val_Rising,DAQmx_Val_ContSamps,gSamplesPerChannel));
DAQmxErrChk (DAQmxCfgInputBuffer (gTaskHandleInput, SingleSampleBuffer));
DAQmxErrChk (DAQmxSetReadAttribute (gTaskHandleInput, DAQmx_Read_OverWrite, DAQmx_Val_OverwriteUnreadSamps));
DAQmxErrChk (DAQmxSetReadAttribute (gTaskHandleInput, DAQmx_Read_RelativeTo,DAQmx_Val_MostRecentSamp));
DAQmxErrChk (DAQmxSetReadAttribute (gTaskHandleInput, DAQmx_Read_Offset, -1 * gSamplesPerChannel));
DAQmxErrChk (DAQmxRegisterEveryNSamplesEvent(gTaskHandleInput,DAQmx_Val_Acquired_Into_Buffer,gSamplesPerChannel,0,ScopeModeSingleSampleCallback,NULL));
DAQmxErrChk (DAQmxStartTask(gTaskHandleInput));

Succes, Jos

[JGS]

Hello Sridhar,

I am sorry to say that I have to correct myself. My only excuse it that I have 7 devices at my "development" computer of which there are 3 USB devices of which there is only one single real hardware device.

With all simulated devices I get far beyond the 1 kHz (my target as well) but with the real hardware 'NDAQPad-6015' I am stuck at 350 Hz. So instead of an answer I get curious if somebody else sends a better reply.

Sorry, Jos

[Mark_E]

Hi Srindhar,

DAQmxReadAnalogF64 is a blocking function, so it will wait until NumberOfSamples is received before it returns its values. So the speed at which it runs is very dependent on the sampling rate and the number of samples expected. If you reduce the NumberOfSamples do you see an increase in speed?

Also, there are a few other threads that may help, including some example code to help troubleshoot. Take a look here and here.

Let me know if there's more I can do to help.

[MSR]

Hi Mark,

Thanks for you inputs. The number of samples that  I am using is only two. My code has two functions one for cards initialisation and other for data acquisition. 

My initialisation function: (I initialise for all the 16 channels of the card)

{

< code>

DAQmxCreateTask ("AnalogIn", &Handle);
DAQmxCreateAIVoltageChan (Handle, "AnalogIn/ai0:15", "" ,DAQmx_Val_RSE, -10, 10, DAQmx_Val_Volts,NULL);
DAQmxCfgSampClkTiming (Handle, "" ,1000, DAQmx_Val_Rising, DAQmx_Val_FiniteSamps, 2);
DAQmxGetTaskAttribute (Handle, DAQmx_Task_NumChans, &numChannels);  

<code>

}

My Data Acquisition function:

loop {

<code>

DAQmxReadAnalogF64 (Handle, 2, 10.0, DAQmx_Val_GroupByChannel, dataIn, 32, &numRead, NULL);

<code>

}

I increased the sampling rate to 10000 S/s also but there is no improvement in the timing of loop in the data acquisition function. It is still around 150 which is 6 msec for one loop execution.

But when i comment the read function in the loop the timing is around 500 which is 2 ms for one loop execution.

is there any thing that i need to do extra in my code. Your help would be appreciated a lot.

regards,

sridhar

[JGS]

Hello all,

In the first reply, the code shows "autonomous", continuous acquisition to a circular buffer. ReadAnalogF64 retrieves the most recent sample i.e. not waiting for A/D conversion.

Often we have to scale the input values anyway, so we can do this from the volts or we can do this from the raw digital (8/12/16/... bits) A/D value.

Is it possible to get the raw A/D values directly without ReadAnalogF64 ?

Does somebody know how to access (a pointer to) this circular buffer directly, and to the current position in this buffer ?

Regards, Jos

[Mark_E]

Hi Sridhar,

Would you mind sharing some background on your desired application? There may be other things to consider that would help you better overall than just answering these questions.

Let me do my best to clarify a few things that can affect program performance. There is overhead in every while loop, read function, calculation, etc. The read function is going to be one of the more time-consuming calls because it gets the number of specified samples from the buffer, interrupts the operating system, transfers the data across the PCI bus, etc. To reduce this overhead you can increase the number of samples read at a time.

The DAQmxReadRaw will return the binary value before its ADC conversion and scaling, so it theoretically could run faster than DAQmxReadAnalogF64, but could be harder to work with. If you need to do operations in volts, you’d need to convert the data and the conversion you would perform on the binary data would most likely be slower than DAQmxReadAnalogF64, so it’s generally not recommended.

Another limitation is that the operating system has no timing guarantee. The shortest wait function you can even program is 1 ms, because it’s generally not possible to expect a higher timing resolution. It could be faster, but it is entirely possible to go slower depending on what other processes are running. Speed is also dependent on the capability of your computer. The only thing I can think of to make your code faster than 1 ms per loop iteration is to have zero wait in the loop (which you may already be doing). Keep in mind that this doesn’t guarantee anything as the operating system can still decide whether it gives priority to your program or other “critical/important” processes, but it’s the best chance you have before you need to consider investing in a real-time system and FPGA. However, if that is something you want to pursue, please visit www.ni.com/support to get in touch with a salesperson who can spec out a system for you.

[JGS]

Hello Mark,

Can you be a little more specific on the overhead.

I have a similar problem (see previous replies in this thread) and aim for 1 kHz.

With updating the analog inputs and a single analog output to a stripchart, I am stuck near 300 Hz at my (3 years old) computer.

Without sending data to stripcharts and sending a calculated result to one analog output, I have a rate of 350 Hz for a USB device: DAQPad 6015

With identical (DAQmx) software and conditions, I have a rate of over 1 kHz for a PCI device: PCI-6110

The above mentioned software retrieves always a single, most-recent sample for 4 channels.

When I now try the slow USB for a full trace acquisition of 10k samples at 10 kHz, followed by stripchart display, the acquisition takes about 1 second and the display takes about one second. From this I assume that the data rate of transfer and conversion for the USB device is much more than 350 Hz. At this moment, I suspect the overhead for the USB communication or the overhead for each new (EveryNSample) callback.

Is there a white-paper or other information source that compares the performance of NI-DAQmx devices, especially when using single-sample-multuple-channel data acquisition?

Regards, Jos

[Mark_E]

Hi Jos,

When I said there is overhead in every loop, read function, calculation, etc., I was referring to the fact that those operations take more computational power to execute than a simply displaying a hard-coded number.

The reason you are stuck around 300 Hz is due to the specification of the NI DAQPad-6015 for analog output, which can be found on the product page under specifications or in the specification document. The analog output has an update rate of 300 S/s. The PCI-6110 is in a separate league, being a simultaneous-sampling DAQ card with an update rate of 4 MS/s—quite a bit of difference.

To compare specifications of different products, you can visit www.ni.com/products; choose “Data Acquisition (DAQ)” under the “Shop for Hardware” column in the middle of the page. Choose at least one parameter to search and then you can narrow it down to more specific criteria and compare the products by checking their boxes and clicking “Compare”.

I hope this helps.

[JGS]

Hello Mark,

I missed that specification.

I started the mentioned application with available equipment i.e. DAQPad-6015 and PCI-6110, but the application needs its own hardware. So yesterday I selected a few options from the M-series e.g. USB-6251 and PCI-6259 with the hardware selection/comparison as you suggested.  Learning from you reply, I also looked this morning again through the specifications for the USB-625x family. All these information sources give an update of 2.86 Ms/s for single channel and 1.25 Ms/s for four channels. I did not find any distinction between continuous pumping a full data trace from USB to host computer and repeatedly sending an update of a single sample (for 4 channels).

Can I assume now that the limitation - up to 1.25 Ms/s when using 4 channels - will be not anymore the USB-6251 device nor the DAQmx driver, but maybe will be due to the use of the USB 2.0 bus by other devices and probably will be the processing speed of my computer when it has to process each EveryNSample callback ? Or do I have to look into other kinds of specification ?

Thanks anywhy for your detailed information.

Regards, Jos