Thinking in G » LabVIEW Tips

The JKI State Machine makes its public debut

Jim Kring — Tue, 14 Oct 2008 06:50:31 +0000

I’m very happy to announce that JKI has released the JKI State Machine™ to the public as a free download. This is the very same template that is used by the JKI team, nearly every day, in our products and various projects.

This tool is the direct result of putting some of the best LabVIEW minds together for several years, tasked with the challenge of creating a LabVIEW architectural design pattern that would allow easy coding, readability, and maintenance. As you might imagine the JKI team has created something truly special that we hope will have a significant impact on LabVIEW users everywhere.

This has been in the works for quite some time and we’re excited that the time has finally come to share this tool with you, now.

Please take this challenge:

Download and install the JKI State Machine.
Watch this great video tutorial.
Take a look at how we refactored the 3-button dialog (VI that ships with LabVIEW) using the JKI State Machine.
Tell us what you think.

Planning for software reuse is easy — mining is hard

Jim Kring — Wed, 17 Sep 2008 17:17:23 +0000

One of the best places to find reusable code is in your old projects. However, “mining” your old projects for “reuse gems” (sorting through every VI, looking for sparkly little gems of general-purpose code that have immense value) is simply not an effective use of time or energy.

For example, if you were a miner looking for precious minerals, you would wouldn’t roam the countryside digging random holes in the ground. Rather, you would work smart — you would try to identify a geographic location with a very high natural concentration of precious minerals (based on a variety of clues). Guess what? This is exactly how you should mine for reusable code in your past projects. But, where do you start looking and what are the clues that will lead you to those reuse gems?

Here’s the secret:

While writing code, when you identify that you are writing a VI that is generic and has the potential to be reused, save it inside a sub-folder of your project folder called “Reusable VIs”.

If you adhere to this strategy, it will be very easy for you to come back later and find your reuse gems. And, before you know it, you will have what resembles a reuse library. Best of all, you didn’t even have to get your hands too dirty.

Note: As your reuse library grows (which it will if you use the planning techniques described above), you’ll need to start thinking about how to utilize your reuse library on multiple projects and share these VIs with other developers. Make sure you don’t get stuck in the pitfalls of a monolithic reuse library caused by copying your reuse library from project to project or by using the same version of your reuse library on each project. Create a VI Package and install your reuse library in your palettes using VIPM — it’s easy and simple.

I’d love to hear your feedback, so please feel free to leave a comment. For example:

Do you have a folder in your project where you put new, reusable VIs?
Do you think that this is a good idea, or do you have a better strategy?

What’s that .lvlps file next to my LabVIEW 8.6 project?

Jim Kring — Tue, 09 Sep 2008 08:00:39 +0000

I’m lucky enough to have a new project that will be developed in LabVIEW 8.6, so I get to use various new features (like Darren’s awesome Quick Drop tool).

When jumping head first into a new LabVIEW version there are bound to be some unknowns. In my case, I noticed that, after saving my project (.lvproj) file, an .lvlps file showed up in my project folder (right next to the .lvproj file).

What's that new .lvlps file?

So, I opened up the .lvlps file in a text editor and saw that it contained the following:

[ProjectWindow_Data]
ProjectExplorer.ClassicPosition[String] = “59,221,459,571″

It appeared to store some window settings for my project.

Figuring there’s probably something in the LabVIEW help about this file, I search the LabVIEW help for “lvlps” and found the “LabVIEW File Extensions” help page.

.lvlps

File that stores project settings that are specific to the local machine. You should not check .lvlps files into source control because .lvlps files contain settings specific to the computer you are using; for example, .lvlps files contain the local source code control configuration. LabVIEW saves .lvlps files when you save a project, and correctly renames the file when you rename a project. You can remove or delete .lvlps files without affecting the performance or behavior of a project because .lvlps files only contain project settings specific to the local machine. If you build an application, LabVIEW does not copy the .lvlps file into the built application.

Conclusion: OK, the .lvlps file contains my LabVIEW Local Project Settings. So, I don’t want to check it into Source Code Control, because each developer working on the project will probably have different settings and they aren’t really important enough to do change control.

Note: I kind of like how Apple Xcode project files (actually they are “package” folders — they just look like files, in the Finder) work. Your local Xcode project settings (like window positions) are stored in files that include the user’s name, so that you can, if you want, save them in source code control without developers overwriting each others’ settings. But, since Windows doesn’t really have a feature like “packages” (and LabVIEW needs to be multi-platform), I guess we’ll have to keep doing things the hard way.

LabVIEW 8.6 Quick Drop is awesome (and an unfair advantage)!

Jim Kring — Tue, 26 Aug 2008 08:00:42 +0000

I’m lucky enough to have a new project that will be developed in LabVIEW 8.6 (which was just released at NIWeek 2008), so I get to start using various new features like Darren’s totaly awesome Quick Drop tool. I’m really excited to start using Quick Drop, because I saw Darren (the LabVIEW R&D team member who created it) use it during the NIWeek 2008 coding challenge and he was able to code ridiculously fast. Seriously, you’ve got to see it to believe it. He’s even faster than me!

Quick Drop even works with OpenG VIs!
Now, that’s an unfair advantage.

In fact, I didn’t even bother to enter the coding speed challenge at NIWeek this year (which I won at NIWeek 2005), because I saw how fast Darren was coding during the NIWeek keynote (here is a video of it), and my LabVIEW skills were more than a little bit rusty at NIWeek 2008, as I hadn’t touched LabVIEW for 3 weeks (I was traveling for a wedding, and also visiting some of my European LabVIEW buddies, in France). Ya, excuses, excuses…

So, instead of competing, I hid in the JKI booth and pretended to be too busy to enter the contest. Of course, I didn’t want to loose my unofficial “fasted LabVIEW coder on the planet (or at least, NIWeek)” title in a head-to-head match up against Darren — the dude is fast! I wanted to at least have some time to practice using the Quick Drop tool and try to level the playing field. Then, I’d come back and challenge Darren to a fair match — pretty sneaky huh?

Speaking of fair competition, they weren’t even letting contestants use OpenG VIs in the coding speed contest, this year (I guess OpenG is an unfair advantage). Like Darren didn’t have an unfair advantage

All joking aside, the Quick Drop tool is amazing. It’s basically like auto-completion for text-based languages (so, it gives text-based programmers one less reason not to go graphical). Just press Ctrl+Space and then type the name of the VI or function you want to place on the Block Diagram. As the list of possible items appears, press Enter to select the top item in the list, or click on any other item, to place it on the Block Diagram. It really lives up to it’s name by allowing you to quickly drop nodes onto the block diagram. There’s no doubt it will become one of your favorite tools in LabVIEW, once you give it a try.

LabVIEW 8.5 Feature – For Loop Conditional Terminal

Jim Kring — Mon, 07 Jul 2008 07:00:20 +0000

One of the great new features in LabVIEW 8.5 is the addition of an optional Conditional Terminal on the For Loop structure. This allows you to easily "break" out of the For Loop, when an exit condition occurs. (In fact, text based programming languages often let you use the "break" command to exit a For Loop.)

In the screenshot below, you can see the difference between the classic For Loop and one with a Conditional Terminal.

Show the Conditional Terminal by right-clicking on the frame of the For Loop structure and selecting Conditional Terminal from the context menu.

When would you want to use the Conditional Terminal?

A For Loop are commonly used to iterate over an array of items, either operating on the items or checking for some condition within the items is satisfied (for example searching for an element with a certain value).

Sometimes, you might want to stop iterating over the items (i.e., break out of the For Loop) if:

your objective was satisfied -- e.g., you found the element (s) you were looking for), or
an error occurred during an iteration and it doesn't make sense to iterate over the remaining items.

Example 1 - Doing work in a For Loop that can generate errors

In LabVIEW versions <= 8.2, you might have implemented some code that looks like this:

This example, takes an array of file paths and deletes any files that are larger than some maximum file size. (Warning: you might want to be careful with such a VI, since it deletes files.)

You can see that, in the event an error occurs, the VI will not do any more work. It will just finish iterating over the array, passing the error through, before it exists.

Now, in LabVIEW 8.5, we might want to rewrite this example, by wiring the error cluster to the Conditional Terminal of the For Loop in order to stop it, in the event of an error.

