Analog read and write with DAQ Assistant block using NI-USB 6215

[MatheusPereiraS]

Dear friends.

I´ve been having problems in my control application using LabView+DAQ NI-USB 6215.

In general, I need to read a analog input, filter this input by a LMS FIR filter and then write this filtered signal in analog output port.

The problem is that my output signal is okay in the window graph (Labview), but wrong in the output port of DAQ. To be more exact, the frequency of my generated signal is wrong, smallest than must be.

I'm setting the input port with the continuous samples mode, at a rate of 2500 Hz, with 1 sample to read for loop iteration. The output port has been configured with an on demand mode.

Somebody knows how to fix it? Maybe the the frequency of my signals were corrupted by the loop iteration time?

[Plínio]

Hello Matheus.

Looking at your code description, I could see that the problem is on the acquisition sampling rate. You setting 2.5KHz for sampling rate and 1 sample to read per loop iteration, it implies your loop should run in theory 2500 times per second, but this is not attainable in a PC running Windows or any conventional OS. 

When you configure so few samples to read you cause overwriting on DAQmx Pc buffer, and then you do not reach the desirable rate. 

Unfortunately it is impossible (or even highly unlikely) to run acquisition like this. Usually when you just want to acquire data and not control anything you should set samples to read 10 times less than sampling rate (that way your loop will run at 10Hz, what is easily attainable for Windows). Refer to the following link to understand how to specify Number of Sample When Continuously Acquiring with NI-DAQmx for LabVIEW.

In your case that you are running a close loop, I would recommend you to run your application maximum at up to 20 Hz. More than it you can experience some delay and jitter (http://www.ni.com/white-paper/3938/en/ - look at Important Terminology and Concepts to understand Jitter).

Configure both analog input and output to On Demand, and set the loop timing using for example a Wait funtion (at least 50ms).

In summary if your application demands this control loop rate, you should look for a Real-time OS to implement it.

If you have any question feel free to post it back here.

[MatheusPereiraS]

Thank you for your tips Plínio.

I can't use a small rate how 20 Hz, because I'm acquiring signals until 500 Hz of frequency. And how I'm working with sound signals (input and output) I need to have more than 2 points im my signal, for this I work with 2500 Hz that gives me a period with 5 points of resolution.

I can't use this wait function block, because it can be setted just for milliseconds wait time, and for my work rate I need a microsecond wait time. I will try to use the timed loop block for this.

I made tests acquiring  signals and generating in different loops, and the rate of 2500 Hz was not a problem to acquire and generate simultaneously. The problem just appears when I need to generate a signal based on my input, the two aren't synchronous.

In my tests I could generate a correct signal with I put the DAQwrite block out of loop and use a sine source. But when I remove this source and conect the filtered signal, that are inside the loop, I can't generate the signal for the error 200802. Do you know why? 

[Plínio]

Hello Matheus

As I said, Windows is not the right OS to run a point-by-point read and write analog task. That's why you are facing this problem. In a analog input task sometimes you could reach that sampling rate, but it does mean you will reach it all the time, Windows is not a deterministic OS. It means that if now your app is running at 2500 Hz if later you open another application in your PC, your app could decrease the rate drastically. But now when you add up to your system analog input and output tasks and processing routines, it will very unlikely to get your app running on this rate in cycle of your loop. Got it?

You can do two things to meet your rate spec. First you can use a Real-time OS to meet this rate spec (http://www.ni.com/white-paper/5423/en/).

Second, if you application specs allows it, you could set your acquisition and generation to buffered, i.e. increase the number of samples to read and number of samples to write, so your loop will run at a lower frequency (a freq that works better for windows).