LabVIEW
Create array in a VFG
Hi,
Thank you for all the advice, I didn't quite understand the feedback node. But after me in the FGV, we have always the While loop Right ? Yes you're right for the icone, I'll change.
Since we are in the FGV, do you think it is possible to put notifiers in the FGV? I will try to do it. I have too many wire. Here is just an example
And it allows me to work on the FGV.
@MaSta wrote:
Why is it called a functional global variable? It's neither functional, nor what in terms of LV is a global variable. It's an array in a loop. If you put it into a subVI without the loop, you can access it as a function and store data in it.
That's a long story. Back in the days LabVIEW 2.x (only on Mac OS and around 1990) had no global variables (and yes even LabVIEW 3 didn't have global variables).
Someone at NI (Monnie Anderson) discovered that when you use an uninitialized shift register in a while loop set to only always run once, you could simulate global variables that were very useful. Those were simple read/write globals and the access was controlled with a boolean. Someone duped them LabVEW 2 style globals, probably simply to give the beast a name.
They were used quite often and people found also that they are a perfect way to create race conditions, especially in an inherently parallel environment as LabVIEW, where everything is dataflow controlled.
So instead of (read global, add/subtract/multiply/etc value, store global) sequences all over the place, someone else came up with the idea to replace that read/write boolean with an enum and do the actual operation on the global variable inside the VI, which serves as protection from parallel access to the variable during the read-modify-write sequence.
Some called that LabVIEW 2 style global too, but others wanted a distinguishing name. Two names eventually got fairly common:
- Functional Global Variable
- Intelligent Global Variable
Personally I prefer the second, but they both could be considered adequate but not necessarily perfect names.
And yes, use of the officially available global variable in LabVIEW (since around 5.0 I think) definitely can and often will cause race conditions. Which is why it is frowned upon by a lot of experienced LabVIEW programmers. It should be really only used when you either do a write once, read many times, or if you very stringently control parallel access to it to make sure that there can NEVER EVER be two read-modify-write sequences happening at the same time. For most reasonably complex applications this is not only hard to guarantee but there is always the chance that someone later on goes and adds this "quick tiny little fix" and the race condition is introduced anyways.
@MaSta wrote:
@rolfk wrote:
It should be really only used when you either do a write once, read many times, or if you very stringently control parallel access to it to make sure that there can NEVER EVER be two read-modify-write sequences happening at the same time....which could easily be achieved when putting it into a sub VI.
And then you have a Functional Global Variable, except you replaced the shift register with your global variables, and these global variables are also accessible anywhere in your program and the engineer having to modify your program in a year from now may still not be aware of the potential race conditions and just do his read-increment-write on his own somewhere else.
And except of course if you want to do an add, increment, subtract, multiply, blabla and blublu on that same variable in different places. If you create for each of them a seperate VI there is no protection of the globals from concurrent access anymore. So you have to put it all in the same VI and use an enum as operator selector.
And yes then you have an Intelligent Global Variable, but still with the option to access that global variable elsewhere and mess up everything. 😁
