Customer Reviews

The LabVIEW Style Book

5 star:		(11)
4 star:		(1)
3 star:		(1)
2 star:		(0)
1 star:		(1)

 

 

I get the feeling the other reviews are written by the author and his friends. Some are just a little too glowing.

This book is good but, needs editing because it is very long winded; using twice as many words than necessary to get the point across (the author is always stressing efficiency). Many of the "rules" are subjective and should be called suggestions. For example, the author has a rule disabling "Show dots at wire junctions". I like the dots. The VI's are not included with the book. Some are available from the authors company site but, only after registration.

I recommend the book but, be prepared to spend the time required for reading.

Labview has grown so complex and powerful that the necessity has arisen for a book like this. Inevitable, I suppose.

A lot of the recommedations by Blume are applicable to any GUI designer. Like minimising the text in labels. Few users want to or will read large paragraphs or long sentences pasted into labels. These act instead to clutter up the real estate of the display, and often will confuse the new user or irritate the experienced user, who does not need such a laborious elaboration.

Another tip is to avoid string controls unless really required. The problem here is that the user then has many ways to enter a badly formatted string. Perhaps it should be an integer. But she sticks a letter or decimal point in it. Opps! You'd better then have logic to check for this. But it is even better to prevent such errors from occurring. In general, you should make the input widgets as robust as possible against faulty user input.

Yet another general tip is to have data output in XML format. These days, it makes it much easier for someone else to come along and write code to read in your output, for other applications. By writing in XML, you take advantage of powerful parsers that are freely available.

Of course, many tips are specific to Labview. Try to have data flowing mostly in one direction in a circuit diagram. And not left to right, right to left, up and down. More generally, whenever you have wires, minimise the number of bends. Makes the overall picture much clearer for a user to grasp.

All of which makes this book well worth it for a Labview designer. Granted, there is a lot here, and it is definitely not a trivial read. But even just taking in some chapters has the prospect of quickly improving your circuit designs.

I read the first couple chapters and was impressed with the quality of information. I then gave it to a programmer I am supervising for a project. I had him read it and told him to adhere to the standards of the book. After a couple weeks the code he is turning out is much improved. The flow is better, the code is documented and there is actual error control being used. It will be much easier to maintain the project as time goes on. The point of the book is to write better labview diagrams so I think it works quite well in that regards.

then their efficiency would be much higher.

In our organization we have seen the classic LabVIEW evolution: People with little or no programming experience start with the 3 icon demo, and then start wiring like crazy, and soon are wired into a corner and have a spaghetti bowl of LabVIEW code.

People with Classic CS training may try to force object-orientedness down LabVIEW's throat, and end up having too complex, abstract structures, with a lot of overhead relative to the actual functionality.

Peter Blume's book is an excellent medicine against the above mentioned problems. Probably the absolute three most important rules is to always use Typedefs, choose an design pattern that matches your applications, and learn to use Queues.

Typedef is easy to learn, and should be taught the first day you learn LabVIEW. The time savings are enormous.

The choice of design patterns is a lot more difficult for beginners to intermediate programmers, because it really requires a lot of "wisdom" to pick the right one. Therefore, in my opinion, Chapter 8 is the most important chapter in the book, and also the Chapter that could benefit from even greater detail in learning why the shown patterns are used and going more into details about which things to avoid.

Once you have crossed that hurdle, LabVIEW becomes much easier, more efficient and fun. But for many the "best practice" design patterns seem to break the fundamental data flow rules you learn as a LabVIEW beginner.

* Front panel controls are handled in event structures (instead of being polled)
* Data and front panel controls are often accessed by reference instead of being "hardwired".
* Queues are a cool, safe, and efficient way to move data and control around between parallel loops, but may also confuse users because they also access data by reference, and hence could be considered to be "impure" in terms of data flow.

In addition, traditional LabVIEW wisdom says "avoid massive use of references", and avoid large hierarchical clusters. In my recent experience these rules seem antiquated, in that historical performance related issues with these don't seems to have a significant impact when running on modern machines.

I have also seen programmers who explicitly have avoided queues due to the difficulties associated with them in many textual languages.

In summary, the book is well written. Internally at DELTA we are in the process of adopting variations of Peter Blumes more advanced design patterns, which really are conceptually quite simple and clean, once you understand them.

One consequence about using these design patterns goes quite against the grain of certain ideas in classical programming, i.e. information hiding.

Typical object oriented LabVIEW code shows virtually no specific functionality at the high level. The consumer/producer design patterns in which functions and data are stuffed onto queues and de-queued in appropriate parallel executing loops, actually allows a lot of specific program logic to be visible at the top level, without getting cluttered.

This is thanks to the user interface being handled in case structures (at the top level) and resulting actions being fired (at the top level) in queue selected case structures in the consumer loops.

I have found this actually increases the readability of the code enormously, particularly if carefully lay out your wiring so that you create a Typedef of references to Queues and unbundle by name only the references that are used inside each consumer loop. Thus the master control logic is concisely represented at the top level, even though the diagram is relatively small.

