03-30-2017 09:06 AM
@Ben wrote:
I have done that and I am not ashamed to admit it. But I use them not as a means to control the code execution sequence but rather to hold documentation IN THE DIAGRAM. State "0" is the code and state "1" or more will hold flow diagrams or images of the industry standards describing the math etc.
Am I being a hypocrite railing against Global variables but still advocating for preserving the Stacked-sequence?
I think not (please help me out if I am missing something) because cloning a SS will not introduce a bug. After all a SS differs from a flat sequence or a set of flat sequence frames coupled together using an error cluster.
Ben
I'm just pulling your leg, Ben. 🙂 I don't exactly believe you're on a downward slope to sequentitis and localitis (old funny forum thread referrence), but it's kind of a volley hard not to tease a little about. I could also have posted the old picture of which types of variables LV developers use.
And placing comments in a SSS doesn't count (though it do make we wonder how big is that comment is if it needs a frame of its own).
/Y
03-30-2017 09:07 AM
Ben wrote:
I BELIVE you see them as useful as long as YOU the developer understand their nature and are the person developing the code AND that anyone that may follow-up to maintain the code in the future has a similar understanding.
Not entirely accurate, but close.
If we are being completely honest here, 95% of my global variables are private data in a library. So only that library can muck around with the variable and it is almost always a "constant" or a one-time written value.
And as far as User Events to stop parallel loops, I store them in an Action Engine that is private in a library. I then have public interface VIs to people to send an event, get a registration, or eventually release it. If loops are parallel, this is not an issue with data flow.
03-30-2017 11:20 AM
For the vast majority of rules, there are always some legitimate cases for exceptions. (That's why rules/regulations/laws should be administered by people with good judgement rather than "zero-tolerance" zealots.)
The primary objection to globals is that they are readily abused.
Using a global in a legitimate way isn't a sin.
03-30-2017 01:54 PM
Ben wrote:An analogy would be "A flat roof is fine as long nobody is stupid enough to try play Frisbee on it."
Was the roof designed to hold the weight of people? Because globals were design to hold memory and that's what they are being used for. You won't find native globals in any of my applications (as far as I can remember) but I won't condemn them until I see how they are used.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
03-30-2017 02:08 PM
@Hooovahh wrote:
Ben wrote:An analogy would be "A flat roof is fine as long nobody is stupid enough to try play Frisbee on it."
Was the roof designed to hold the weight of people? ...
The analogy was based on Deuteronomy 22:8
"When thou buildest a new house, then thou shalt make a battlement for thy roof, that thou bring not blood upon thine house, if any man fall from thence."
Based on that passage and Joshua 2:6
"But she had brought them up to the roof of the house, and hid them with the stalks of flax, which she had laid in order upon the roof.
"
It seems that roofs back in the Old Testament days were designed to hold the weight of people.
When I was in Jerusalem back in 2010, it was rather common to see solar water heaters on the roofs.
Ben
03-31-2017 04:25 AM
Excuse me for digging this out (from yesterday), but I'd like to ask : Why are Globals so evil if overused ? And what are typical cas of Globals overuse ? I generally don't use them, because my boss told so, and he's CLA (and he is my boss) so I do what he said, but I do use a lot of FGV (especially when I need different "means" to save or access to my data), and I also use a lot of queue (with one or more element), but (forgive me for saying this 🙂 I find the globals being very pratical for stuff like ending parralel loop, or holding data such as "current sequence" which have to be accessible to various parts of my code, part which I don't necesseraly know the location in advance.
And since I'm already here, I'd also like to know what is the status quo about local variables. When I first started to develop in Labview, I was told to avoid them since they caused a memory copy. Now I use them freely, just avoiding anything that could multiply big chunk of data in memory (typicaly 2D arrays). Is there any good practice about that ? Should I always use reference pointing to my data instead ?
Thank you in advance
03-31-2017 07:14 AM
I will just defer to a couple of links...
Are Global Variables Truly Evil? (my NI Week 2016 presentation)
03-31-2017 07:40 AM - edited 03-31-2017 07:42 AM
@Ben wrote:
....
I have done that and I am not ashamed to admit it. But I use them not as a means to control the code execution sequence but rather to hold documentation IN THE DIAGRAM. State "0" is the code and state "1" or more will hold flow diagrams or images of the industry standards describing the math etc.
Am I being a hypocrite railing against Global variables but still advocating for preserving the Stacked-sequence?
I think not (please help me out if I am missing something) because cloning a SS will not introduce a bug. After all a SS differs from a flat sequence or a set of flat sequence frames coupled together using an error cluster.
Ben
That's actually a pretty useful idea, I'll have to add that to the idea toolkit. Might not even put code in it, the idea to put multipage/image information is useful as well.
All things have a use; globals, stacked sequences, and yes even the dreaded GOTO statement have their place in your toolbox of code, much like that small, supposedly Phillips, offset screwdriver in the back of your workshop toolbox, there are times when it will be needed as something other than a dust magnet.
03-31-2017 08:13 AM
@Joannick wrote:
Excuse me for digging this out (from yesterday), but I'd like to ask : Why are Globals so evil if overused ? And what are typical cas of Globals overuse ? I generally don't use them, because my boss told so, and he's CLA (and he is my boss) so I do what he said, but I do use a lot of FGV (especially when I need different "means" to save or access to my data), and I also use a lot of queue (with one or more element), but (forgive me for saying this 🙂 I find the globals being very pratical for stuff like ending parralel loop, or holding data such as "current sequence" which have to be accessible to various parts of my code, part which I don't necesseraly know the location in advance.
And since I'm already here, I'd also like to know what is the status quo about local variables. When I first started to develop in Labview, I was told to avoid them since they caused a memory copy. Now I use them freely, just avoiding anything that could multiply big chunk of data in memory (typicaly 2D arrays). Is there any good practice about that ? Should I always use reference pointing to my data instead ?
Thank you in advance
No need to apologize! You were not the one creating a global. (smiley-wink).
I will offer some links and then say a bit.
In my Action Engine Nugget found here I included code that demonstrates the race condition that can occur with Global variables.
In this thread from almost 17 years ago one of the Chief Architects of LabVIEW discusses talks about globals and other methods of sharing data.
In this thread (which was never answered and reminds me that I did experiment with globals on one more occation!) I encountered a situation where I tried using a global as stop flag for a bunch of Timed Loops and discovered some of the Loops were finishing late.
Now for some thoughts on Globals and data sharing...
As mentioned by Mythilit, different tools for different jobs (except for Goto that Dijkstra declared harmful ... introduces chaos). Each of the methods that we now have in LabVIEW can be used provided that use is consistent with their functionality.
Back in the day of LV 4, Globals were less hamful because LV was single threaded because two clumps of code could not run at the same time. But as of LV 5.1 (ws it 5.1 or 5.0 ?) multithreading allowed access of globals in parallel threads. (see those links above so I do not have to repeat).
Stepping back and waxing philosophical about LV Architecture...
One of the things I teach me peers is to spend some time thinking about the shape of an application.
What are the independent components?
When and where do the components interact?
What is the nature of the interactions?
And one of the most important question for a language based on the Data Flow Paradigm "where is the data and how does it move?"
Answering those questions lets us chose from (what is now an assortment but in the early days did not exist) from an assortment of data sharing techniques.
Each of the synchronization and data sharing methods have their own personality. User Events, Notifiers, Queues, Action Engines, globals ...
Check out the documentation for all of those functions and choose the method that matches the needs of the application. Choosing the wrong method may not be harmful at first but may not withstand the test of time and application changes.
Example:
Say you want to be able to change scale factors on the fly and choose a global that shares the scaling info and decide "I will only modify the setting at startup or in a config screen, neither of which will be active at the same time." You test it out it works great and the customer approves and says "That worked so well I want to be able to adjust scaling from my laptop at home while someone on the shop floor is adjusting other scale factors...
Chaos in is not a nice thing in the world of software.
Ben
03-31-2017 08:58 AM
That's a lot of links. Thank you for all of this.
I think that I understood most of the issues that globals can create, but I'll check out your links.
Thank you