Why do LabVIEW Example Projects use Global Variables?

[Bob_Schor]

I'm puzzled.  I've been to enough talks by good LabVIEW programmers (including some who work for NI) and have come away with the impression that Global Variables should, in general, be avoided, with Functional Global Variables (a.k.a. VI Globals) usually preferred for "local memory".

I've been studying some of the Example Projects distributed with LabVIEW 2012 and 2013, in particular the Real-Time Acquisition project, and am struck by the use of Global Variables, where I would be inclined to use an FGV instead.  For examples, to stop all of the loops on the RT Target, the Global "All RT Loop Stop" is set; Configuration "constants" (such as TimeOuts, Network Streme names, Log Folder names) are kept as Globals; the Network Streme endpoints are saved in Globals.

[Note -- there's a funny spelling to the second word of Network Streme, above -- when I tried to post with the correct spelling, I got an error message saying that word is "not permitted in this community".  I apologize for the infraction, but I must confess I don't understand what is wrong with using the correct spelling of that word ...]

Why use Globals in these instances, instead of writing a bunch of VIGs to hold these data?  Note that almost all of these Globals are "Read Mainly" (written once when a resource is acquired, for example) or "Read Only" (treated as though they were a constant).  Indeed, the Read-Only variables could be written as a sub-VI with only an output terminal, acting as a (visible, because of the icon) Constant.

I can see some advantages to this latter approach.  For one, VIGs can have Error terminals, which enforce Data Flow (I just spotted a "data-flow" bug in some code I'm developing that is based on this Template, namely reading configuration data from an XML file into a Global and, in the same VI, wiring that Global to a "use-me" terminal, but with no guarantee that I'll read the Global after I write it).

There is, I suppose, an issue of "speed" -- perhaps Global Variables are "faster" than VIGs (particularly if the VIG "sits" on an Error Line).  My thought, though, is that this difference is likely to be trivial, particularly as these VIGs (or Globals) tend to get "occasional" calls (except for the "All Loop Stop" flag that gets called once per loop).

Are there other arguments or considerations that make a Global Variable a better choice than a VIG?  Is there a reason that the LabVIEW Developers put them in these Getting Started with LabVIEW Projects?

BS

[billko]

---

@Bob_Schor wrote:

I'm puzzled.  I've been to enough talks by good LabVIEW programmers (including some who work for NI) and have come away with the impression that Global Variables should, in general, be avoided, with Functional Global Variables (a.k.a. VI Globals) usually preferred for "local memory".

I've been studying some of the Example Projects distributed with LabVIEW 2012 and 2013, in particular the Real-Time Acquisition project, and am struck by the use of Global Variables, where I would be inclined to use an FGV instead.  For examples, to stop all of the loops on the RT Target, the Global "All RT Loop Stop" is set; Configuration "constants" (such as TimeOuts, Network Streme names, Log Folder names) are kept as Globals; the Network Streme endpoints are saved in Globals.

[Note -- there's a funny spelling to the second word of Network Streme, above -- when I tried to post with the correct spelling, I got an error message saying that word is "not permitted in this community".  I apologize for the infraction, but I must confess I don't understand what is wrong with using the correct spelling of that word ...]

Why use Globals in these instances, instead of writing a bunch of VIGs to hold these data?  Note that almost all of these Globals are "Read Mainly" (written once when a resource is acquired, for example) or "Read Only" (treated as though they were a constant).  Indeed, the Read-Only variables could be written as a sub-VI with only an output terminal, acting as a (visible, because of the icon) Constant.

I can see some advantages to this latter approach.  For one, VIGs can have Error terminals, which enforce Data Flow (I just spotted a "data-flow" bug in some code I'm developing that is based on this Template, namely reading configuration data from an XML file into a Global and, in the same VI, wiring that Global to a "use-me" terminal, but with no guarantee that I'll read the Global after I write it).

There is, I suppose, an issue of "speed" -- perhaps Global Variables are "faster" than VIGs (particularly if the VIG "sits" on an Error Line).  My thought, though, is that this difference is likely to be trivial, particularly as these VIGs (or Globals) tend to get "occasional" calls (except for the "All Loop Stop" flag that gets called once per loop).

Are there other arguments or considerations that make a Global Variable a better choice than a VIG?  Is there a reason that the LabVIEW Developers put them in these Getting Started with LabVIEW Projects?

BS

---

There's nothing wrong with using Global Variables, as long as you understand when and hw to use them.  If you are going to write once/read many then using a plain old Global Variable is a lot easier to implement and maintain.  When data will be constantly shuttling in and out, it's better to use an FGV.