The above code that uses the Conditional Terminal will finish sooner, in the event of an error, and is also much more readable.

Example 2 - Searching an array in a For Loop

Now, let's look at different example where we want to search an array for an element. Here is what our code might look like in LabVIEW <= 8.2.

And, here's how we could improve the performance in LabVIEW 8.5, using the Conditional Terminal.

By using a Conditional Terminal to stop the search once we've found the element we're looking for, we can exit the loop early and save CPU cycles.

What do you think about this new feature?

These are just a couple simple examples of how using the Conditional Terminal of the For Loop in LabVIEW 8.5 can improve the readability and performance of your code.

What other patterns of use have you identified? Are there any benefits or drawbacks that you can think of? I'm interested to know whether you've tried using this new feature and if you've had success with it, in improving your code.

Customizing the LabVIEW Palettes is (Ridiculously) Hard

Jim Kring — Tue, 17 Jun 2008 00:21:42 +0000

Have you ever tried editing the LabVIEW palettes in order to integrate your reusable VIs into LabVIEW? If you have then you've undoubtedly experienced the frustration of finding your VIs missing from your custom palettes, at some point.

Maybe you didn't realize one of the following facts about *.mnu files:

Tip: you can skip over this list, because it's probably completely irrelevant to you.

*.mnu files uses Symbolic Paths for linking to files some times
*.mnu (palette menu) files can be set to Synchronize with Directory
*.mnu files have both a Functions palette and Controls palette inside them
an LLB file contains a built-in palette menu
your palette was being stored in an LLB file that you overwrote
your palette was being stored in your My Documents LabVIEW data folder and didn't propagate with your reuse library folder
*.mnu files store deleted/hidden items
LabVIEW automatically creates dir.mnu files in folders found inside user.lib

except for folders that begin with an underscore ("_")

The "merge VI" setting is used to place a VI's contents when dropped, rather than placing a subVI

OK, you get the point. There's a lot you don't know (or more likely that you don't care to know) about *.mnu files. Whatever the reason, getting your reuse library into the palettes is way too hard. Only an unlucky few people in this world understand the idiosyncrasies of editing the LabVIEW palettes. Fortunately, a few of these people are at JKI working hard on a solution to this problem. And, the next version of VI Package Manager is going to make understanding how the LabVIEW palettes work completely irrelevant (unless of course, you work at JKI).

Imagine being able to get your reuse libraries into the LabVIEW palettes with the press of a button. And, that's just the beginning...

Have you tried editing the LabVIEW palettes? Were you successful? Do you feel that you understand how the palettes work? Are you looking for a better solution?

The Diagram Disable Structure causes bugs

Jim Kring — Sun, 11 May 2008 07:00:21 +0000

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!

In Place Element Strucure – Saves Time and Prevents Bugs

Jim Kring — Tue, 29 Jan 2008 07:01:40 +0000

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

Functional Globals in LabVIEW 8.5 – No Loop, No Joke

Jim Kring — Fri, 07 Sep 2007 15:20:39 +0000

As an April fools day joke this year, I posted a VI on LAVA that shows an implementation of a Functional Global that appears to not have any While Loop or For Loop around the Feedback Node. This trick was accomplished by making the While Loop very large (extending beyond the visible region of the Block Diagram) and coloring the loop’s border white

But, now in LabVIEW 8.5 you really can create a Feedback Node that is not owned by any loop! The screenshot below, shows an example of this.

It’s so beautifully simple

LabVIEW tip: easy unit conversion

Jim Kring — Mon, 25 Jun 2007 09:00:34 +0000

Recently, I wrote a short article on easy relative timestamp calculations, showing how to use LabVIEW’s built in units feature to easily add relative times to timestamps. Now, I want to show you another very useful technique that every LabVIEW developer should know — how to harness the built-in unit conversion capabilities of LabVIEW for converting units of numerics. Here’s how:

Simply cascade two Convert Unit functions where the first has the from units and the second has the to units (see the screenshot, below). Yep, that’s all there is to is

Note: in order for the above example to work, the original numeric must be a pure number (therefore having no units associated with it, already) which is usually the case.

If you liked this tip then you should check out, LabVIEW for Everyone. It’s chalk full of great LabVIEW tips and tricks that I’ve learned over the years.