LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

speed up DAQmx with cRIO

Hello,

 

I have been working on communication with an analog input card (NI cRIO 9215) and output card (NI 9269) each plugged into a separate cDAQ-9171.  Ultimately, my goal is to have two analog inputs and one analog output, where the analog output is controlled through the inputs.  Currently, I have it setup so that a MATLAB script controls the output relative to the inputs, but that is subject to change.

 

When I simply have the analog input directly routed to the output, there is a ~80 ms delay (with the MATLAB script, ~70 ms without) between the input rising edge and the output rising edge. To perform this test, I put a 1 Hz square wave on my input and measured the analog output relative to this input, as shown below:

 

try5and6.png

 

In testing this, I have been referring to the following thread: http://forums.ni.com/t5/LabVIEW/How-to-speed-up-DAQmx-operations/td-p/1061881/highlight/true and references therein.  However, nothing seems to speed things up considerably.  If I can get to the point where the MATLAB script is the main hangup, then I would be quite pleased.  The .vi files (with and without the MATLAB scripts, tries 5 and 6, respectively) I have been using are attached.  I have also played with the clock (with very little success) and the input sample rate and number, but the best parameters for these are not obvious to me.

 

My question is, is there something silly that I'm missing that could improve the performance of this .vi?  It seems very slow, but I am not super familar with the particulars of these devices.

 

Thank you for your time!

 

Best,

 

Carrie

Download All
0 Kudos
Message 1 of 14
(3,451 Views)

First of all, you do not have a cRIO here.  You have a cDAQ system.  There is a huge difference.

 

Now to your issue.

So you have the DAQ set up to sample at 1kS/s and you are reading 100 samples per loop.  So a single iteration will be 100ms.  Therefore, I would expect a 100ms delay between your input and your output.

 

What kind of delay are you wanting?  What processing are you wanting to do with the Matlab node?  You may actually need a cRIO to do this properly.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 14
(3,444 Views)

@cweidner0 wrote:

Hello,

 

...  It seems very slow, but I am not super familar with the particulars of these devices.

 

Thank you for your time!

 

Best,

 

Carrie


I suspect the proper term to understand your concern is " high latency" indicating th delay between the stimulus changing state on the input and the time required to get the measurement from the hardware and move it to the LV code and then passing out to the output.

 

If you need very low latency then you will have to sample single point values as fast as the data is acquired and update the output once for each measurements. Depending on how often the inputs should be measured and the output updated, you may have to move to RT or cRIO as ws mentioned previously.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 14
(3,428 Views)

 

 

@crossrulz wrote:

First of all, you do not have a cRIO here.  You have a cDAQ system.  There is a huge difference.

 

Okay, fair enough.

 

Now to your issue.

So you have the DAQ set up to sample at 1kS/s and you are reading 100 samples per loop.  So a single iteration will be 100ms.  Therefore, I would expect a 100ms delay between your input and your output.

 

If I, say, decrease my number of samples to 5, the delay is still about 70-80 ms (without MATLAB).  As I said, I've played with the timing sample rate and samples per loop and had very little luck in terms of being able to find the optimal values.  Part of my problem is that there is obviously something here I'm not understanding in terms of timing and buffering.  I'm not an expert in the slightest (hence my misuse of language, etc.) but it does seem that I am hardware limited.  I suppose I just wanted to confirm this.

 

>What kind of delay are you wanting?  What processing are you wanting to do with the Matlab node?  You may actually need a cRIO to do this properly.

 

This is going to end up being a PI controller at a reasonably low bandwidth (~1 Hz), so I don't NEED more than what I have to make something work, although being able to use a single-point sample would have been nice.  It seems that this is not supported with the hardware I am using, though. This was more a question of curiosity as to what was limiting me.  The MATLAB node is likely not necessary and can be removed.

 

0 Kudos
Message 4 of 14
(3,413 Views)

 

If you need very low latency then you will have to sample single point values as fast as the data is acquired and update the output once for each measurements. Depending on how often the inputs should be measured and the output updated, you may have to move to RT or cRIO as ws mentioned previously.

 


I figured that my issue was hardware limited.  Because of cost, etc, I am stuck with what I have and have to make this system work as well as possible in the face of its limitations.  Thankfully, I only need very low bandwidth (about 1 Hz).  I was just curious what was limiting me.

0 Kudos
Message 5 of 14
(3,412 Views)
I have done 10 hertz updates of PID loops for multiple IO systems 4 years using Hardware like that in a Windows environment.
What you all have to do is change your architecture and set up a continuous data acquisition and read the backlog continuously as your feedback element for your PI control Loop.
Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 14
(3,403 Views)

Hi Ben,

 

Could you clarify how one would implement this?  Alternatively (or additionally), can you provide some resources that I can refer to in attempting this task?  My LabVIEW knowledge is limited in this realm, and thus I don't know where to begin.

 

I appreciate your help.  Thanks.

 

Best,

 

Carrie

0 Kudos
Message 7 of 14
(3,400 Views)

I think you will want to start with a Producer/Consumer.  The idea is that the Analog Input is read in one loop and sent to another loop via a queue.  The second loop does the processing and writing to the analog output.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 8 of 14
(3,394 Views)

@crossrulz wrote:

I think you will want to start with a Producer/Consumer.  The idea is that the Analog Input is read in one loop and sent to another loop via a queue.  The second loop does the processing and writing to the analog output.


Based on your reply (endorsed by Ben's kudos), I used a couple of NI examples and some documentation to try and come up with a solution.  The sample code that I pulled this from is Cont Acq Producer Consumer to File.vi found here:https://decibel.ni.com/content/docs/DOC-2431

 

I think that I'm on the right track, but I am seeing Error -200294: Not enough samples were written to satisfy the initial data transfer request condition.  I have played a bit with DAQmx Configure Output Buffer.vi, but the error still shows up.  I suspect my issue has to do with timing, but I am not knowledgeable enough to know how to correct for it.  The input (producer side of things) appears to be working, but the consumer is not.  Based on the order of operations when execution is highlighted, it appears that the consumer loop is running before the producer loop has produced its first set of data.  Other than implementing a "wait" function, I'm not sure how to handle this.

 

The .vi is attached.

 

Thank you for your help.

 

-C

0 Kudos
Message 9 of 14
(3,363 Views)

You don't need the timeout for the Dequeue Element.  That is likely what is causing your problem.  When a timeout happens, the queue will output an empty array, which is not enough data to write out of the analog output.

 

You also have the issue of the consumer loop has no real way of stopping other than a DAQmx error.  What I recommend there is to send an empty array when the producer loop is complete.  The consumer can then use the Empty Array? function to look for that condition and stop the loop.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 10 of 14
(3,351 Views)