Would this be an advisable way to take a running average for a large sample set?

[Patrick H.]

First off, I don't know if it is working properly, would someone be able to verify that it is actually taking a running/moving average for 5 points at a time.

Second, will this slow down my program with a an array of about 10k numbers? Is there a better way?

When I run it with the "light bulb" it seems to work and it is displaying a graph that looks similar to the graph without the loop added, but since there is very little noise in the graph originally and I have no other sample data to use, I can't tell for sure.

SEE ATTACHED

I apologize for the sloppy wiring. I was trying to mock it up quickly before I had to leave.

Thanks

Patrick

[GovBob]

Patrick,

 Have you looked at the Mean Pt by Pt.vi under the signal processing pallette? It might be what you are looking to do.

hope this helps.

[Patrick H.]

Thank you for the reply,

I saw something about that, but I wasn't quite sure what was happening in it. I will research it more to see if it is the route to go.

I also forgot to add a reverse 1D array outside of the loop. Without it, it outputs backwards.

[johnsold]

The Pt by Pt VIs can be opened, so just look at the block diagram.  Generally they build an array of data internally.

If you never will want more than 5 points in your moving average, just expand the left terminals of the shift register down until you have 5 points.  Feed the data in by autoindexing over the array.  Add the five points and divide by 5.

Lynn

[altenbach]

---

@Patrick H. wrote:

Is there a better way?

---

Mean ptbypt is probably want you want. For details, have a look at my example posted here. I am sure it can be adapted to your secnario. (Remove the chart and put the core code in a FOR loop and replace the "dice" with the data from the autoindexing input, for example).

Your code picture raises quite a few flaming red flags and you are well advised to correct them, especially if you want to operate on large amounts of data:

• Your outer while loop acts like a FOR loop with a defined number of iterations. Replace it with a FOR loop so the compiler can correctly allocate the autoidenxing output arrays when the loop starts. Autoindexing tunnels on while loops don't have that advantage.
• Your small inner while loop has the same problem. Memory thrashing is even more severe because you constantly resize the array in the shift register, forcing a new memory allocation with each iteration of the loop. A much better "in-place" solution can be adapted from my example quoted above. I would bet it will be several orders of magnitude faster and memory efficient for large arrays.
• The wire gong to the lower "array size" primitive is hidden. Where is the source? I am guessing it is the outside array, so why do you think you need to measure the size with every iteration? Since it does not change, that primitive belongs outside the loop. (Well, the compiler can probably identify it as loop invariant code and treat it as such, still it makes the code confusing). As you can see, it is impossible to fully understand a code image if the diagram is not clean, feel free to post the actual VI instead.
• What also worries me is the size of the vertical scrollbar handle. Is the diagram really 6 screens high? 😮
• I am also worried about the fact that there is not a single terminal in sight. All we see are value property nodes and local variables. This is also a performance issue because local variable cause extra data copies in memory and value property nodes need to execute synchronously.

[Patrick H.]

altenbach,

I will try to address all of your issues, most of which stem from me not being able to post the whole vi.

1.) I will most certainly try to adapt the Mean ptbypt example you have provided.

2.) I did not write most of this code, I am just working on details of it like the moving average and thing like that so I can not speak for the outer main while loop. But I will pass along what you said to who wrote it originally. The inner while loop was the way I thought up to have it work. Again, by adapting your example to fit my needs should get rid of this.

3.) The lower array is sourced from the same one above in the shift register, it was wired and resized and sloppy print screen resulted.

4.) Since it is a proprietary code I cannot post the whole vi (sorry) and it really is that big. It is a huge program and it is broken up into many subvi's already. My colleague and I are brand new to Labview (as of January) and we have been assigned to take this whole program head on with reference only to here and another colleague who does not work in this office and most of our contact is via email (painfully slow).

5.) The property nodes and local variables are in the process of being cleaned up. I spotted this when I got the code and will work on cleaning that issue up too.

Thanks for you help and I will try to adapt your solution tomorrow and report back.

[Patrick H.]

altenbach,

Is there a way of putting it into a graph instead of a chart? We need it in a still graph. I have been messing around with it for a while and haven't figured out a way to have just the "x" value, raw "y", and averaged "y" on a graph. Is it possible? Should I not give up on it yet?

[altenbach · Accepted solution]

---

@Patrick H. wrote:

Should I not give up on it yet?

---

Never give up! Here's a 2 minute rewrite, comaring the "mean ptbypt" with an explicit version.

[Patrick H.]

Thank you. I was trying to built the array and not doing it properly. I don't know if I had the indexing wrong when I tried it or not but it did not accept the format of the input into the graph. I appreciate the rewrite and apologize for my ignorance to all that Labview can do.