How do I create an n-point running average VI?

Question

I've been programming in sequential written languages like C for many years now. I've been using LabVIEW for the last 4 months and am having problems writing an n-point running average VI. It is really bothering me, because this would be really trivial in C or anything else. But for some reason I can't conceive how I would do this in LabVIEW. I used LabVIEW 5 for the bulk of that time, and we just upgraded to LabVIEW 8 last week so I've been learning it. Wow, some pretty big differences between the two but the gist is the same.
I have a 5-point running average subVI written that uses a run-once while loop with shift-registers that keep their value between subsequent VI calls. This works for what I need, but have 2 problems I would like to overcome.
1. I can't have multiple instances of the same subVI in my top-level VI program because the way the shift-registers are keeping their value between subsequent VI calls. I have to make duplicates of the .vi file (i.e., 5_point_running_average.vi, 5_point_running_average_2.vi) in order to keep all the shift registers seperate.
2. I want it to be an n-point running average. Currently I have to jump into the VI and add another shift register to add another point. I often change my sample rate, and thus being able to have a different averaging window is really handy.
So the VI takes 2 inputs:
n - (integer) the number of points to computer the average over.
in - (real) the current data point.
output:
out[i] = (in[i] + in[i-1] + ... + in[i-n-1])/n
I've also thought about the possibility of needing a 3rd input that is "instance" which might help keep variables within the subVI separated and thus not needing separate duplicate files.
In case you are wondering, I'm using a running average to make digital HUDs easy to read. The actual data that I'm recording to file will not be going through the running average function, because as you can see by the output function, there will be a phase shift in the output. At high sample rates, the digital displays can be moving very rapidly and that makes them hard to read.
Other recommendations as to how to make digital displays easy to read to help operators while performing tests? As for instantaneous data smoothing, so to speak. I already make the displays very large if they are critical.
I'm very interested in this n-point running average solution. I've been scratching my head over it for awhile now and am quite stumped on how to approach this in LabVIEW.
Help is very much appreciates,
-nickerbocker

Answer 1

The atomic operations (delete/insert) MUST do the following:
When you insert into array, all higher elements need to be moved up one slot, then the element is inserted.
When you delete from array, the lement needs to be deleted and all higher elements moved down one slot
Both operations involve an array resizing operation and data shuffling in memory.
How can LabVIEW be sure that the memory can be re-used? What if your code would delete one, but insert two at each iteration? It might well be that the LabVIEW compiler properly re-uses the memory in your particular case, but there are no guarantees. A five element array is peanuts. so it would probably be difficult to notice a difference.
You might want to run a benchmark of the different algoritms using a huge buffer.
"First call?" is defined as followes in the online help:
First Call? returns TRUE the first time the VI runs after the first top-level caller starts running, such as when the Run button is clicked or the Run VI method executes. If a second top-level caller calls the VI while the first top-level caller is still running, First Call? does not return TRUE a second time.
It will only be true exactly once during the entire execution of the toplevel VI, only the first time it is called from anywhere.
LabVIEW Champion . Do more with less code and in less time .