LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Averaging of each element of array

Solved!
Go to solution

@msabah38 wrote:

Could you please downgrade the array averaging_MODCA2.vi ‏15 KB  VI to LV.2015


Done. Please download it again.

0 Kudos
Message 11 of 33
(1,921 Views)

wiebe@CARYA wrote:

@altenbach wrote:

wiebe@CARYA wrote:
The for loop will average all channel data, as if it was a single channel.

 


... unless we use a parallel FOR loop with a sufficient number of instances. 😄


should that work?

wiebeCARYA_0-1654269671145.png

It still seems to use 1 instance of the PtPyPt VI?

 

I'd expect 0,1,2,3,4,5,6,7,8,9, but I get 0, .5, 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5.


Form remembering older discussions and from plain logic, I thought it should. I guess it does not!

(even playing with the chunk size does not help)

 

altenbach_0-1654272703118.png

 

0 Kudos
Message 12 of 33
(1,920 Views)
Solution
Accepted by topic author msabah38

To wrap this up, I would probably wrap (sic) the exponential filter into a reentrant subVI containing a feedback node. The global initialization will also eliminate the "first call?" primitive.

 

altenbach_0-1654274076926.png

 

NOTE: depending how dirty your data is, you might need to protect from damaging values (NaN, Inf, -Inf) and from situations where the array size changes during the run. All this would simply need a little bit more handling inside the subVI.

 

 

Message 13 of 33
(1,913 Views)

@altenbach wrote:
(even playing with the chunk size does not help)

It gets slightly better if we place a small wait inside the loop (I guess if the iterations are low and the loop is greedy, the compiler decides against using more than one instance).

 

 

altenbach_0-1654276069026.png

 

 

So yes, this does not work.

 

Of course we could place a case structure wired to I with N identical cases. Then it would work with or without parallelization. Not really a simplication, though. 😄

 

altenbach_1-1654276407042.png

 

Message 14 of 33
(1,902 Views)

Well, Ive always wanted to clean that up anyhow.  And found a little time

 

Use this (Bugs not included)

Snip 2021.png


"Should be" isn't "Is" -Jay
Message 15 of 33
(1,886 Views)

Previous attachment in 2019

attached here in 2015

Capture.pngCapture1.png

VI properties are set per PtbyPt lvlib standards and I even hooked up the help tags


"Should be" isn't "Is" -Jay
0 Kudos
Message 16 of 33
(1,884 Views)

As it turned out the vi could be vastly simplified with better results

(Dang, I wrote a bug too!)


"Should be" isn't "Is" -Jay
Message 17 of 33
(1,871 Views)

@JÞB wrote:

As it turned out the vi could be vastly simplified with better results




I used the vi Means_PtbyPt.vi ‏27 KB in my program, but the results are not getting updated. I have attached my VI. Can you please tell where I am going wrong.

0 Kudos
Message 18 of 33
(1,808 Views)

@msabah38 wrote:




I used the vi Means_PtbyPt.vi ‏27 KB in my program, but the results are not getting updated. I have attached my VI. Can you please tell where I am going wrong.


(I am not going to troubleshoot an unknown, untested subVI, but maybe it is buggy.)

 

I really think your approach is not reasonable! Why would you even do it that way?

 

So you are reading a local variables (that gets updates every ms!) every 100ms, meaning that you are only averaging 1% of the data, then you are trying to average 100 of these 1% points, so your sparse averaging time is 10 seconds!

 

Just use my solution and run with it!

0 Kudos
Message 19 of 33
(1,786 Views)

Here's how I would write an N-point averager subVI (For simplicity, the averaging resets whenever the array size or the history length changes. Please verify correct information.

 

Note that this is very efficient because it just maintains the sum and adds the new values while subtracting the oldest.

 

altenbach_0-1654529721072.png

 

 

 

Message 20 of 33
(1,779 Views)