Why do LabVIEW Example Projects use Global Variables?

[crossrulz]

---

@JÞB wrote:

---

@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?

---

It's a long weekend after a couple of really long weeks and I couldn't quite remember how he spelled his name.  My brain mostly just turned off when I got home Friday.  And it didn't help any that college football started yesterday.  Yep, I watched almost all day and way later into the night than I should have.  I think I am running on 4 hours of sleep right now.

[Bob_Schor]

Wow!  What a lot of obsessing over a passing comment, and spellling of a name.  Let me clarify --

First, I meant to acknowledge Crossrulz's comment that "Mercer" distinguished between FGVs and Action Engines by saying that I had adopted (probably by reading things in the Forums, and maybe even by hearing said person say this himself at an NI Week presentation).  I'm aware that FGVs are also known as LV2 Globals, meaning they've been around a "long time" (and hence probably not "invented" by said person).

Second, while I've heard Mercer give talks and have sat next to him at a recent Action Engine roundtable, I don't claim to know him well enough to know the correct spelling of his name, nor even whether he prefers to be addressed by the formal "full name" or the shortened form, "Steve", that I used.  If I have offended, I do apologize.

[Bob_Schor]

---

@JÞB wrote:

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.

---

I had the pleasure of meeting Jeff at NI Week this year -- I learn a lot from his posts.  Some questions on the above:  I don't see the relevance of the thread on New Numerical Constants.  More important, I think it would be valuable (to me, at least) to see your ideas about "where to use a Global instead of a constant", plus a more complete discussion of "Public" Globals, Globals whose values are "defaulted", and how (and when) to create "Polite Globals".  I think I can figure it out from your post, but a White Paper on the entire subject of Globals, Constants (write-only VIs), and FGVs, written in a language accessible to LabVIEW Programmers at the CLAD/CLD level (so not so elementary, but not able to access the content provided at CLA symposia) would be very helpful.

If you write it, I'll be happy to "edit" it (meaning to raise questions and make suggestions about clarity) (I'm currently working on some of the Hands-On manuals from NI presentations ...).

Bob Schor

[Ranjeet_Singh]

IPC - Inter Process Communication

[Darren]

I wrote most of the RT/CompactRIO sample projects available in LabVIEW 2012 and 2013, with help from our System Engineers here at NI. As I've discussed here, there are perfectly valid use cases for Global Variables. For the configuration data in these projects, the globals are "Write Never, Read Many" (WNRM) globals. For other items like the Network Stream refnums or the All RT Loop Stop condition, the globals are "Write Once, Read Many" (WORM) globals. Now you will also notice that there are some functional global variables being used in some cases to transfer data into and out of time critical loops...according to some benchmarks performed by our SEs, functional globals are the most performant data transfer device for more complex types and time critical loops. But for regular priority loops, and simple data types, globals are fast, very easy to program, and also easy to understand.

[JÞB]

---

@Bob_Schor wrote:

Wow!  What a lot of obsessing over a passing comment, and spellling of a name.  Let me clarify --

First, I meant to acknowledge Crossrulz's comment that "Mercer" distinguished between FGVs and Action Engines by saying that I had adopted (probably by reading things in the Forums, and maybe even by hearing said person say this himself at an NI Week presentation).  I'm aware that FGVs are also known as LV2 Globals, meaning they've been around a "long time" (and hence probably not "invented" by said person).

Second, while I've heard Mercer give talks and have sat next to him at a recent Action Engine roundtable, I don't claim to know him well enough to know the correct spelling of his name, nor even whether he prefers to be addressed by the formal "full name" or the shortened form, "Steve", that I used.  If I have offended, I do apologize.

---

Trust me,  I have reason to believe AQ prefers "Stephen."

Bob, You may be onto something important!  A lot of our community's "Common Knowledge" and best practices have been based on outdated development envioronments.  A Community Nugget discussion of Namespaceing, Application instances and scope is clearly overdue.  DT@Y.Com.  (Hit my profile) 

Sorry for being obscur in the link.   Had you looked throught the link's links you would have learned that I discovered that cosmetic bug by doing a "find and replace" on text within BD Constants in a project.   A Global would have prevented me (Saved my poor co-developers and myself) from finding that bug.

Yes, this might be a template for the discussion.

[dacad]

Reading that many are saying GV's are fine for write once / read many situations.   What about write many / read once ?   

I use a couple global variables a few levels down to define what specific function is occuring or what the current result or load is and then read it once in a 'while loop' (looping for the entire duration of the testing) in my top level vi to update the screen display.

Pros or cons of this ?

Doug

[billko]

---

@dacad wrote:

Reading that many are saying GV's are fine for write once / read many situations.   What about write many / read once ?   

I use a couple global variables a few levels down to define what specific function is occuring or what the current result or load is and then read it once in a 'while loop' (looping for the entire duration of the testing) in my top level vi to update the screen display.

Pros or cons of this ?

Doug

---

It's a little dicey because you have make sure data flow makes it impossible to read the GV before writing to it.  Instead, I would use a state machine to control something like that.  Then dataflow takes care of itself.

[dacad]

All the writes are controlled in the assorted cases in lower (sub or sub-sub vi's) level state machines (specific to each gv) and are pretty much data flow controlled in that manner. The only read for all gv's is in a top level while loop that is essentially only for display updates. 

Has been working for several years like that. Was just wondering what the opinion is of that particular use.

[billko]

---

@dacad wrote:

All the writes are controlled in the assorted cases in lower (sub or sub-sub vi's) level state machines (specific to each gv) and are pretty much data flow controlled in that manner. The only read for all gv's is in a top level while loop that is essentially only for display updates. 

Has been working for several years like that. Was just wondering what the opinion is of that particular use.

---

Since it is an FYI function, I think it's okay.  Still, I would rather have brought in a reference to that control/cluster and use property nodes to write to the main VI control.  Or, I've done this before - have a queue for this and write the informational data to the queue.  Dequeue in the main loop.