LabVIEW
Cannot append an array with an element using local variables
Solved!
Hello!
I am kind of new to LabView and i cannot figure out why the element 20 is not appended to my "buffer" but 10 is. Can someone tell me why?
Thanks
@rpdp wrote:
Can someone tell me why?
... because you have race conditions due to mindless overuse of local variables. Your code fragment on the right executes before the fragment on the left, so it first reads the local variable (which probably contains some random value from the previous run or might even be an empty array, appends 20 and writes it back to a local. In the meantime the FOR loop finishes, writes the result to [a}, appends 10, and writes the result to buffer, undoing whatever the code on the right did.
LabVIEW does not execute left to right or care about arrangement of code. Execution order is determined by dataflow, and local variables break dataflow!
Of course you only show us a truncated picture, so we have no idea what else is wrong. We don't even see where the terminal of "buffer" is or if you write to it from other locations. To get better help, always attach the actual VI.
Tell us what you want to achieve with your code and we can give you targeted advice how tho make it better.
Note that although a Sequence Structure solves your problem here, you could also just not use any of your local variables and wire directly between the nodes.
In LabVIEW, dataflow will sequence your program - that is, any given operation won't start until all of the inputs are available, and none of the outputs will become available until the entire operation is finished.
As an example of the latter, consider the following:
Here I have a loop that takes 5 seconds to run, but the probe shows the "Random Number" node finishes as soon as I press run, more or less. However, the front panel indicator remains the default 0 (or whatever it was previously displaying, if you run the VI repeatedly) for 5 seconds and then only updates just before the program finishes, 5 seconds later.
@rpdp wrote:
Thank you. It worked when I put the whole thing in a sequence. I was trying to update the value of the buffer variable along with the flow of the program just like I am used to with python or C.
No you don't solve a problem by adding yet another problem. You need to forget the notion of "variables" is classic programming sense and embrace dataflow. In LabVIEW (simplistically!) "The Wire is the Variable", while controls and indicators are just connections to the front panel (and local variables are basically just duplicate instances of these terminals). A well written program rarely needs sequence structures and local variables, so see if you can improve you code along these guidelines.
As we said, explain what problem you are trying to solve and we'll point you in the right direction. Show us your code! 😄
(It look like you are smart and a fast learner and we can speed up the learning curve by helping you avoid typical beginner mistakes. It is easier to avoid bad practices from the start than to un-learn them later. ;))
@rpdp wrote:
... just like I am used to with python or C.
That's exactly the problem. You are trying to apply text code practices to graphical programming! Once you grasp the full power of LabVIEW, it will poen your eyes. 😉 (I was a seasoned FORTRAN programmer (20+ years!), switched to LabVIEW in 1996, and never looked back 🐵
It seems your "buffer" is just used to store intermediary results. temporary data does not belong on the front panel! (Controls and indicators require their own datacopy, a transfer buffer, and the UI thread and are thus wasteful.)
Typically, we keep temporary data in e.g. shift registers (one of the most powerful LabVIEW tool you should quickly learn!)
Here's is one simple draft. Depending on your requirements, you could eliminate the "buffer" indicator and just wire "a" in it's place.
(In the far(!) future (not now!) you might also start thinking about performance and memory. For example it is inefficient to constantly grow large arrays, especially if you know the final size. It is more efficient to keep the number of expensive new memory allocations to a minimum)
