LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

global.vi vs functional global

Hi,
 
I'm making an application with one data acquistion VI and a bunch of user interface screens which includes about 50 global variables.  On another forum, it was mentioned to me that some expierenced LabVIEW users avoid globals altogether and if they need one they use a functional global.  I was wondering what the advantages and disadvantages of using functional globals vs. using regular global variables were in a fairly large application like the one I'm making.  Any advice would be appreciated.
 
Thanks in advance!
 
Jason
Message 1 of 9
(6,209 Views)
I hate to say "never", but in this case I would NEVER use a global and always use a functional one, especially in a large application. I shy away from globals altogether, even in smaller applications, but I'm sure they have their use somewhere. I just don't know where. Smiley Happy
PaulG.

LabVIEW versions 5.0 - 2020

“All programmers are optimists”
― Frederick P. Brooks Jr.
Message 2 of 9
(6,206 Views)

see this thread

http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=2362&jump=true

Where tst solicites replies to the Q " Re: Are globals really THAT evil? ".

Ben

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 9
(6,198 Views)

After reading the thread about "are globals really THAT evil?" I'm a little confused.  It said somewhere in there that the built-in globals are faster than LV2 globals but the regular globals make a copy of the data.  Wouldn't that slow up the call of a regular global and make LV2 globals faster?  Also, in my application, most of the globals are written to only once and read multiple times and the few that are written to multiple times, I laid out a sequence of events or made the VI front panel modal so that race conditions didn't occur.  I guess what I'm really asking is this.  Would changing the globals to LV2 globals improve the performance of my application and make it run a bit faster?

Jason

0 Kudos
Message 4 of 9
(6,162 Views)

One other tidbit I really like about "functional globals" when debugging:

I can set conditional breakpoints based on numeric value in the code for the "Write" case, then trace back to find out just who the heck is responsible for writing the weird value at the wrong time.  Very nice!!!  Can't do that with native constructs like true globals, notifiers, queues...

-Kevin P.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 5 of 9
(6,146 Views)
Globals are faster when they don't hold a lot of data because of the way LV schedules the running of VIs. Apparently, the time it takes to handle a global (which is probably just a pointer if you're reading it) is much shorter than running a VI. If they do hold a lot of data, the very act of creating a copy sometimes takes a lot of time, not to mention larger memory consumption.

@Kevin Price wrote:

I can set conditional breakpoints based on numeric value in the code for the "Write" case, then trace back to find out just who the heck is responsible for writing the weird value at the wrong time.


Nice trick. I haven't thought about that one.

___________________
Try to take over the world!
0 Kudos
Message 6 of 9
(6,122 Views)

One thing for sure when to switch to global variables is:

1) to have a pop-up panel for user inputs

2) run out of room on the calling vi, even when using tabs

But the big drawback of it is slowing down the processing time when they are called and in active state (passing data or in a loop). And YES, ALWAYS avoid using them if possible because local variables are ALWAYS faster, stack pointer inherently, common sense!

0 Kudos
Message 7 of 9
(6,087 Views)


@napview wrote:

One thing for sure when to switch to global variables is:

1) to have a pop-up panel for user inputs

2) run out of room on the calling vi, even when using tabs

But the big drawback of it is slowing down the processing time when they are called and in active state (passing data or in a loop). And YES, ALWAYS avoid using them if possible because local variables are ALWAYS faster, stack pointer inherently, common sense.


I can't say I understood what you're saying, but I fail to see the relation between locals and globals. In general, using locals as a means of data storage is bad form - you're better off using wires as much as possible with the same exceptions which were described in the other thread for globals and a few exceptions which are only relevant for locals.

You are correct that locals are faster than globals (although I wouldn't jump to conclusions as to why, probably the locking is simpler to handle), but globals should be used when you want a global means of communication, not just because you run out of room on your FP. If you want to avoid running out of room, either use tabs and hide the controls or use wires instead of locals. In any case, both globals and locals have some disadvantages which can be overcome by using functional globals.


___________________
Try to take over the world!
0 Kudos
Message 8 of 9
(6,051 Views)
Oh I didn't make it clear. No I did not mean local variable and you got that right: local controls and indicators. I believe that use of either global or local variables all over the place will slow down the program significantly.
0 Kudos
Message 9 of 9
(6,038 Views)