Acquisition speed problem - cDAQ9188XT

[ErwanHut]

Hello,

I need your help because I have a problem of too slow acquisition in my project that  I do not know how resolve.
Basically I realized that my program was not running fast enough and digging I found that it was because of my acquisition vi.
Acquisition speed / loop is limited to 772-773ms for each iteration, while I would reach at least 100ms.

To reduce at minimum other task to do here is  what I did:

and what I get :

* For 2305.63 result ... I had nothing connected but the values with wire are good, the problem is not coming from here.

I am still very novice with DAQmx tasks (I wanted to learn to do without the DAQ Assistant, which itself puts 2800 ms loop ...) so there may be mistakes but I do not know where ...

I acquire only temperature on a NI-9213 module that should not have problems to keep up! And I request one sample on demand. (In the future clocked by a loop to 100ms between each iteration).

To create the "task" refnum, I converted my old DAQ assist into a task ! Maybe it comes from here -> 2.0 DAQ assistant in the project
I also changed computer, I get exactly the same result, so the problem comes from my code / configuration ....

The project is not executable because I put a while loop in the sub vi acquisition.vi to identify the problem.

The test vi is called test-speed.vi and the refnum task : assistant DAQ 2.0, be sure to select on the front panel before launching the execution, although I doubt that without the smae DAQ - module , execution starts ^^

Moreover, by replacing in the overall project, the acquisition by simulation, it runs almost perfectly!

I hope I was clear enough, as usual, feel free to tell me if I had to explain more !

I can't not find a solution at this time, would you have any idea?

Thank you very much !

Erwan

PS: feel free to criticize any bad things you see in my whole project if you see something really bad !

PS2: i just notice that with only ONE temperature on the ni 9213 my loop is 163ms ..

[Daikataro]

Greetings! It seems to me your problem is the acquisition rate and the amount of samples to be read. Exactly what you want to do with those samples? How many samples you need, and how often you need them? The slow is related to the "sample on demand" since it has to start the read, wait for the buffer to fill, read the sample and deliver. Instead I would advice to use a read property node, with offset relative to most recent sample. Watch this video, very informative.

https://www.youtube.com/watch?v=0Gjs6TD8Zn8

[_Bryan · Accepted solution]

Look at the specs on page 6.  The 9213 has 2 modes, high-resolution and high-speed.  It also has an auto zero option.

http://www.ni.com/pdf/manuals/374916a_02.pdf

When you setup the task there should be a device tab that has the auto zero mode and adc timing mode.  Change the timing mode to high-speed and the auto zero to once or none and see if that speeds things up for you.  But there are some takeoff's with accuracy.

Reading 14 channels I was getting about a 300 ms iteration time using a DAQmx task.  I have found that with using the 9188 some modules are not as fast as I would like.  You can run your thermocouples in a separate loop and pass the data to your main vi when it is available.

[ErwanHut]

Hi !

Thank you both of you for your answer ! Really appreciate !

---

Daikataro a écrit :

Greetings! It seems to me your problem is the acquisition rate and the amount of samples to be read. Exactly what you want to do with those samples? How many samples you need, and how often you need them? The slow is related to the "sample on demand" since it has to start the read, wait for the buffer to fill, read the sample and deliver. Instead I would advice to use a read property node, with offset relative to most recent sample. Watch this video, very informative.

https://www.youtube.com/watch?v=0Gjs6TD8Zn8

---

Sorry to be not enough precise on my goal !
I need to acquire at 10Hz, make some really basic calculs but really important one and then at the same time i acquire, so in "real-time / live" display those result on my front panel at the same rate : 10Hz. I just have one waveform, all the other are numéric indicators, that's why i choose "one sample on demand". And in my head, making a while loop that demand one sample for 20 measures ( hoping that it takes less than 100ms ) and clocked 100ms this loop is really clear to make an acquisition at 10Hz .
In parallel i need to save those datas on a file, i used a queue and another loop (and an other loop for acquisition and an other for displaying).

So, i though that i will wait the DAQ to acquire every sample (one per channel) and i though it will take far less than 100ms, maybe 50ms, i'll wait 50ms remaining and send the data to the other loop before redoing the routine. Am I wrong ?

