BreakPoint
Why some people say Local Variables are bad...
Not as bad as some, but adding to the fun. They also use the property nodes instead of locals.
After spending a number of months getting his project to work, my colleague has asked me to make a small hardware change.
VI size: 3.2MB
396 local variables
57 stacked sequence structures
A single test run will normally take upto a week of continual running, and the log file loop is timed with the 'wait until next multiple' function
Top right structure:
Sequence inside case inside sequence inside while inside case inside while
A whole bunch of control polling loops, yet has demonstrated understanding of the event structure
I'm rather tempted to do the quick change and put it into the code repository under someone else's name
@Ben wrote:
@for(imstuck) wrote:
@yenknip wrote:
After spending a number of months getting his project to work, my colleague has asked me to make a small hardware change.
Well, I think I found one disadvatage of being able to make parallel loops so easily in this language...
LV 5.1 was a funny (I am being polite with that word) version of LV. It featured multipthreding but did not offer property nodes but instead used attribute nodes. Any non-trivial GUI required an "upside down" implementation wherein all of the low-level stuff had to be handled in the top level VI and the high level stuff was pushed down into the sub-VI. I suspect most of the "Scary" VIs that NI shows off in their seminars were actually developed in version prior to LV 6i or by a developer that stopped trying to "learn new tricks" in LV 5.1 or earlier.
Ben
Sorry, I don't think I was even alive when LabVIEW 5.1 was out 
But, in all seriousness, that picture of a diagram with crazy wires that NI always shows as an example of piss-poor code gets really old. I don't even laugh at it anymore. I think it must be part of their powerpoint template now, as frequently as I see it...
@for(imstuck) wrote:
...Sorry, I don't think I was even alive when LabVIEW 5.1 was out
But, in all seriousness, that picture of a diagram with crazy wires that NI always shows as an example of piss-poor code gets really old. I don't even laugh at it anymore. I think it must be part of their powerpoint template now, as frequently as I see it...
I never got a really good look at it but it looks strangely familiar to an app I was involved back in the 5.1 days.
Imagine you need to present a GUI that looked and felt like it used tab controls but you were not allowed to use tab controls (becuase they did not exist yet) and you were forced not to use control references but only property nodes on the diagram of the GUI (again since property nodes did not exist, they were attribute nodes).
You would need a plethera of visables disables etc.
Add to that all updates of controls would be limited to terminals and locals and for good measure there was no Event structure so polling was the game used to check for user actions.
AND ... (yes there is an AND)
LV 5.1 was the first version of multithreaded LV so prior to 5.1 the possiblities of Race Conditions were much less. It has ben removed from the standard option settings of LV (it can still be invoked with the right ini token) but LV had an option to allow you to run your code single threaded if you wanted. In many cases, they HAD to run single threaded.
Even a trivial app of that type could quickly turn into what those "ugly" diagrams looked like.
So cut the old guys code some slack! WE were developing with stone knives and bear skins back then.
Ben
And the single thread that it would run in would be the already overworked UI thread, mostly running on the same hardware/processor as everything else. I had a GUI that had "tabs", liked to show it at the NI LabVIEW dog & pony shows. Really painful to implement (compared to today), but as Ben points out, so was much of the GUI stuff back then. Polling all of your controls to detect which one had been selected, ouch! Sort of made complex front panels really glacially slow to respond.
