Calculating RMS value over a timeperiod works with file #2, but not with file #1

[DIAdem2010RMS]

I have done an current measurement. This measurement file has been read into LabView. I want to calculate the RMS current over multiple contiguous measurements, so I can know the maximum current over a period for 1 minute, 15 minutes, 1 hour, etc.

The VI seems to work with File #2, but when using File #1 the calculated RMS current becomes flat after 90 contiguous measurements. See attachment with the VI. I don't know what is different in file #1 compared to file #2 what causes this problem.

Any idea why this doesn't work with file #1 ?

Using LabView 2012.

[RavensFan]

Not sure why you are talking about files when you are working with data that is stored in graphs.

But graph #1 has less data than graph #2.  So it seems like it would run out of data sooner.

What are you really trying to do here?  One thing I noticed is that it takes a pretty long time for this VI to run.

[DIAdem2010RMS]

The measurement data has been embedded in the VI for this forum question. In the original VI I can open an external file.

File #1 contains indeed less data. When expending the file by copy pasting the measurements after each other the problem with the flat line still exist. Even setting the "Number of samples max" to 30000 gives the same results.

I want to know what the maximum RMS value is for:

1 second of data (1 sample)

2 seconds of data (2 samples)

3 seconds of data (3 samples)

....

3600 seconds of data (3600 samples)

This to calculate the margin there is before the electric circuit breaker will blow.

The results from 90 seconds and further seems not correct for file #1. It can't be stable due the changing current that has measured.

[altenbach]

I would think the problem is in the data. (e.g. if you would reverse the array before processing, it all looks fine)

As I first step you should clean up your code to make debugging easier. Here are some of the problems

• While loop should be FOR loops because you know the number of iterations before the loop starts.
• We have the iteration terminal to get an incrementing value with each iteration.
• Building an array in a feedback node by prepending is much harder on the memory manager. Append at the end and now you don't even need to reverse the array after the loop 😮 Of course an autoindexing output tunnel will build the array for you directly (see image).
• Sorting an array followed buy reversing and indexing out the first element is just "array max". Much cheaper.
• Your sequence structures have no purpose.
• Why are you using dynamic data? Makes no sense here.

Here's a quick rewrite of your code that produces exactly the same result (and is much faster).

Important note: This is a near literal translation of your code. It makes no claims about the sanity of the algorithm!

[altenbach · Accepted solution]

OK , here's the reason you are seeing what you are seeing.

The bad dataset has a strong peak early (around index 80) and since you are doing the pt-by-pt averaging, you get a high RMS value here because you are only averaging the first 80 points. Even if the averaging window is much larger, it has only seen few points at that time of the inner loop. (illustrative demo: change the first point of each dataset to something very high (e.g. 1000) and both results will be a flat line for the same reason) 

You could discard all RMS averages that acted on fewer points than the averaging window, e.g. you could take the appropriate array subset before finding the max. Here's a quick fix. Modify as needed. (there are probably better ways to do all that).

[DIAdem2010RMS]

This works perfect and is indeed much faster!

Dynamic data was comes out of the "Read from Measurement file" VI. I am now changing it to 1D array.