You Don’t Need a 34-Inch Monitor to Be a Good LabVIEW Programmer: LabVIEW Rookie Mistake No. 4

Publish Date: Oct 01, 2015 | 9 Ratings | 4.56 out of 5 | Print | 3 Customer Reviews | Submit your review

Table of Contents

  1. Why Worry About Software Architecture?
  2. Scale With a State Machine Design Pattern
  3. Execute Parallel Tasks Using a Queued Message Handler
  4. How to Be a Software Engineering Ninja

1. Why Worry About Software Architecture?

One of the most common frustrations a new LabVIEW user endures is learning how to manage a block diagram to be able to program effectively. Believe it or not, you don’t need a stack of monitors that look like the Jumbotron at your local stadium to be an efficient LabVIEW programmer. A bloated diagram that’s hard to navigate is often a symptom of a poorly architected program.

We’ve all been there: you need to get a project out the door and you take shortcuts by bolting together bits of code. You end up with a monster but, hey, it compiles. Though it may be gratifying in the short term, this approach will leave you with a messy diagram that’s costly to understand, maintain, and scale over time. If your code looks like the example shown in Figure 1, it’s time for you to invest in learning a couple of key architectures to help you write more robust (and more compact) code.

Figure 1. With code like this, you need more help than a bigger monitor can provide.

 

Software architectures are common frameworks that provide a sound and scalable way to build many types of applications. A lot of the architectures in LabVIEW, such as state machines, are similar to those in other programming languages. Understanding LabVIEW architectures reduces development time and improves application scalability. It makes your diagram more readable and easier to navigate. The templates and sample projects that come with LabVIEW 2012 and later are a great resource for you to explore and learn. Templates explain the different architectures and when they should be used. Built on top of the templates, sample projects are larger applications that demonstrate how you can use architectures to meet real-world challenges.

 

Back to Top

2. Scale With a State Machine Design Pattern

 

With a state machine, you can quickly build an application that you can scale by adding more states. This architecture can be used to implement complex decision-making algorithms represented by state diagrams or flowcharts. The design of this template makes it easy to insert new sections of code, remove sections of code, or change the order in which sections execute—all without making major modifications to the structure of the application. Besides their powerful ability to implement decision-making algorithms, state machines are functional forms of application planning. As applications become more complex, so does the need for adequate design. State diagrams and flowcharts are useful tools in the design process.

 

State machines are not only advantageous in application planning but also easy to create. A state machine requires a loop with a Case structure inside it to execute the right code for a particular state. State transitions occur by passing the next state through a shift register and using this state information as the input to the case selector. Take advantage of the Simple State Machine template in LabVIEW 2012 and later to get started quickly. From the Getting Started window, click Create Project and choose Simple State Machine from the list. Once you have created your project, take advantage of the extensive project documentation to learn exactly how to customize this architecture to meet your needs. Click here to learn more about the state machine application design pattern.

 


Figure 2. This code is already more compact and scalable.

Though the state machine is a powerful tool for many applications, it does have limitations. For example, states execute sequentially in this single-loop structure. If you have operations you can perform in parallel, then you can improve your execution time by moving to a multiloop pattern.

 

Back to Top

3. Execute Parallel Tasks Using a Queued Message Handler

 

A Queued Message Handler (QMH) template facilitates multiple sections of code running in parallel and sending data between them. Each section of code represents a task, such as acquiring data, and is designed similarly to a state machine. However, a QMH can easily be expanded to a multiloop pattern for which tasks communicate between each other by passing data in a queue. Because of this design, you can divide your application into tasks and run several tasks at the same time. A QMH is a scalable design, and even a multiloop QMH should fit on a single screen especially if you use subVIs to contain your various message handling loops.


A QMH consists of three key steps. First, the Event Handling Loop monitors the front panel for a user action, such as a button press. When a particular action is captured, a message is produced and stored in a queue. Next, the Message Handling Loop reads the message from the queue. Finally, the code corresponding to that particular message is executed. To accommodate parallel tasks, simply create multiple Message Handling Loops.

 

In addition to enabling tasks to execute in parallel, a QMH can easily scale to meet new requirements by adding cases to one of the Message Handling Loops or adding more loops if needed. With this pattern, you can create a responsive UI. Because all user actions are monitored and queued up by the Event Handling Loop, you don’t risk missing an action while other code is executing. To learn more about building and modifying a QMH, explore the template in LabVIEW 2012 or later.

 

Figure 3. A QMH relies on at least two parallel loops.


The Continuous Measurement and Logging Sample Project shown in Figure 4 is an example of a real-world application that is built using a QMH pattern. Here, five loops are executing in parallel—the Event Handling Loop, UI Message Loop, Acquisition Message Loop (encapsulated in a subVI), Logging Message Loop (encapsulated in a subVI), and Data Display Loop. This makes the application responsive as it acquires, logs, and displays data in parallel so one step doesn’t bottleneck another. Though this application is quite sophisticated, the code fits nicely in one screen.

 

Figure 4. This moderately complex application still fits easily on one screen.

 

Back to Top

4. How to Be a Software Engineering Ninja

 

Investing in architecting your application right the first time will save you time and money in the future. It will help you be a faster, more effective programmer and eliminate spaghetti code and massive block diagrams. You don’t have to be a Certified LabVIEW Architect to start building better code—the LabVIEW Core 3 course is a great place to start. It teaches you how to follow an agile software development process to design, implement, document, and test key application features. If you are on active service (SSP) with a LabVIEW Full or Professional license or a Developer Suite license, you can access LabVIEW Core 3 for free through NI’s Self-Paced Training offering. Learn more about increasing your LabVIEW proficiency.

This article is part of a series on the Top 5 LabVIEW Rookie Mistakes. Subscribe to NI News to keep up with the series.

Back to Top

Customer Reviews
3 Reviews | Submit your review

Good, point, in fact limit them to 20 inch monitors with 1200x1024 resolution  - Oct 21, 2014

Another missing point on architecture, is to look at tools for re-use or that already exist! Why reinvent it? Most of what you mention already exists in TestStand... I know this is a LabView forum, but you gain so much by using the amazing features already there.

Different title for managers?  - Oct 21, 2014

It's hard enough already to convince managers to pony up for new monitors; this title wouldn't help. Maybe NI can target managers' user profile information (i.e. job title) to send a title like, "Employees Have Earned >34" Monitor When They No Longer Make This Rookie Mistake". :p

Excellent means to work around bitmap limitations of LabVIEW display  - Oct 21, 2014

Why use the awkward and "imaginary" word "architected" when "designed" is exactly what you mean?

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit