≡ Menu

033 VISP Functional Global Variables Revisited


If you think you know everything there is to know about functional globals, then you're wrong. In this episode of the VI Shots podcast, Nancy Hollenback and I take functional global variables to the next level. Find out how to safely use native globals, have multiple instantiation capabilities and speed optimize your look-up tables.

Functional Global Variables Revisited

I hope you enjoy this interview as much as I did. Leave me a comment below and tell me what you think of this episode, or if you have any questions. You can support this podcast by subscribing on iTunes (for iOS) or giving us a rating and review in the platform of your choice.

Links to the topics mentioned:


Hey, this is Michael Aivaliotis! Thanks for reading my post, listening to the podcast or watching the video on this page. When I’m not posting content on this site, I help companies develop automation powered by LabVIEW. If you want to find out how I can help you succeed with your next LabVIEW project – Contact Me.

  • FabiolaDelaCueva

    Glad I finally had time to listen to this podcast. I enjoyed it a lot. I admire Nancy and I have been lucky to have her as my mentor in my career as a LabVIEW consultant. Thanks Nancy, I am always happy to have the opportunity to continue to learn from you.

    All advanced users think there is not more to learn about FGVs and there is always something new!. I found very interesting the idea of using an actual global, adding it to a project library and setting its scope to private. Thanks for talking more about project libraries, I have been teaching more and more to use them. I agree they are very powerful and underutilized. Just one little observation, when Nancy and Michael talk about protecting the global storage data, the access scope has to be set to “private”, they mention “protected” several times, that access scope option is available for LabVIEW classes (which at the end of the day are another time of project library).

    I had set in the past the FGV and the enumerator in a project library and set them as private, then I create wrapper VIs for each option in the enumerator. The idea there is to create a public API and make sure that only the needed inputs and outputs are exposed via the connector pane. I have found that this works much better with beginner programmers, because they don’t become confused with all the extra inputs and outputs that are only used in certain actions and not in others. In turn, this leaves the architect with an option to later change the insides of the FGV (like trying what Nancy suggested with the Global variable, or replacing implementation with a DVR or other options) without breaking any code that calls it. It also provides an opportunity to turn the beginners into intermediate users by showing them other alternatives. Finally, locking a project library, hides the private VIs in the project tree, making it clear what are the VIs the library designer intended for the developer to use.

    Michael, thanks again, love to listen to VI shots podcasts, it is like having coffee with all my LabVIEW heroes. Keep them coming!


  • Steen Schmidt

    Great discussion of some different “FGV” type data stores. I was surprised to hear that a Global should be faster by 10x compared to a feedback node (all else equal), and my own (very preliminary) investigations show that the feedback node actually beats the Global by 30%. I’ll look further into this discrepancy of course…
    But great thoughts about protecting the private parts of an “FGV” with the locking mechanisms of a lib. Hadn’t thought of that. There could be some good stuff in there.
    Take care,

  • Steen Schmidt

    Ok, I’ve solved the puzzle. The issue is that using a feedback node over a while loop isn’t just a couple of percent faster, THAT’s 10x faster and even beating the global. So relatively we have this performance (numbers are execution times thus lower numbers are better):

    FG with For loop and shift registers: Index 100
    FG with While loop and shift registers: Index 98
    FG using private global: Index 17
    FG with feedback node: Index 12

    I must add that absolute performance depend on data types and compile options but in all cases the ranking is as above.

    So use no lvlib, just replace while loop and shift register with a feedback node and you have highest performance.


    • Steen, thanks for this awesome discovery. Just got around to reading your comment and observations. I think this adds several more positive points in favor of feedback nodes in my development practice. Thanks!