You can encounter race conditions when reading from and writing to local or global variables in the same application. If you misuse or abuse global and local variables, particularly with array data types, the memory usage of the VI increases and the performance is affected. You can use global and local variables to write VIs efficiently, but use global and local variables as sparingly as possible. Use global and local variables as sparingly as possible. Every local variable that reads the data makes a copy of the data. Here’s a snippet from NI’s “LabVIEW Style Checklist” in the LabVIEW 2011 Help, where I’ve bolded part of the last, disturbing paragraph…Īvoid using local variables when you can use a wire to transfer data. Keep reading to understand more about race conditions and how this game of “telephone” progressed to where we are today. Whoa! Given no context, that last statement is just plain wrong.Īn internal document is one thing, but I’ve also heard this echoed by at least one customer in the past month, and also in an informal conversation here at NI.
Functional global variables are VIs that use loops with uninitialized shift registers to hold global data.
#Local variable labview code
It started earlier this week when I found an NI-internal document that’s used for code reviews, which said… Functional Global VariablesĪ way to avoid race conditions associated with local and global variables is to use functional global variables. The same thing seems to have happened with some information on race conditions and functional global variables in LabVIEW, so I want to try to clear it up. Invariably, the message gets corrupted along the way, and the statement at the end has lost all of its original meaning. Do you know the party game, “telephone”? It’s where a group gets in a circle, and someone whispers a statement to the person next to them, who in turn whispers it to the person next to them, until the message gets all the way around the circle.