Concurrent Wait Time Issue to Generate Rate of Change Measurements

[dclalonde]

Hi,

I am a basic user (Edit: using LabView 2014) and have been trying to correct what I assume is a fairly simple misconception about how to perform two or more concurrent rate of change measurements using the VI shown below. The issue I am running into is the output is syncing to the longest time lapse period and they are not running independently. Any advice and suggestions are welcome!

[CyGa]

Hi,

Your main loop MUST wait that the other 2 loops finished executing before looping again. So yes, here it will wait a multiple of 5s before analyzing new data coming from your DAQ board.

The other thing that I notice is that all your loops are stopping after 1 loop because of the True value on their stop condition.

What do you want to do exactly ? Continuously acquire a signal and get deltas within 1 and 5 sec slots ?

[RavensFan]

Also, your DAQ assistant determines what is the timing being your data points.  Your delays in the loop are only going to affect how long it takes to display the data that has already been received.

[Ben]

Have you tried to watch your code in execution highlighting mode?

It would show you when the data is being read and ...

Ben

[dclalonde]

Yes, the intent is to continuously acquire data that I can use to perform a simple rate of change math on but it needs to be modular so I can apply it to thermocouples or transducers as well as being able to change the time delta to upwards of 30 minutes which is why I do not necessarily want to fill up lots of different arrays.

I understand the stop condition was in the wrong position when I screen grabbed it.

[dclalonde]

---

@RavensFan wrote:

Also, your DAQ assistant determines what is the timing being your data points.  Your delays in the loop are only going to affect how long it takes to display the data that has already been received.

---

This is a test VI that will be inserted into a much larger VI with the timing on the DAQ being set by other requirements and need the timing with respect to the rate of change to function independently. I need the displayed data in real time so the operator can make an assessment of a stabilization criteria which they will have to compare different time periods.

[RavensFan · Accepted solution]

Do you want your "30 minutes ago" to always be 30 minutes ago from now?, or every 30 minutes it stores a value and then updates that after another 30 minutes has passed.

If the former, then you will need to store arrays of data.  What you are doing is called a circular buffer where you continually add new data and discard the oldest, and the size of the buffer determines how far back in time you can look.

You need your data acquisition to run continuously at whatever data rate makes sense.  You don't want your analysis of that data to be delayed by arbitrary "wait until next msec" functions.

[dclalonde]

---

@Ben wrote:

Have you tried to watch your code in execution highlighting mode?

It would show you when the data is being read and ...

Ben

---

I tried this and I understand the problem because I watch when the outputs of my indicators release. I have also tried Timed Loops and a variety of nesting conditions to fit this to my needs. 

[JÞB · Accepted solution]

Interesting problem

Lets start with the DAQmx Configuration.  I have the following config on a simulated USB 6221 ao0

By using a pair of Feedback nodes The task is easily accomplished thusly:

Now, if you need an nZ transform node we can look into the PtbyPt vis and calculate a delay for This fine function

and simply take the delta between input data and eliminated data

[dclalonde]

---

@RavensFan wrote:

Do you want your "30 minutes ago" to always be 30 minutes ago from now?, or every 30 minutes it stores a value and then updates that after another 30 minutes has passed.

If the former, then you will need to store arrays of data.  What you are doing is called a circular buffer where you continually add new data and discard the oldest, and the size of the buffer determines how far back in time you can look.

You need your data acquisition to run continuously at whatever data rate makes sense.  You don't want your analysis of that data to be delayed by arbitrary "wait until next msec" functions.

---

Thank you. I will redesign this to use arrays. Based on others experience, what size and quantity of 1D arrays typically start burdening the computer system running LabView (assume average processing power and RAM).