[Ranjeet_Singh]

Why not? Why you dont like global variables? Whats wrong. This is also a method of IPC.

[Bob_Schor]

---

@Ranjeet_Singh wrote:

Why not? Why you dont like global variables? Whats wrong. This is also a method of IPC.

---

I neither "like" or "dislike" Global Variables.  From listening to talks at NI Week and reading from Better LabVIEW Programmers than I, I got the impression that Global Variables were not always the "preferred" solution.  Yet I see them in code designed (I hope!) to be a "Gold Standard" for LabVIEW code development, and am asking for understanding why this choice was made.

My own practice has been to use VIGs and "Write-only" VIs (which I call "LabVIEW Constants"), but to not use Global Variables.  By asking this question, I'm attempting to learn under what circumstances Global Variables might be a better choice.

I do not understand the sentence "This is also a method of IPC", having no idea what IPC means.

BS

[crossrulz · Accepted solution]

I have to ask, how are you using Functional Globals Variables?  As just a Get and Set?  If so, you might as well just use a global variable.

Yes, globals are faster and use a lot less overhead.  At the CLA Summits the last couple of years, we talked about using globals.  The most common use is for Write-Once-Read-Many and Write-Never-Read-Many with configuration data.  It is a good idea to use globals with constants that can change on you.  It actually turns out that the global will have the same performance as a constant in this case.  This is done so that you only have 1 place to edit the "constant".

The rule about "Globals are Evil" actually goes back many years when NI had the huge "Locals are Evil" vendata.  But NI didn't explain well how to do things properly.  So I found people, instead of using locals, using the value property node.  This is even worse because the property causes thread swaps and kills your performance.  It wasn't until I yelled at people to use wires and shift registers that I saw improvements in how people wrote their code.  So people are still riffling about the use of globals and have decided to use FGVs with the Get and Set cases instead.  But this doesn't fix the problem of race conditions with critical data and you are causing extra overhead.

So coming from my experience, I use globals all the time for configuration data.  Yes, you have to be careful about race conditions.  But as long as you understand that, it is a common and useful practice.

I would not use a global variable for data that is constantly changing (use shift registers or Action Engines) and/or processes that have critical sections of code (use an Action Engine).

NOTE:  I am using Mercer's definition for FGV (a Get/Set only) and Action Engine (many cases that specifically act on the data contained).

[Bob_Schor]

Thanks for the clear discussion.  While I didn't know it originated with Steve Mercer, I also use FGV (or VIG) for Get/Set and Action Engines for more complex things driven by a custom Enum.

[crossrulz]

---

@Bob_Schor wrote:

While I didn't know it originated with Steve Mercer

---

It didn't start with Steve Mercer.  The FGV has been around since LabVIEW 2, well before Steve even heard of data flow.  And the Action Engine was first defined by Ben Rayner.

There has been some discussion about terminologies in the last couple of years.  I was in Steve's presentation at NI Week this year and he had a slide that had Action Engine and Functional Global Variable in different columns.  I asked for his definition.  I fully agreed with his distinction and have been using that definition since.

[altenbach]

---

@crossrulz wrote:

---

@Bob_Schor wrote:

While I didn't know it originated with Steve Mercer

---

It didn't start with Steve Mercer..

---

I never heard of that guy. Are you possibly talking about Stephen?

[JÞB]

Look into my thread here

Had I taught my co-developers where to use a global instead of a constant that thread would not exist.

A few things to note though:

1. IMHO there must be a requirement to WRITE a global before it is valid.  Either from a config file or by a set-up calculation.  that constant 84600 (seconds per day) changes at least twice per year where daylight savings is observered and may change up to four times a year to accomodate leap seconds.  A file of leap second days and DST changes can make that global pretty valuable.  I'm sure there are other examples.
2. With the introduction of newer features (to lvlibs and classes) Globals can be restricted in scope (Marked private) Public globals were the main reason that Globals were not good practice (Some id10t wrote to my Global WHERE?) 

So "Public" Globals and Globals whose values are "defaulted" should still be avoided because someone WILL access them out of scope.  "Polite Globals" are blazing fast and highly useful.  In the templates these rules are respected.   Even if you don't decorate the templates vi names the FQN limits the scope of the global to the project's application instance.

[JÞB]

---

@altenbach wrote:

---

@crossrulz wrote:

---

@Bob_Schor wrote:

While I didn't know it originated with Steve Mercer

---

It didn't start with Steve Mercer..

---

I never heard of that guy. Are you possibly talking about Stephen?

---

I'm sure he meant "Stephen"  right Timmy?