06-29-2011 10:42 AM
I'm relatively new to LabVIEW and as I'm building bigger and bigger VIs with multiple subVIs, etc. I've been wondering what makes a good "looking" program. Basically... how should I organize it so that it's readable and makes sense to another person.
Is there any where I can find some good examples of this with some more complicated programs? I did a quick search and didn't find anything, but please let me know if you know of anything. Thanks.
06-29-2011 10:48 AM
If you have lots of sub-vi's in a logical file strucure you're on the right path. If they have good naming and connector panes it's excellent. If you wire through all with error wires and use it you're home safe.
http://www.ni.com/pdf/manuals/321393d.pdf#labview_style_guide
/Y
06-29-2011 10:49 AM
My image gallery has a lot of samples to look thru.
Ben
06-29-2011 02:27 PM
A vi looks good if it's fitting on a single screen. Getting a bigger monitor is the cheating option. Switching your monitor resolution to 640x480 is like zen (doesn't help you to get the job done but enlightens you). Yes, I seriously recommend to try to code on such a screen. It's the same as with other scientific topics, the true master does not talk a lot to say a lot.
Organize your SubVis in a Tree.vi (also known as FakeRoot). This is a vi that's not intended to run but just to show an organization/documentation of your SubVIs (similar to the hierarchy window).
Comment. Just plain text what you intend to do at some place, which bugs you might expect, references to specs... whatever. Drop pictures if you have (like state charts, formulas, ...).
Show us code. Then we can comment on your style. Most of us are pretty happy to do a code review.
Another recommendation is to get the 'LabVIEW style book' by Blume. As the name tells, it's teaching best practices in coding style (but not how to code in LV).
You also can find some cool example stuff in the LAVA CR (code repository). People there tend to write a lot of good code.
Felix
06-29-2011 03:51 PM
Thanks for the information. I'll have to take a closer look later. I have however taken a snippet of my "worst" one - meaning more complicated and not put into many subVI's yet. I have plans to make several subVI's but at least this will give anyone that wants to a chance on critiques the general flow of my block diagrams.
Note: There are some things because LabVIEW makes local variables/property nodes messy when I made a snippet of this chunk of code.
06-30-2011 02:03 PM
At first, this looks good, your wiring is clean and easy to follow the data flow. I've some worse code in my own projects.
So let's see where/how you can reduce the overall BD size.
I think that using SubVIs will also get down a second optical 'bug', that you have a very highly nested structure (look at the bottom right corner and see that you have 4 error catching case structures). I normally place the error catching case around my event structure. Maybe this already gets you rid of one. Also I think some of them are unnecessary, as code isn't executed with an error on the wire (e.g. the TDMS and VISA vi's won't do anything when called with an error).
As an alternative, use a state machine that basically just goes Init CAN -> Init Visa device -> Run -> Shutdown with branches to an error handling state or to the shutdown state (e.g. if cancelled by the user).
Other points to change:
Felix