Thinking in G

One LabVIEW features that I both love and hate is the Diagram Disable Structure.  I love the fact that you can comment out code, especially broken or stub (unfinished) code.  However, I hate the fact that output tunnels of the Diagram Disable Structure are set to "Use Default if Unwired", because it causes buggy code.  Here's an example...

Let's say that we have the block of code and want to comment out a VI.




So, we wrap the VI in a Diagram Disable Structure.




Everything is good, now, right?  The VI's "Run Arrow" () button is not broken, so surely everything must be OK.

WRONG!!!

If we show the "Enabled" frame of the Diagram Disable Structure, we can see that we're not passing though the DAQmx task reference and the error cluster.  Our code won't work.




To fix this problem we have to manually wire the DAQmx task reference and the error cluster.



Now, we're good.  But, we could have avoided this whole problem if the Diagram Disable Structure didn't set all the output tunnels to "Use Default if Unwired".

Presumably, this "feature" (although I like to think of it as a bug) was chosen because users's code doesn't break (at least not at edit time) when they wrap a block of code in a Diagram Disable Structure. Personally, I'd happily accept broken code at edit time to avoid code with bugs -- the choice is obvious to me.

A good solution would be for the LabVIEW designers to make the Diagram Disable Structure intelligent enough to automatically wire any output tunnels to input tunnels that are of the same data type and vertical position.  Now, that would be cool!

LabVIEW Developer Education Day is coming up soon (May 22), here in the San Francisco Bay Area.  The good news is that National Instruments will be giving free Certified LabVIEW Associate Developer exams at the event, so, if you're not yet certified, this is a great way to do it.  If you've read my blog, you know that certification matters (to me).

Recently, I've gotten a couple emails from friends about how they should study for the exam.  Here are my thoughts:

First, I recommend my book (of course), LabVIEW for Everyone.  There's info in the preface on the LabVIEW exams and how to use the book as a study guide.  We worked directly with National Instruments' training department to make sure that the book was a good resource for the LabVIEW certification exams.

Next, I recommend that you take a look at the LabVIEW tutorials on the LabVIEW wiki and the exam prep resources provided by NI (especially, the How Can I Prepare for the Certified LabVIEW Associate Developer (CLAD) Exam? page).  When you have studied and you want to test your skills, here is an online quiz and sample exam you can take.

If you are taking the exam, good luck.  Study hard, practice, and I'm sure you'll do well

This is a special, community announcement.

LAVA <http://www.lavag.org> is a free, independent LabVIEW community and discussion forum. It's a resource that I couldn't live without, so please help them reach their 2008 fund-raising goals so that we can all continue to enjoy this extraordinary LabVIEW community resource.

Please click on the button, below, to make a donation to LAVA via paypal.

There's a new LabVIEW (video) blogger named Ben Zimmer, over at the LabVIEW Mastery Tip Jar Blog, who has been creating some useful videos about LabVIEW.  His most recent video blog post about OpenG is great.  It gives a very quick introduction to OpenG and how to install it and then shows some of his favorite OpenG VIs in action.  As you all know there are many OpenG VIs I couldn't live without.  It's nice to hear that there are others out there that share my passion

Ben, welcome to the LabVIEW blogging community and thank you for helping to raise awareness for OpenG and the LabVIEW community.

As I've mentioned before, using XML data in LabVIEW is way too hard.  And, according to this poll, 7 out of 10 LabVIEW developers think so, too.  LabVIEW's built-in XML schema and support functions are not at all useful for generating and parsing XML schemas defined by others.  And, the various tools available to LabVIEW developers for generating and parsing XML schemas defined by others are not easy to use.

For example, there's really no simple and maintainable way to write the code necessary to generate and parse the following XML:

<Person Nationality=”US”>
  <Name>
    <First>John</First>
    <Last>Doe</Last>
  </Name>
</Person>

The existing tools require understanding way too much about the details of the XML language (e.g., DOM) and get in the way of the average developer doing useful work with XML data.  For examples, this is the code required to read only a single attribute of an XML entity:



When I think easy, I imagine a tool that will allow the developer to:

1.) define a simple LabVIEW data structure that is analogous to an XML data structure of interest and
2.) use it to generate and parse the XML data.

For example, generating and parsing XML data in LabVIEW should be as easy as creating a cluster:



The good news is that JKI Software has just released such a tool that lets you work with XML by simply creating a cluster in LabVIEW.  For example, you can create an XML playlist with just one VI and a cluster, as show in the screenshot, below.



