LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How should my VIs look?

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.

0 Kudos
Message 1 of 6
(2,311 Views)

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

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 2 of 6
(2,304 Views)

My image gallery  has a lot of samples to look thru.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 6
(2,302 Views)

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

0 Kudos
Message 4 of 6
(2,266 Views)

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.

0 Kudos
Message 5 of 6
(2,247 Views)

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.

  • The timed loop has some empty space between code and checking the exit condition.
  • The VISA code is a good candidate for SubVIs, especially the VSET command could be a single reusable SubVI that takes a dbl. Same for the ISET
  • You also can make SubVIs without intending them for reuse. I think about a XNET/CAN Init.vi. Would save a lot of real estate.
  • Test Info Names could be a Constant.vi (so just the constant feeding an indicator). Might be reusable if you read from the TDMS at another place. I also use small VI Icons for such VI's, about half the size of a normal 32x32 icon. You need to make the 256 and the BW color Icon of a reduced size, then the outer part is made transparent.
  • Use clusters, e.g. max volts, min volts, volt inc, set amps could go into one cluster. You can make the borders transparent, so it doesn't look like a cluster on the FP. Helps you to make that code a SubVi as you only need a single control (the cluster). Make the cluster a type def so you only need to change the type def and not SubVI and FP.
  • Same place, consider using a dialog for setting up the measurement. Then all can go into a single vi (including the FP code/indicator).

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:

  • The run button is outside the coresponding event frame. Place it inside the event frame to get the latching working.
  • Error handling. The outer while loop has no shift registers on the error wire and no abort if an error occures, so you will drop errors without noticing.

Felix

0 Kudos
Message 6 of 6
(2,202 Views)