LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Fast calculation loop with slow output loop

Hi,

 

I'm trying to develop a VI containing a fast timed loop doing some internal calculations and a DAQ Assistant to output one of those values to an NI9263 in a cDAQ9188 chassis.  I'm having problems with the output step slowing down the loop. 

 

I've attached examples of some of the things I've tried, with a much simplified model in the fast timed loop (there's more in my loop, but it's not relevant to the question):

  • with the DAQ Assist in a separate while loop, directly connected - the DAQ Assist never runs;
  • using a queue with the DAQ Assist in a separate while loop - if the queue length isn't limited, the fast loop runs quickly but the DAQ Assist output lags as data comes out of the FIFO queue.  If I limit the queue to single length (as in the attachment), the fast loop fills the queue and waits for it to be emptied (I assume), so runs at the same rate as the DAQ Assist.

I've also tried including the DAQ Assist in the main loop (which slows it down) and in an internal while loop with a timed execution (faster, but it's noticeably slows on the output steps).

 

I think what I really want is a LIFO queue, or a single length queue that drops previous value when full.  Are either of those possible?  Is there something else I should be doing?

 

Sorry - this is my first VI.  If I'm making silly design decisions, suggestions for alternatives would be most welcome too.

 

Thank you, Paul

0 Kudos
Message 1 of 6
(3,306 Views)

Before trying anything else, learn how to program DAQmx properly. DAQ Assistant is not an efficient approach, good for slow tasks and prototyping, but not for serious applications.

http://www.ni.com/product-documentation/5434/en/

Message 2 of 6
(3,293 Views)

EngineerPaul wrote:  or a single length queue that drops previous value when full.

If you only care about the latest value being written to your analog output, then the options I would consider (in no particular order) would be a Global Variable, Notifier, or a Channel (if you have LabVIEW 2016).

 

However, from what I am seeing in your code, you would be better off with a cRIO and let the FPGA do all of this work.


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 3 of 6
(3,291 Views)

In addition to the sources that Blokk indicates, my all-time favorite (which isn't on his list, don't know why) is Learn 10 Functions in NI-DAQmx ..., which clearly shows you how to go beyond the DAQ Assistant and simplify, speed up, and rationalize your DAQ code.

 

Bob Schor

Message 4 of 6
(3,277 Views)

Thank you all for the suggestions.

 

A cRIO would be lovely but, sadly, I have to make do with what I have - I'm only developing something to control some lab test equipment for a short-term test campaign: the budget is limited and the timescales are short.

 

Thank you for the suggested reading - I'm make time to read those, and continue working through the core courses.

 

I'm certain that any one of the suggested solutions would have worked.  In the end, I discovered the lossy queue block, so I've used that with a single element queue.  Almost certainly not the most elegant or efficient solution, but sufficient for my test rig, I think.

 

Once again, many thanks!  Paul

0 Kudos
Message 5 of 6
(3,236 Views)

@EngineerPaul wrote:

 

A cRIO would be lovely but, sadly, I have to make do with what I have - I'm only developing something to control some lab test equipment for a short-term test campaign: the budget is limited and the timescales are short.


Being the engineer I'm sure I'm preaching to the choir, but that reminds me of a modified conversation I have with management.

 

Stable

Short timeline

Low Cost

...

Now pick two.

0 Kudos
Message 6 of 6
(3,227 Views)