And, parsing XML is just as easy, as you can see in this example that downloads the LAVA RSS feed and parses the data into a cluster.



This new tool is called the EasyXML Toolkit for LabVIEW and is a low-cost ($39 introductory price) toolkit that can be installed using VI Package Manager.  And, you can even download the demo for free, using VIPM.  Now, that's easy.

LabVIEW for Everyone, 3rd edition is now available on O'Reilly Safari Books Online and the Amazon Kindle . I haven't tried the Kindle yet, but it looks very promising.

If you’ve gotten past the horrendously boring title of this article, you probably know a little bit about software reuse libraries.   You probably even contribute to a software reuse library (a personal reuse library or one belonging to your organization).   So, I won’t go into the benefits of code reuse and the pitfalls of reinventing the wheel -- I’ll jump right in and get to the meat of the matter.   Let’s consider two strategies for managing a software reuse library.

Monolithic vs. Modular Reuse Libraries

A monolithic reuse library is one where all components of the library are released at the same time as a single unit. 

A modular reuse library is one where several individual libraries are released at different times, independently as separate and distinct units.

For example, LabVIEW ships with a monolithic reuse library called vi.lib , the built-in library of VIs found beneath the <LabVIEW>\vi.lib folder.   These VIs are all kept under the same revision and release cycle as LabVIEW, itself. You'll only get new versions of these VIs when LabVIEW itself is released -- it's monolithic, all or nothing.

National Instruments (the makers of LabVIEW) also sells modular libraries, such as the LabVIEW add-on toolkits.   These libraries each have their own version, different from LabVIEW’s, and are installed separately.   These add-on libraries have dependencies on vi.lib VIs , but rarely have dependencies on other add-ons.

Monolithic wins the short race

Most LabVIEW developers and teams find that the overhead of the modular reuse library is a show-stopper , right out of the gate.   It’s too much work compared to the much-simpler monolithic reuse library, which can be developed and deployed as a single unit. 

The monolithic reuse library is alluring, because it’s: 

• easy to distribute – it might be delivered as a single ZIP file, or a checkout from source code control.
• easy to keep track of which version you have – there is a single version number for the entire reuse library (perhaps a date stamp)
• easy to manage, since there are no external dependencies – every VI that you need is kept within the reuse library, so users will never have missing VIs.
  

But, there are scalability concerns

After the monolithic reuse system is up and running, several problems loom on the horizon that will slow down progress.   Soon, the reuse system might become a victim of its own success and get harder and harder to maintain as the code-base grows.

The solution is a modular system

The solution to the scalability issues (number of developers, number of project, number of reuse VIs ) is to make the reuse library modular.   The only other option is to stop improving the reuse library – but, we can’t do that, of course. 

In an upcoming article, I’ll talk about the specific shortcomings of the monolithic reuse library and how the modular approach can solve them. Of course, this will introduce some new problems that will have to be addressed.

What is your experience?

Please share your experience with LabVIEW software reuse.  I'm curious to know the following:

• Do you have an effective LabVIEW reuse system?
• What does your system look like?
• Is your system monolithic or modular?
• How big is the library?
• How many developers contribute the the library?
• How do you manage your installation?
• Are you feeling any pain points?
• How do you plan to solve them?

---

El Capitan photo courtesy of Mike Murphy.

I'm happy to announce that JKI has shipped the 1.1 release of VI Package Manager , a tool that makes it simple to find, download, and install reusable LabVIEW VIs directly into the functions palette. We're very proud of this release, as it adds an important new feature: configuration management.

In this release, we've added a new construct called a VI Package Configuration file, which allows you to save and recall the state of LabVIEW for each of your projects (meaning, which libraries are installed).
And, we've even added support for saving the actual package files inside a VI Package Configuration file, so that you can easily store the packages inside your project folder (and thus use your source code control system to make the packages available to other developers and computers).


Configuration management was a very important problem for us to solve, since we work on a lot of different LabVIEW projects, both internally at JKI and for our clients. We can't afford the risk of not knowing which versions OpenG and other library VIs are required for a given project. So, before we start working on a project, we use VI Package Manager to apply our project's VI Package Configuration file.

The designers of LabVIEW added a new function to LabVIEW 8.5 called the In Place Element Structure . The idea behind this structure is that it allows memory efficient operations on sub-elements of compound data structures like Clusters, Arrays, Variants, and Waveforms. However, it also has a the unintended benefits of saving developers time and helping them prevent bugs . Let me explain...

