Help improve my style and quality of LabVIEW coding

Question

Hello,
I am thinking of doing the CLD certification for LabVIEW and have started preparing by reading some literature (code style guidelines, etc.) and also trying to implement the newfound knowledge into my coding habits. I have also read that local variables are bad, and that the best practice is to avoid them.
However, I am having difficulty implementing all of the material I read about LabVIEW coding into my VIs - which are almost always coded in the same manner as the one I attached. Basically all of the LabVIEW applications I make at my company require reading DAQ inputs, processing the acquired data and doing some control algorithms, which send control signals to DAQ outputs, and writing all of the data to a file.
I have attached a sample VI (with dummy DAQ subVIs). If you have the time - any ideas, comments, consideration or improvements on all areas of the VI are greatly appreciated and welcomed. I think this will be the best way for me to learn new LV tips and tricks.
Thank you!
Attachments:
LabVIEW coding test.zip ‏375 KB

Answer 1

Jeff Bohrer wrote:
OK I've seen worse. (actually not too bad but...)
Use wire labels especially when you have wires that don't fit on 1 screen
You show a lack of understanding how timed loops differ from while loops  (event structure in TLoop with DT=0, Elapsed Timer in Timed Loop.   Someday you'll say WTH was I thinking spawing unique execution systems for those
You could have saved a lot of locals and data duplication by enqueueing data from the DAQ loop to the Write File Loop instead of using a notifier
Sometimes an Array of Clusters can be a good idea  clusters of clusters of same data type can often be harder to maintain- want to add a new element- maybe test a single point? just init the array of clusters (like from a file perhaps?)  Saves a lot of confusion
Saving timestamps to file as strings is a pet peeve of mine.  Now how do you graph vs time?  Check out My Idea 
There is no reason to avoid creating sub-vis and making the Main BD fit on one screen.  I fact it can help to show the code high level structure.
Straighten them wires!
Most of your issues would be solved by re-thinking your data structures- A good place to concentrate on to improve.
Keep Slinging- you'll get there
Ok, will do.
Can you explain what the difference is? Or point me to some good literature on this topic? 
How exactly can you do that? I tried sending data via notifier, but I could not send different data types.
I do not quite understand what you mean.
Also, I do not understand what the problem here is. The graph shows data vs time.
Will try.
Mark Yedinak wrote:
OK, I did take a look at the code now. HEre are some additional points to consider.
Document, document, document. None of your controls or indicators are documented. Also, document your code more to help someone looking at it to actually understand it better.
Definitely avoid the use of all of the local variables. Thing of a design pattern that separates the processing tasks from the UI. If you have one task handling the UI you really don't need to use local variables.
Avoid unnecessary bends in your wires.
Definitely get your block diagram to fit on a smaller screen. These days it shouldn't be larger than 1600x1200 or close to that.
Modularize your code. Use more subVIs
You have a classic off by one error in your code. All of your loops use the stop button to exit. However you always check the value at the beginning of the loop iteration therefore you will execute the loop one more time than necessary.
Avoid unnecessary frame structures. You have a frame structure in the second loop that does nothing for you. Everything down stream of it will execute in the correct order because of the data dependencies. The frame structure serves no purpose here.
Try to avoid deeply nested case structures. Once I start to see that happening in my code I rethink my logic. At a minimum I would build an array of the various Boolean values and convert them into a number and use that to chose the appropriate case to execute rather than nesting three or more case structures.
Will do.
How can I accomplish all the tasks in my application without the use of local variables? I admit, this is the main reason I opened this thread ... because I have tried to imagine a design architecture that would work without local variable, but was unsuccessful. Can someone please explain in detail how to do this on this specific application.
Will try to.
I will try, but I make my block diagram to the width of my screen, but vertically I do not limit its size - so I can easily scroll up and down to move around.
I try to create as many subVI as possible, but only on code that is reusable on other projects. Is also better to have a lot of single use subVIs with every project? Doesn't this add unnecessary overhead and slows the application?
What would be the correct way to stop the application?
Ok.
Ok. I only do your proposed solution on nested case with a depth of at least 4. 3 nested structures were still acceptable for me, but I will listed to your proposal and try to improve on this.
Thank you all for taking the time to look at the code and writing your comments.
I already have the CLAD certification, but this was only a test. I think I will be able to try the CLD exam sometime next year, but I have to learn and implement different coding style in my everyday application (at work). With your help I am sure I will be able to accomplish this - reading literature is one thing, but actual projects are another.