understanding the global variables concept

[jon_mcbee]

To add to what GerdW said.  One nice thing about the cluster is that it follows the data flow paradigm while the action engine breaks it the same way that a global variable does.  One nice thing about the Action Engine is that you dont have mulitple shift registers carrying data between states in a state machine.  Its a matter of personal style, I like the Statechart module because it abstracts all of this away...

[PaulG.]

855 Globals?! Sounds like it's enormous with an enormously ugly code structure. Something like that needs to be shot and rewritten from scratch. You have my deepest sympathies.

[smercurio_fc]

krispiekream at the end of the day:

 

[PaulG.]

Popcorn. Mmm popcorn.

[tst]

---

jmcbee wrote:
Functional Globals are better to use than Global Variables because they do not allow race conditions because they are not reentrant, and therefore can only be written to in one place at a time. 

---

This assertion is completely false as it is written.

FGs are better than globals not because they can be written to from only one place at a time (the same is true of globals), but because they are functional. This means that they can have internal code which performs whatever operations are needed. The "better" part comes because they can only execute this code sequentially, because the non-reentrant setting locks the VI.

If such a VI only has set and get operations which put the value into the SR and read it out then it isn't any better than a global and in some ways it's worse.

[altenbach]

---

krispiekream wrote:

I found out that my main program uses 855 global variables.

---

Is this 855 unique global variables, or 855 instances of a single global variable, or something in-between?

There is nothing wrong with global variables if they are used properly (e.g. not as a substutute of "variables" in text based code).

Can you show us some code so we can get a better idea of the problem?

[DFGray]

I once flushed a shipping (and very buggy) application for exactly this reason.  After that experience, I would not recommend starting from scratch.  You are far better off refactoring your existing code, painful as it may be.  It is working.  That means a lot of problems were solved to get there.  You lose that knowledge if you start from scratch.  I have also refactored a very buggy, brittle, and old piece of code (about 200 VIs, six years and six hackers).  It took much less time than expected (one week for design, one week to code, one week to debug/verify), and I did not lose all the domain knowledge that went into the original code.  Break it up into subVIs, then put the whole thing into a good programming structure, if you have the time.  Planning is key.  If you approach it right, you can do it in stages by modularizing the base code a bit at a time before you finally copy the whole thing over into a good base structure (provided it does not already exist).

One more note.  I prefer single-element queues over action engines for data storage.  They are pure data storage and more scalable than action engines.  They are also faster in most situations.  However, this is only a preference.