Example 1 - Modifying an Element of a Cluster

Traditionally, if you wanted to perform an in-place operation on an element of a cluster, you would unbundle it, operate on it, and bundle it back into the cluster, like this:



And, here is how you would do it with an In Place Element Structure :



Example 2 - Modifying an Element of an Array

Traditionally, this is how you would convert one element of a string array to lowercase:

" zid="49" />

And, here's how we would do it using an In Place Element Structure :



Conclusion

While the difference between the traditional way of performing an in place operation doesn't look remarkably different from how you would do it with an In Place Element Structure , there are some real advantages to using this new structure:

• Saves time :   fewer nodes, fewer wires, fewer mouse-clicks
• Code is cleaner : fewer wires
• More maintainable : The unbundle and bundle nodes of the In Place Element Structure stay synchronized (you change one and the other changes to match it).

These may not be the reasons that LabVIEW's designers added the In Place Element Structure to LabVIEW 8.5, but these are the reasons that I use it. I'm constantly trying to find ways to code faster, cleaner, and with fewer bugs. In fact, I'm surprised that the only place to find this structure is buried down in the Programming>>Application Control>>Memory Control Functions palette. I always expect to find it in the Programming>>Structures palette and I'm disappointed each time

It’s been over 20 years now that National Instruments has been refining LabVIEW as a powerful test, measurement, and automation platform, as well as a general purpose graphical data flow programming language. For many years, LabVIEW’s slogan was " the software is the instrument ". NI even named the basic building block of LabVIEW programs the "virtual instrument" (or "VI" for short). But, after using LabVIEW now for well over a decade, I have to wonder…

Why is it so hard to create virtual instruments in LabVIEW?

Just to be clear, when I say it’s difficult to create virtual instruments, I’m not taking about VIs (the basic building blocks of LabVIEW programs) with their Front Panels and Block Diagrams. I am talking about software that behaves like a instrument . Let’s take a step back and look at what I mean by this.

A traditional instrument is a physical device that sits on the lab bench or in a rack. The traditional instrument:

• has statefulness — it remembers whether it’s turned ON or OFF, it knows its active configuration settings, etc.

• can do work asynchronously — you can ask it to reset, acquire some data, perform analysis, etc. You can ask it when it is finished with the asynchronous work and then ask it to send you the data.

• can have multiple instances — just order another one from the catalog and set it on the lab bench, right next to the first. You can give each physical instrument a name, such as "multimeter 1" and "multimeter 2" — you might even choose to use a label maker to print the name and stick it onto the front of each instrument, so that you never forget which one is which.

• can communicate with other software and instruments — TCP-IP, RS-232, GPIB, etc. via SCPI, LXI, or other protocols.
  

OK, you get the point — you know all about traditional instruments.

Now, let’s say that you want to create a virtual instrument — meaning, you want to create software that uses modular hardware that can do everything that a bench-top instrument does. You want to use a data acquisition (DAQ) device as modular I/O and then write some software that uses the DAQ device to implement the functionality and behavior of a traditional multimeter. Where do you get started? First, let’s take inventory of the requirements:

• Statefulness
• Asynchronous processing of tasks
• Multiple named instances
• Ability to communicate with client software using industry standard protocols such as SCPI, LXI, etc.

Hmmm, it’s starting to sound like we need some kind of by-reference object-oriented framework…

Now, I’m not going to get into the whole by value vs by reference OOP debate. All I’m saying is that almost every LabVIEW developer who creates a non-trivial automation or control system application will want to create a virtual instrument with all of the features that I’ve identified above and that these features sound a whole lot like by reference objects.

Where did NI drop the ball with virtual instrumentation?

Did the concept of a VI as a Front Panel and Block Diagram distract them (and us) from what we really need from a virtual instrument? Does NI’s marketing mantra shift away from "the software is the instrument" to "design, develop, deploy" imply that they aren’t really concerned with the developers ability to emulate pysical hardware using software (after all, NI does want you to buy their hardware)? Is NI simply out of touch with the types of large systems that software developers create using LabVIEW? Or, is NI working on a by-reference framework that will allow us to create our own, stateful, asynchronous, multi-instance, by reference virtual instruments that can communicate using a variety of protocols and physical transport layers?

In a future article, I’ll describe more about the features that I’m looking for in a virtual instrumentation framework and how NI could stand to benefit from implementing something like it.

PS - After writing this, I did happen to find somebody at NI talking about the Growth of Software-Defined Instrumentation . Hopefully that’s a good sign.