PDA DAQ DAQCard 6036E problem with acquisition rate

[Imaginatics]

Hi all,

I am trying to run a 4 channel analog input at 500 samples/sec/channel (2000 aggregate) on a Juniper Systems AllegroCX PDA under LabVIEW PDA 8.2.1 and DAQmx Base 2.2 and I am having problems with the acquisition rate being slow.

In DAQmx Base Configuration Utility I have a 4 channel task set up called ndt_ai_4. 
It is Bipolar, Differential, Gain=1. Channels 0 - 3 are all set up like that.
Rate = 500, Continous.

I have attached the exported DAQmx Base Configuration Utility tasks list as: ndt_tasks.cfg
I also included the PDA project and a test VI:  TEST_Loops per Sec 4CH_AI dbl.vi

When I run this simple loop, which is using the 2D DBL DAQmx Read to get the 4 channels I only get about 1.17 loops per second, for an aggregate read of 468 samples.

Since I have the task set up at 500/channel/sec and the read at 100/read, I would expect to get 5 loops per second. 

Strangely enough I do not seem to get an overflow either ???.  Since I am obviously not reading the data out as fast as the task is set up to acquire, I would expect to get a buffer overflow pretty quickly, but that does not occur. It just blissfully runs waddles along forever.

Can anyone help please?  I truely hope I am just doing something simple and dumb.

Lastly, has anyone ever been able to achieve sustained 4 channels at 500 s/sec/channel for any PDA project (with datalogging, oh yeah, I forgot to mention, I have to log as well, but lets start simple, with just the DAQ) and if so could you point me in that direction?

Thanks in advance for help.
Mike Ashe

[Imaginatics]

Oops,  I forgot to mention the DAQCard is a 6036E.

Thanks again,
Mike

************************************
Michael Ashe             Imaginatics
Imaginatics Control & Test Systems
(860) 444-2141  (Phone)
(860) 961-0876  (Cell)
email:  michael.ashe@imaginatics.net
Waterford, CT, USA
************************************

[Steve_B]

Hi Mike,

The issue you are experiencing is a limitation based on the memory used to perform the read command. The continuous read involves making multiple read calls from software and there is an associated memory allocation based on amount of data to be read. The driver makes an adjustment to the sample rate based on the current available memory and the amount of data. If you set your system up for a finite measurement, you avoid the need for multiple reads and you can achieve a much higher sampling rate. You can increase your continuous sampling rate by changing the data type to Raw I16 instead of a double which will allow 4 samples to fit in the same memory space. You would have to do some post processing of the data to get it into the same format. Please refer to this knowledgebase article for additional information.

Maximum Analog Input Transfer Rate From PCMCIA Card to the PDA Buffer
http://digital.ni.com/public.nsf/allkb/29C5C53D83A9F91786256F43006ECAE2?OpenDocument

You can also refer to the NI-DAQmx Base Readme for more information about the functionality when it is used with a PDA. You can also take a look at moving your VI to the PDA by selcting the Generate Serial Only in the application builder in order to minimize the memory that is needed on the PDA as recommended in the Readme file. 

NI-DAQmx Base 2.2 - Windows 2000/Vista x64/Vista x86/XP
http://joule.ni.com/nidu/cds/view/p/id/424/lang/en

As far as post processing and logging your data, I would recommend you take advantage of the producer consumer loop architecture. You can find a template for this by selecting File>>New>>VI>>From Template>>Frameworks>>Design Patterns>>Producer/Consumer Design Pattern (Data). You can use the producer loop to Read your measurements and you can use the consumer loop for the post processing and logging. The producer loop is able to run without any post processing delay. This example makes use of queueing to pass data between the loops. You can refer to this Developer Zone Article for additional information.

Application Design Patterns: Producer/Consumer
http://zone.ni.com/devzone/cda/tut/p/id/3023#toc2

[Imaginatics]

Hi Steve,

First, thank you for the reply.

We cannot do finite acquisition in this application, it has to be continuous and run for up to 90 minutes.  The PDA has plenty of memory to log data for this time limit.

I had already tried Raw I16 acquisition, but I thought I'd try again.  I took the VI above, that reads a 2D double array and changed it to Raw I16s. Note that 2D I16 is not supported, but I assume that the 400 length array of I16s is just the 4 channels of 100 samples, all concatenated together. Unfortunately the speed up was not the 4x you stated below.

Double loops/sec:      1.17
Raw I16 loops/sec:    1.29

Here is the new VI and project file for comparison. They use the same DAQmx Base config file as above.

I had already ready read the article: "Maximum Analog Input Transfer Rate From PCMCIA Card to the PDA Buffer" and I left feedback.  Unfortunately this article only really covers finite acquisition and it kind of dodges the question of continuous acq.  It says it is slower, much slower than the 200 khz you can get from finite (til the FIFO fills), but doesn't give any numbers on continuous acq.

I also tried the Generate Serial option and that did speed things up.  The article: "What does the "Generate Serial Only" Checkbox Do"  indicates flattening of execution order of parallel loops, so does that mean the Producer Consumer pattern will wait to finish the acquisition Producer loop before it executes the logging Consumer loop?  Or does it mean that it will alternate iterations of the two loops? 

If it is the former, then no logging gets done until the 90 minute acquisition is done.  If it is the latter then it doesn't make much sense to do separate loops. Anyway, I'll keep working on variations using the Generate Serial Option, thanks.

Mike

[Steve_B]

Hi Mike,

You have some good questions about the interaction between the DAQmx Base driver and the PDA. I am still researching the details of the issue but in the mean time, please try out the VI that I posted. I made a few changes to the VI that you were working with. The VI performs the timing outside of the while loop and it will essentially do an average of the loops per second. This is better because the interrupt data transfer happens in bursts which makes an average more appropriate. If there is an error in the loop, it will now stop the loop and the simple error handler will make the error known. You can try some different configurations such as the number of samples to read from the front panel and you can easily see the effect on the loop rate. Let me know if you are able to find a better loop rate with a different configuration.

[Imaginatics]

Hi Steve,

Thanks for the VI, but I cannot use it. We are using LabVIEW 8.2.1 for this project. If you could save to that I would give it a try.

Mike

[Steve_B]

Hi Mike,

I'm sorry for posting the VI that was saved in LabVIEW 8.5, here is the version for 8.2. Give this a try and see if you are able to find any improvement by changing you samples to read. I was also able to verify that the generate serial only option will completely iterate a loop and then completely iterate the other loop when they are in parallel in LabVIEW. The limitations of the continuous analog input are due to the interrupt data transfer and the ability of the PDA to acknowledge the interrupt. Let me know what you are able to determine with this VI.