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.

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.

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!

Fab

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

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):

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!