timing problem application using DAQmx functions
MSR
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 analogand 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 executesaround 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 fastand 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 only190 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 theexecution 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
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
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
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 <a href="http://forums.ni.com/ni/board/message?board.id=250&message.id=30739&requireLogin=False" target="_blank">here</a> and <a href="http://forums.ni.com/ni/board/message?board.id=180&message.id=24625&requireLogin=False" target="_blank">here</a>.
Let me know if there's more I can do to help.
MSR
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
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
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 <a href="http://www.ni.com/support" target="_blank">www.ni.com/support</a>
to get in touch with a salesperson who can spec out a system for you.
JGS
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
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 <a href="http://digital.ni.com/manuals.nsf/websearch/2A7F7C4E786E3694862570D600777AD1" target="_blank">user manual</a> on page 5. 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 <a href="http://www.ni.com/products" target="_blank">www.ni.com/products</a>; 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
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
Mark E
Correct. The speed limitation is not the DAQmx driver. The
equivalent PCI-6251 is also limited to 1.25 MS/s (1-channel) or 1 MS/s
(multi-channel), so that?s the limit of this particular product family. A
3-year old computer should be able to handle this amount of data, depending on
how often overhead operations, such as reading data, are performed. If you are
calling a read function for every sample, that is going to create a lot of
unnecessary overhead that could slow down any computer.
The last point I want to make is that the sampling rate of
1.25 MS/s seems to be a USB limitation as indicated by this <a href="http://www.ni.com/dataacquisition/find_product_by_application.htm" target="_blank">page</a>, found from <a href="http://www.ni.com/dataacquisition" target="_blank">www.ni.com/dataacquisition</a> by
clicking on ?Compare Product Families? in the upper left.
JGS
Thanks! I know now enough to (let) buy me some new toys.
Regards, Jos
Nathan_R
I?m assuming that since you are
trying to emulate a SPI memory you have a read, write and clk line. The clk
line controls the timing for when you need to read and write. For your digital
read and write tasks what type of timing are you currently using?
I would recommend trying a continuous acquisition
with an external sample clock. In this case the sample clock could be the spi
clk line. This way your read and writes are hardware timed and you can possibly
run your application faster. This will also force your card to use its built in
buffers to store data before outputting it or writing it to buffers in the computer?s
memory.
Below I?ve included the path to a
couple of examples that show how to set up a digital task for continuous
external clk acquisition. The examples should be at these locations on your
computer. They were installed with the DAQmx drivers.
Continuous Digital Read ? External
CLKC:\Documents and Settings\All
Users\Documents\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Digital\Read
Values\Cont Read Dig Chan-Ext Clk
Continuous Digital Write ?
External CLKC:\Documents and Settings\All
Users\Documents\National Instruments\NI-DAQ\Examples\DAQmx ANSI
C\Digital\Generate Values\Cont Write Dig Port-Ext Clk
Let me know if you have any questions
and have a great week.
Thanks,
Nathan_R
As long as you are not trying to read and
write from the same line then both tasks can be started at the same time.
Also they can both use the same sample clock.
Just specify the same sample clock source for both tasks in each tasks?
DAQmxCfgSampClkTiming function. With the same source selected and both tasks
started at the same time. When you have a rising edge on the sample clock it
will read a sample from the read line and write a sample to the write line.
Let me know if you have any questions. Take
care.
Thanks,