BreakPoint
Rube Goldberg Code
- There is at least one uninitialized shift register that (seemingly) grows an array of a cluster without bounds. It is actually difficult to tell, because the initialization wire could be buried underneath the FOR loop. Please check.
- Blindly writing the same properties (many properties!) over an over with every iteration of the loop is relatively expensive and disruptive. Properties should only get written when the property actually changes.
- All value properties should be replaced by locals. For example, in the center we read from a local, process it, and write back to a value property of the same. e.g. [C(v), M(mV/dB)]. Of course ideally you would keep them in a shift register or action engine.
- There are potential race conditions, for example some of the controls at the bottom left are also modified by code above it, meaning that code fragments that depend on both data paths (e.g. the small case structure in the lower right) could get hybrid data, some based on the old and some based on the new values. Of course there is no real way to check all this without seeing actual code and spending hours debugging.
- There is a reference kept in a shift register (top SR in outer loop) that goes through a case where some cases drop the reference (use default if unwired). This means that the reference can potentially become invalid. (this can lead to errors and even buildup, because dropped reference cannot be closed)
- I have rewired that particular shift register to initialise it. In the outer while loop (you can't see the left side of it in the picture) I have several uninitialised shift registers, but their values are irrelevant until the 'test' boolean button has been pressed which returns results specific to the unit in the test jig. Only then are those values saved or manipulated with meaning. Is this a bad way of doing it? I have initialised some shift registers with blank arrays or clusters, but should I do this for the rest too? (see left side of Image 1)
- I converted the base of this VI up from an old lv5 VI. I have worked with the while loops since they work (in theory) and when I started on this I was new to LabVIEW. I've noticed the event structures hiding in the structures pane, but not really known how to implement them. I have a feeling that they would be the better approach (the other way is often best)! The advantage I can see of the while loops is the simple memory function of shift registers so I can retain values whilst the test program is 'idle' (nothing happening that is visible to the user). (see Image 1 for VI when in 'idle')
- I don't think I have action engines on lv6.1 - are you saying that local variables are generally more appropriate than value property nodes? This is something I've been wondering a while.
- When the VI is in its 'idle' state, there are no race conditions. When the test boolean button control (for want of another name) is pressed, the case statements execute their true function one by one so I think (but could be wrong) that I might just be getting round that.
- I've noticed that. I'm not sure where to close the reference. It is a reference to an Excel._Workbook where the data for the current unit is being written, updated and saved. There are two tabs on the front pane, and when switching between the two, I don't want to loose it. The only way I could see of doing this was to close it at the very end. As expected, this doesn't really work! Any suggestions?
I realise that I'm kinda hijacking this thread with my problems! Should i move this somewhere else to start a thread in the LabVIEW forum?
Yeah - i fear i may be beginning to abuse sub VIs in the same way that some abuse local or global variables! Doesn't it slow the operation to be constantly calling up too many sub VIs?
As for the error wires, they are clusters! 
It's a boolean, a numerical error index, and an error descriptor - all bundled into a cluster! That, i assume, is why they were originally pink. When i went to a half-day LabVIEW basic hands on course thing, i got really confused trying to work out where the errors had gone. Then it dawned on me that someone had decided to print them in black and white. Oh, and another little rant about the modern version - i hated the way all the controls were so big! I had to keep setting them back to their 'normal' size!
I'm thinking of completely rewriting the VI i've been showing you pictures of. Things have been crammed in left right and centre as i worked out how to do more, and also when i realised that i 'needed' to be able to do something else! It's still a bit squashed cos i was originally told to make it all fit on one screen. Now i have too screens, so my VIs are all becoming long and thin! There's quite a bit of defunct code in there now, and i've got several controls and indicators that are waiting to be wired up again since i demolished their associated code. It was messy and didn't work as i wanted it to. There's some VIs i wrote that i can't remember how they work. They were written during an inspirational brainwave - i only know how to use them and as long as they do work, that's fine for me!
I found an old VI created by a predecessor in LabVIEW 5.0 which i'm trying to implement. When i first discovered it i suddenly realized what global variable abuse really meant. The associated page of globals wouldn't fit on my screen - even if i crammed them together so they were nearly overlapping! I remember there being several complete graphs in the global panel too, as well as a huge cluster i just now pretend never existed! 
On that note, this VI i've converted up still has a couple of annoying bugs which i can't seem to find the origin of, and a couple of other things that don't work 100% as i expect. Goes a bit like a formula i remember finding in these forums that went something like this:
Number of bugs = (Size * Size * Local variables)/ (Time spent debugging * Skill of programer)+1
D'ya think anyone would be able to give me some pretty in depth help with this?
Anyway, i'd best stop rambling on lest i get banned for failing to reply without too much hesitation, deviation or repetition!
James Mamakos wrote:...
Number of bugs = (Size * Size * Local variables)/ (Time spent debugging * Skill of programer)+1
D'ya think anyone would be able to give me some pretty in depth help with this?
Anyway, i'd best stop rambling on lest i get banned for failing to reply without too much hesitation, deviation or repetition!
I already did!
This series of Nuggets were written to help people implement real apps and avoid complications as they go.
In This Nugget I use Occurences to show how to launch and run multiple threads. Tht discusion talks about the environment re-entrancy etc.
In This Nugget I talk about using type definitions to define your data and simplify passing complex data structres to sub-VI's as well as how to use the Hiarchy screen to evealuate the impact of data type changes on your application.
In This Nugget I introduce the concept of an Action Engine, which solves race conditions and is one of the most powerful code constructs in LV. If you read only one of my Nuggets this is the one to read!
In This Nugget I push Control references to the limit and open up that rat's nest to expose all of its gory details giving you the power to build your own monsters.
All of the above cited Nuggets along with about 120 other Nuggets are linked in this thread.
And if you manage to read through all of those links and are still looking for more, then you can start with this Tag Cloud and explore all of the branches.
If you have follow-up Q from any of those threads, post to them so we can keep the related conversations organized.
But remeber, you are coding in LabVIEW so HAVE FUN!
Ben
To day I want to show the real genius of the Express VI concept. Say I want to check if a number is within a certain range. I could of course use the function "In Range and Coerce" But then I usually have to go through the tremendous drudgery work and do some labview programming. So instead I do as I always do. I toss in an EXpress VI, and problem solved ;). And of course the output will be the "dynamic" type. I feel I have much more control, and overview with this data type.
All kidding aside the interesting thing is to see how much code that is generated for this simple task. Perhaps I am somewhat touchy regarding the topic Express Vi. Since I have used the phrases "flimflams", and "glued on top with cheap glue" in previous discussions. But I still think it is correct to call the result Rube Goldberg Code. Se for your self I have attached the resulting code
The Index Array function is clearly overrated, and the only proper way to pull off a row from a 2D array is to use Delete From Array and Reshape Array. Don't make me tell you again!
from here.
