Programming with Style


Programming really is an art... and it can be especially fun in LabVIEW! The following section is a collection of final reminders and guidelines for writing a good LabVIEW application. You can look at the Fundamentals>>Development Guidelines> Concepts>>LabVIEW Style Checklist section of the LabVIEW Help documentation for a checklist of style and quality guidelines.

If you're interested in learning more about LabVIEW coding style, check out The LabVIEW Style Book by Peter Blume (2006, Prentice Hall).


One of the best ways to learn good style is by looking at the LabVIEW code of developers who use good style. One good place to find such examples is on the block diagrams of OpenG VIs. These VIs are under heavy peer review and scrutiny and, as a result, have code that is very well organized and commented.


Modularize and Test Your VIs

Although it's theoretically possible to be too modular in designing your program, this rarely happens. Make all but the most simple and trivial functions and procedures subVIs. This gives you a chance to test each of your individual pieces of code before working with the big piece. It also lets you easily re-use code, keep yourself organized, and make the block diagram size manageable. Don't forget to test each subVI as a top-level VIand be thorough: Test all sorts of strange input combinations. If you know all your subVIs are working, it should be very easy to debug any problems with your top-level VI.

One useful tip: Often LabVIEW programmers won't test certain VIs because they require DAQ hardware or other externally-generated inputs. Don't wait until you have the hardware. Write a simple "dummy data" VI (or better yet, use a simulated DAQmx device as we learned about in Chapter 10, "Signal Measurement and Generation: Data Acquisition") to pass data to these VIs in the meantime so you can at least test part of their functionality.

Document as You Go Along

Please document your work! Many programmers shun documentation, thinking it will be done later or not needed . . . until a user (possibly yourself) two years later is trying to figure out how this VI works. Take advantage of LabVIEW's built-in documentation capabilities:

  1. Block diagram comments. Use floating labels (or edit function and structures labels) to comment your code. Don't get carried away, restating the obvious, but definitely place comments that give people an overview of what the code fragments are intended to do.

  2. VI documentation. At the very least, write a short description for each VI you create. This is extremely valuable when someone is looking at the subVI icons in the block diagram and needs an idea of what they do.

  3. Descriptions. Ideally, write a help statement for each control and indicator using the pop-up Description and Tip . . . command (unless you've chosen the control label or caption so well that it tells the whole storyvery unlikely). These invaluable comments will appear on the Help window if a user points to the control or indicator in question.

  4. VI revision history. This option, available from the Edit menu, is a more sophisticated tool for larger projects. It allows you to enter comments about the changes you've made to a VI along the way. The History window can be quite helpful when more than one person works on a project, because it keeps track of the user, time, and date. (It also can be invaluable when someone manages to link an old copy of a subVI into your project, and old bugs that you know you've fixed reappear.)

  5. Front panel text. For important indications, just write some text (perhaps with a bold or large font) on the front panel itself. Users can't miss that one!

One More Time: Dataflow!

As you get more comfortable with LabVIEW, you will begin to take more advantage of the way dataflow programming works. Some tips to remember are the following:

  • Dataflow means that data is carried across wires. When data reaches a terminal of a subVI or a function, that subVI or function will only start executing after ALL of its input terminals have received data.

  • Two or more objects or groups of objects on the block diagram that are not connected have no specific execution sequence. Many people new to LabVIEW have a feeling that execution should take place left-to-right or top-to-bottom. That is not true! There is no way to predict in what order two or more pieces of block diagram will occur unless it's specified by dataflow. (Unconnected nodes won't even necessarily execute in the same order each time, so execution highlighting doesn't help predict the order.)

  • When you need to "force" an execution sequence, you have the option of using a sequence structure, which can be awkward for large diagrams, or an artificial data dependency structure, as shown in Figure 17.36. (And, yes, most experienced LabVIEW programmers use a single frame sequence for this purpose when there isn't a convenient terminal availablebecause a "sequence" is self-documenting.)

    Figure 17.36. Even though B requires no inputs from A, by wiring the output of A to the sequence structure, the diagram forces B to execute only after A has completed executing. C similarly does not begin execution until the entire content of the sequence, including B, has finished.

  • You've noticed that many LabVIEW functions have common "threads": refnums, taskID, error clusters, and so on. These threads are designed to string several common VIs together in a natural dataflow sequence. You can also use threads, such as error clusters, for your own VIs. Using threads will reduce the need for sequence structures with awkward sequence locals.




LabVIEW for Everyone. Graphical Programming Made Easy and Fun
LabVIEW for Everyone: Graphical Programming Made Easy and Fun (3rd Edition)
ISBN: 0131856723
EAN: 2147483647
Year: 2006
Pages: 294

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net