Look at the specs on page 6.  The 9213 has 2 modes, high-resolution and high-speed.  It also has an auto zero option.

http://www.ni.com/pdf/manuals/374916a_02.pdf

When you setup the task there should be a device tab that has the auto zero mode and adc timing mode.  Change the timing mode to high-speed and the auto zero to once or none and see if that speeds things up for you.  But there are some takeoff's with accuracy.

Indeed, I also read this, but i have absolutely no idea how to set up the high speed, what vi daqmx i have to use ? I guess it's directly into the task, maybe a property i did not see ?

Thank you very much for your help 

Erwan

[Daikataro]

So, is the 10Hz acquisition really vital? Or just how fast you want to get the samples? Because it would be impossible to get one sample per 20 measures in less than 100 ms at said rate. 10Hz means 10 samples per second, or 2 seconds to get 20 samples. What I would suggest is setting the sample rate to 1kHz, 1k samples to read at continuous samples mode, and using a read property node to ask for the most recent sample every 100ms, something like this

Basically you just allow the DAQ to sample at a higher rate than needed, and take advantage of the buffer so it does the heavy lifting for you, and just call it when you need it. Don't mind the stacked frame much, it's just a small delay to allow the buffer to fill before reading info, since it returns an error otherwise.

[_Bryan]

Here is where the settings are.  It is the same if you use  DAQmx or the DAQ Assistant.  It would do good to get away from using the assistant in the future.  You can also right click on the DAQ Assistant and select generate code once it has been configured.

[ErwanHut]

---

Daikataro a écrit :

So, is the 10Hz acquisition really vital? Or just how fast you want to get the samples? Because it would be impossible to get one sample per 20 measures in less than 100 ms at said rate. 10Hz means 10 samples per second, or 2 seconds to get 20 samples.

---

I would like to have, every 100ms all the 20 channels, one data per channel :

100 ms data1 data2 ..... data 20

200 ms data1 data2 ..... data 20

300 ms data1 data2 ..... data 20

Maybe i'm wrong, but i though 10Hz is 10 samples per second but for EACH channel ... 

---

Daikataro a écrit :

What I would suggest is setting the sample rate to 1kHz, 1k samples to read at continuous samples mode, and using a read property node to ask for the most recent sample every 100ms, something like this

Basically you just allow the DAQ to sample at a higher rate than needed, and take advantage of the buffer so it does the heavy lifting for you, and just call it when you need it. 

---

It seems very tricky but should work i guess, i'll try it as soon as i can. Thank you for the great idea ! But what i did not truly understand is, currently i do not see how i'm limited to 772ms per loop and how acquiring at 1kHz will be possible.
In my head, currently the acquisition go as fast as it can to catch only one sample for the 20 channels but is not able to go less than 772ms ... so 1khz will impossible ... i'm a little confuse but i will try to see and understand.

---

Daikataro a écrit :

Don't mind the stacked frame much, it's just a small delay to allow the buffer to fill before reading info, since it returns an error otherwise.

---

The delay seems big .. but i will trust you.

Thank you Bryan too ! Really help !

I'll try it as soon as i can and come back.

Thank you very much both of you !

Erwan

[Daikataro]

Oh I didn't get the before, yeah no matter how many channels, your DAQ will acquire data at the same rate from all of them, whether you ask for 1 or all channels. The one I have virtualized only has 16 channels but the principle is the same. You can easily acquire 1 sample per 100ms if you just ask for 1 at a time. You can generate this very same code with the assistant by selecting:

-Sample mode as continuous samples

-Samples to read to 1

-Sample rate at 10Hz

Then just right-click assistant and select "generate DAQ-mx code". Make sure to change the indicator to a 2D double array.

EDIT:

Don't mind the delay too much, it only does it one time before the main loop, and is only necessary when using the read property node and asking for past samples.

[ErwanHut]

Hello !

The first thing i tried was to set my acquisition card to High-speed instead of High resolution, and, with just this simple setting, i'm able to record 14 channels, one sample on demand, every 16ms ... quite impressive ... and strange against the datasheet ... but works fine for me, so i think it's okay.
Thank you _Bryan !

I did not try your solution Daikataro but i will, just to understand the process 

Thank you for the help !