Resetting an indicator back to zero after each loop

[Thesoothsayer]

Hi guys, I'm trying to get the inliers indicator to reset itself after each loop. Currently, it does not reset and every time I initialize it, the number of inliers will add on to the number of inliers in the previous loop. I've seen threads regarding this and some people suggest using local variables and invoke node. However, invoke node seems to cause all of my readings to reset, which I do not want and I am unsure of where to place the local variable. Recently just started using LabVIEW and I am really new to all of this. Thank you.

[altenbach]

An indicator updates whenever you write to it with whatever data is in the wire. It does not "add" anything from the previous loop. If you see that kind of data, the problem is the data in the wire, i.e. the result of the calculation. Unfortunately, you only show a small section of the program. can you show the entire code, maybe attach the VI. Do you have any shift registers or feedback nodes?

(Local variable, value properties, or invoke nodes won't help you here. You don't even say what "invoke node you were trying.)

[Thesoothsayer]

Sorry, I do not recall which invoke node it was. However I do know that it resets all the readings and controls of the VI. Here's the VI. It is very messy but what it is supposed to do is randomly generate 2 coordinates and use those to construct a best fit line while it uses a random coordinate to check with to see if it is within the distance threshold. If it is, it will be considered as an inlier. I do not have any feedback nodes or local variables in my program. 

[altenbach]

Your program spends about 2 seconds in one of the inner loops, so until that has completed, your indicator in question will show the value from the previous iteration of the outer FOR loop.

Overall, your code is overly complicated with pointless operations. You generate a lot of data just to throw most of it away a nanosecond later. The entire thing could be done with code the size of a postcard.

(If you attach code, make sure that all controls have reasonable default data so we can test without having to guess what the inputs should be.)

[Thesoothsayer]

Thank you for the feedback and sorry for the controls. May I ask how could I have done the program better? I agree with how overly complicated it is but I am unsure of what I can do to make it less complicated.  

[cbutcher]

Even without changing anything, here is a copy of your VI with some whitespace removed. It fits on a 4k screen now 🙂

You also use a set of operations over and over again to randomise the order of your arrays - you could make a SubVI doing this (the Edit > Create SubVI menu option should work for this) and that would remove lots of the same code and give you just one place to have to edit if you wanted to change something.

[jwscs]

one example

sorry... the remark about the "Array" is wrong,

you get either the first element or 0 (because the index you want to access is SIZE of input == out of bounds)

[Thesoothsayer]

Alright. Thank you for your help, I appreciate it!

[altenbach]

Your math is even wrong. If you round to nearest, there is a nonzero chance that you trying to index out an element that does not exist. Also the fist and last element of the array has only 50% of the probability of all others to be picked.  You need to round to -inf. Currently, you get a biased distribution and an overabundance of zeroes (that might not even be in the original array).

A FOR loop with 1 iteration does not really do any looping. most of the FOR loops can be deleted without any change in functionality. The two big inner FOR loops could be combined into one.

How big are the input arrays? What are their values? Why are the some array control terminal inside the inner loop? Is there a chance the can change during these loops? It would be much more efficient if the terminal does not need to be read with every iteration of the inner loop. Why do you rewrite the plot properties with every iteration of the loop? Properties only need to be written if the differ from the previous state. Since your loop takes over 2 seconds, changing e.g. the interpolation will apply with significant lag. Not a good UI. If this feature is important to you, do it in a parallel loop and an event structure so it can act instantly at any time needed.

None of your formula nodes seem useful. Operations on coordinates are often much easier using complex datatypes. Try it!