Compared to OO code, it is much leaner, more readable, and easier to maintain. I believe OO is important and relevant, but only for large proejcts and/or large multi-person teams. For typical LabVIEW aps which are in the weeks to month range, I believe the above described design patterns are by far the most efficient to develop, and easiest to maintain. They are also very readable if done well.



Peter Blume is to be congratulated on a truly excellent book. Concise, well written, and worth a lot of money if you follow the most important priniciples.

Perhaps a good follow-on would be a more in-depth discussion of design patterns, which is where efficiency is made or broken, depending on whether the right patterns is chosen.

A final observation, is that I was not able to find the word object-oriented anywhere in this book. I surmise this may be a conscious decision, by showing how far LabVIEW actually can extend its reach with its native paradigms.

Carsten Thomsen

Mr. Blume is a very successful entrepreneur who has used LabVIEW as a central strategy for his company. His practices are worth following. If you want to be any bigger than a team of three in the NI environment, this is a must read.
There are very few books on LabVIEW and this one I found best. This is because following sound programming practices is central for graphical languages.

The LabVIEW Style Book (National Instruments Virtual Instrumentation Series)

I'm programming full-time exclusively in LabVIEW since 2005 and I have implemented more than 70% of what Mr. Blume suggests. You certainly give your customer highly re-usable, scalable and maintainable system if you follow this book.

I'm reading this now and learning plenty as I do. It is very thoughtful and insightful. This book is defining, for me, the step up from being able to use LabVIEW to appreciating good programming style and aspiring to it. This book is much more about why some ways of doing things are better than others, much more about ways to think of LabVIEW, and not just another reference explaining how to use each of LV's features.

Until I saw this book, I was leery of using much LabVIEW. After reading it, I see that LabVIEW doesn't have to be a snarled mess, you can "write" very readable, and useful code. It really is a best practices guide for anyone who wants to write LabVIEW software.

This book is very useful for people that know already how to use LabVIEW. The book is about the best way about how to program the block diagram and front panel for make really useful application that need to be modified for different persons through the time. This is a book about the software engineering concepts in LabVIEW.

This book on LabVIEW Style is very helpful at getting designers of LabVIEW applications to adopt best practices so that within an organization you don't have users scratching their heads trying to get a feel for how each particular LabVIEW application author goes about designing an application before they can become comfortable using the application. This not only means better designed applications, but greater productivity within the organization.

This book is intended for readers that already have a working knowledge of basic LabVIEW principles and terminology as well as experience developing and deploying applications. The book contains the style rules for optimizing ease of use and all of the other desirable attributes of well designed LabVIEW applications. The book first shows each design rule, then provides a detailed explanation, and concludes with examples and illustrations. I found the illustrations to be particularly well done and numerous. Screen shots are shown whenever it is considered helpful at explaining the topic at hand. The following is the detailed table of contents, which is currently not shown as part of the product description.

Chapter 1. The Significance of Style
Section 1.1. Style Significance
Section 1.2. Style Versus Time Tradeoff

Chapter 2. Prepare for Good Style
Section 2.1. Specifications
Section 2.2. Design
Section 2.3. Configure the LabVIEW Environment
Section 2.4. Project Organization, File Naming, and Control
Endnotes

Chapter 3. Front Panel Style
Section 3.1. Layout
Section 3.2. Text
Section 3.3. Color
Section 3.4. GUI Navigation
Section 3.5. Examples
Endnotes

Chapter 4. Block Diagram
Section 4.1. Layout
Section 4.2. Wiring
Section 4.3. Data Flow
Section 4.4. Examples
Endnotes

Chapter 5. Icon and Connector
Section 5.1. Icon
Section 5.2. Connector Pane
Section 5.3. Examples
Endnotes

Chapter 6. Data Structures
Section 6.1. Data Structure Design Methodology
Section 6.2. Simple Data Types
Section 6.3. Data Constructs
Section 6.4. Examples
Endnotes

Chapter 7. Error Handling
Section 7.1. Error Handling Basics
Section 7.2. SubVI Error Handling
Section 7.3. Prioritizing Errors
Section 7.4. Error Handling Tips
Section 7.5. Examples
Endnotes

Chapter 8. Design Patterns
Section 8.1. Simple Design Patterns
Section 8.2. State Machines
Section 8.3. Compound Design Patterns
Section 8.4. Complex Application Frameworks
Section 8.5. Examples
Endnotes

Chapter 9. Documentation
Section 9.1. Front Panel Documentation
Section 9.2. Block Diagram
Section 9.3. Icon and VI Description
Section 9.4. Online Documentation
Section 9.5. Examples
Endnotes

Chapter 10. Code Reviews
Section 10.1. Self-Reviews
Section 10.2. Peer Reviews
Endnotes

Appendix A. Glossary
Appendix B. Style Rules Summary

This book is a really good effort to present software engineering concepts, applied to LabView. Not secondary aspect: it is very easy to read (also for non-english mothertongue people).

Of course, you can't agree 100% with what P.Blume says, but it's useful to know his point of view, and maybe discuss on them.