VIPM Makes Managing Re-Use Libraries in LabVIEW Easier

Distributing code and re-use libraries can be a surprisingly difficult task.  Luckily for us, our friends at JKI have come up with an extremely elegant and professional solution for LabVIEW called the VI Package Manager.  If you’ve never heard of this tool, I strongly encourage that you check it out.  In addition to making code management easier, VIPM lets you download all the OpenG libraries, which adds some very useful functionality to LabVIEW.

To understand when VIPM is especially useful, consider several common examples of when you want to distribute your code:

1. You have a set of common VIs that you want to re-use in multiple applications
2. You are working in a team-based environment and other developers need your code
3. You want to share a set of development tools with a colleague
4. You want to post VIs online for the community to use

These all seem simple enough, but now lets throw a wrench in the works with a few common tasks:

• Updating code – it’s common to make changes or updates to shared libraries during development.  All team-based environments should be using some form of source code control to track and manage changes from multiple developers, but it can still be challenging to make sure you have the right version of all the subVIs installed and in-use at the same time.

• Professional distribution – how do you share code in such a way that it minimizes the work required by the recipient?  Instead of having to move multiple files into the correct directory locations, everything is installed automatically and appears on the palettes.

• Dependency management – ever opened up an application on a new machine and discovered that it’s broken because you forgot some dependencies from a re-use library or a toolkit you forgot to install?

• Multiple LabVIEW Versions – how do you make sure that the updates have been made available in all versions of LabVIEW, and not just the most recent version?

As you’ve probably already guessed, these are some of the biggest challenges that VIPM is designed to help with.

There are two flavors of VIPM: the professional version facilitates creation of ‘VI Packages’ and the free version enables anyone to install and manage these packages.  You can download packages from a number of places online, or VIPM can automatically scan dedicated servers to see what’s available.  I’ve also spoken with a number of LabVIEW users who are using the professional version of VIPM to distribute code internally during development.

As an example, Simon recently posted a set of custom controls for use in LabVIEW.  Minutes after making them available, Jim had created a package and posted it on the document, which made installing them in LabVIEW a breeze.  A few clicks, and the swanky new controls were in my controls palette.

ni_lib_ni.com_inspired_controls-1.1.0-1.vip

These were updated a few times, and each time I just downloaded the package and VIPM took care of replacing the old controls.

Download VIPM and give it a try yourself.  Thanks to JKI for making such a great tool!

Taking a Bite Out of Upgrades and Preparing for LabVIEW 2009

To anyone who is afraid or worried about upgrading, we hear you and we’ve made changes to help.  Back in January of this year, David Fuller wrote an entry on John Pasquarette’s blog  describing what we’re doing in R&D to reduce problems associated with upgrading.  To summarize:

• Our move towards an annual release schedule results in incremental changes and updates, which mitigates the risk associated with introducing several completely new features at once, as we did with LabVIEW 8.0.
• The regular release cycle provides more opportunities for guidance from customers as features evolve – consider the changes to the LabVIEW Project Explorer between 8.0 and 8.5 as an example of this evolution.
• Internal alignment across all teams means better coordination between all software products, drivers, and hardware

However, it’s important to realize that there is something you can do to help.  Try the Beta of LabVIEW 2009.  Upgrade issues are top priority for us - the trick has always been finding these problems, and for that we need your help. 

As of April 2nd, the entire platform of the next version of LabVIEW is now in Beta and available for your evaluation – this means all software, toolkits and drivers. 

As always, the new version contains new features that aim to improve developer productivity and application performance.  To see a list of new features and provide feedback to the community, click here.

Finally, for more resources on best-practices for upgrading your application, consult this guide on ni.com.

Professional User Interfaces in LabVIEW

The flexibility of front panel objects in LabVIEW is something many people, including myself, take for granted.  We quickly drop down charts, knobs, and sliders, leaving them unchanged, and as a result, most LabVIEW programs have an unmistakably similar look and feel.  Of course, this makes it much easier to spot in a lab or during cameo appearances on shows like MythBusters, but many people are looking for ways to make more impressive and even ‘sexy’ user interfaces.

The success of commercial products like the iPhone are clear examples of the growing desire for intuitive user interfaces, but the world of engineers and scientists is not exempt.  There are a lot of practical reasons why a clear and appealing UI is valuable for a large LabVIEW application, as it can reduce learning curves and improve the effeciency of the user.

What many LabVIEW developers don’t realize, is the level of customization and flexibility that LabVIEW controls and indicators provide.  Realizing this, my friend and colleage, SimonH, set out to see just how easy it would be to make some impressive controls and indicators for LabVIEW that broke the mold.  He’s posted his first few examples in his new UI Interest Group, but I happen to know he’s got a lot more up his sleeve.  Join his group and look for more soon!

Here’s another particularly slick user interface that was made in LabVIEW for OptiMedica

‘Software that makes Software Better’ Economist Article

I read a great article in The Economist this morning entitled ‘Software that makes Software Better.’  This article discusses the growing role and importance of development tools for improving the quality of software and talks about the growing challenge developers face.

This article is proof of how far we’ve come in the last half-century.  We’re seeing a number of trends converge and software engineers are struggling to keep up.  Development times are shorter, team size is bigger, the criticality of the applications is increasing, the expectations for quality and reliability are greater, code has to be modular and re-usable, and on top of all this, developers are expected to learn how to use numerous, poorly integrated tools that claim to make everything easier.

I’ve had a number of engineers, especially those in the mil/aero industry, tell me that they spend a mere 20% of their time actually developing code.  This may be slightly over-exaggerated, but a study conducted by the Standish group revealed that this number was closer to about 30%.  The rest is dedicated to refining requirements, discussing work with teammates, documenting, unit testing, integration testing… you get the picture.

The good news is that we’re making progress.  As another study revealed, the Standish group “found that 35% of software projects started in 2006 were completed on time, on budget and did what they were supposed to, up from 16% in 1994; the proportion that failed outright fell from 31% to 19%.”

LabVIEW is being used in larger applications, with larger code bases, and larger development teams.  Of course, graphical programming inherently abstracts many of the common tasks text-based developers struggle with during development, and with a set of tightly integrated software engineering tools, we aim to automate and improve the experience of applying software engineering practices to LabVIEW.  If you’re interested in learning more about best-practices for software engineering with LabVIEW, visit ni.com/largeappsor go to ni.com/SoftwareEngineering to see a list of products that can help.

New Software Engineering Tools for LabVIEW

There is perhaps no more appropriate place to announce the arrival of two new toolkits for large application development than here in the Large LabVIEW Application Community.  The Desktop Execution Trace and Unit Test Framework Toolkits have been introduced to automate common practices for software engineering and help developers improve code quality.

The Desktop Execution Trace Toolkit facilitates dynamic code analysis for low-level debugging of applications during runtime.   The Unit Test Framework is designed for automated unit testing and requirements-based validation of software.

Feedback from users in highly regulated industries was one of the primary motivations for creating these products.  As we continue to invest in LabVIEW for large applications, we are benefited by feedback on these products and the needs of our users.

So to those of you who have had a chance to use these and similar tools, please use this community as an opportunity to share and exchange your ideas.  We look forward to hearing form you.

Architecting an Application to Avoid Spaghetti

One of the most appealing things about LabVIEW is that you don’t need to be a computer scientist to write fairly large and complex software. For many, their journey with LabVIEW starts in school or at a benchtop with a simple application to quickly acquire some data. Once they’re hooked on the ease of graphical programming, it’s only a matter of time beforethe ideas start flowing, and pretty soon they’re off developing amazing applications like a mind-controlled wheel chair, the world’s largest particle accelerator, or how about a 3D Space Ship that flies through a starflied.

The problem is that the same approach people use when throwing together a prototype or a proof of concept will land them in a world of pain if they don’t ever stop and consider fundamental questions like, “how should I architect this application?” All too often, I see the tangled mess of spheghetti code emerge as the result of thoughtless, or ill-planned development.

For most people, their very first experience with LabVIEW leads to messy, un-readible code.  Even LabVIEW gurus have humble beginnings.  The expert G developer, D Natt, was kind enough to send me a screenshot of his very first LabVIEW program. Let the image on the right serve as an example of what not to do. If you find yourself wishing you had 8 more screens to see a single block diagram, or if your block diagram looks anything at all like this one, you may want to consider giving more thought to the architecture of your application. As an exercise, see how long it takes to determine what the VI on the right actually does.

It’s important to realize that spaghetti code is not unique to LabVIEW. As someone who started with text-based languages, I’ve seen plenty in all sorts of different languages. The difference is that it’s a lot easier to write graphical code that will run, even if it’s completely illegible. When the result doesn’t work correctly or yields unexpected performance, it can be very difficult to debug and many prefer to point the finger at LabVIEW rather than acknowledge their own lack of foresight or experience.

So lets turn our attention to how we can architect our LabVIEW application. Start with the main problem you’re trying to solve and figure out what the software needs to be able to do in order to be considered ‘succesful.’ The criteria that emerges from this assessment will help you make informed decisions about how the code should be structured. This is, in many cases, the product of experimenting, prototyping and developing proof of concepts that highlight the areas of difficulty and help you understand what type of information or data will need to be shared between different ‘pieces’ of an application.  At this point, we need to take a step back and make sure we understand design patterns.

A ‘Design pattern’ refers to a template that serves as the building blocks for software. If you have an application that requires a responsive user interface, consider how many other developers have been faced with the exact same requirement. You’re not alone, and there’s no reason you should be starting from scratch. Design patterns are universal to programmers in any programming language. They save you time by helping you avoid reinventing the wheel and give us the solutions to common problems that have evolved over time to be the best, and most appropriate solution. If you’re new to design patterns, check out the File >> New dialog in LabVIEW (show on the left). This is a great place to get started with some basic design patterns that are very specific to LabVIEW. Be sure to read the descriptions to understand exactly what problemsthey can best help you solve.

I also recommend visiting expressionflow.com. Anthony Lukindo wrote an excellent, indepth article on the QSM-PC (Queued State Machine – Producer / Consumer) design pattern, which is a fairly common and very useful pattern for a-sychronous computations in a fairly large application.

For those of you familiar with text-based design patterns, AristosQueue posted a great article filled with examples of how to map classics like the Factory Design Pattern to LabVIEW using object-orientation.

The JKI State Machine also serves as another great template for developing clean code.

Architecting a high-quality piece of code ensures that it’s readible, scalable, maintainable and reduces the chance that errors or incorrect behavior will occur. I’ve focused a lot on design patterns, but don’t lose sight of the fact that just is one small piece of the puzzle. You’ll also want to think about how the application can be modularized and design APIs early on. Oh and of course, documentation is paramount.

One final word of caution: keep it simple and pick the archicture best suited to what you’re doing. But as always, have fun

Great Resource for Learning a Common Architecture for LabVIEW Applications

Anthony Lukindo wrote an excellent article on expressionflow.com that explains how to utilize a queued state machine architecture with multiple producer / consumer loops.  The example he uses in this article draws from several of the fundamental design patterns that should serve as the building blocks for almost any new LabVIEW application (see image below).

If you’ve never seen them, make sure you review the design patterns that ship inside of LabVIEW as starting points for your applications – even simple ones.  You can navigate several Frameworks for development by clicking File >> New in LabVIEW.  The dialog that will appear is shown below.  Note the descriptions for each design pattern under the image on the right.

.

If any of you want to add your own design patterns to this dialog, you can.  This is potentially useful for groups of developers who would need to use a common, custom template regularly in their work.

To add a template, follow the pattern used for the existing patterns, which can be found here: C:\Program Files\National Instruments\LabVIEW 8.6\templates\Frameworks\DesignPatterns

This should include a png thumbnail and *vit template file.  Don’t forget to enter descriptions in the VI Documentation Property so that users will know what they’re getting themselves into!