Thinking in G » Rants

If you can’t think of something great to say…

Jim Kring — Mon, 09 Feb 2009 01:00:02 +0000

Hopefully, I’m not contradicting myself right now by writing this post, but I think it is worth stating:

If you can’t think of something great to say, don’t say anything at all.

Joel Spolsky just pointed out a perfect example of how being redundant and wordy can make your product look lame.

In today’s world of information overload, getting noticed and remembered is about being remarkable and saying more with less.

This is true for many things, including: blogs, websites, emails, and even software installers.

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?

A Challenge to NI: Use your Application Builder

Jim Kring — Tue, 27 May 2008 07:00:51 +0000

I'd like to challenge developers at NI to find more ways to incorporate stand-alone (built) LabVIEW applications into their internal systems and processes.

One of the major pain points in my day-to-day use of LabVIEW (which I love) is building stand-alone applications. I suspect that the reason this is so painful for me is that (in addition to my use cases being fairly advanced) most of the developers at NI who are on the LabVIEW development team probably don't build applications using LabVIEW -- they are not eating their own dog food.

For example, LVOOP (native LabVIEW Object Oriented Programming) dynamic method overriding requires VIs of the same name, but it is impossible to store two VIs of the same name inside an EXE? How could this feature conflict possibly happen? I suspect that nobody actually tried to build an application that used LVOOP until well after the feature was implemented. What's even crazier is that NI was working on this feature for many years, before it was released.

As time goes by, more people within NI are developing code in LabVIEW on a daily basis. However, I'll bet that most of them never actually use the application builder to build stand-alone applications, since most LabVIEW code is shipped in source form and never gets "built" -- it's just one big, monolithic reuse library.

So, I'd like to challenge developers at NI to find ways to incorporate stand-alone (built) LabVIEW applications into their internal systems and processes. It will make a huge difference to your customers.

I'll have you know that I'm committed to eating my own dog food, too. At JKI, we work very hard to use our own products in a variety of ways:

EasyXML is being used inside VI Package Manager (and other JKI products and projects), for reading and writing XML files.

VI Package Manager (VIPM) is used to install EasyXML, as well as manage the LabVIEW configuration needed to develop and build EasyXML (and every other JKI product and project).

I'm only telling you this, because I'm committed to practicing what I preach. And, we're working on a new version of VIPM that is going to take this concept to a whole new level -- more on that, later.

I should close by saying that I know some of the people who work on the LabVIEW application builder and LVOOP and they are all very nice/smart people who are very competent LabVIEW developers and software designers. The only problem is that they are probably not eating their own dog food. NI has stated that they are committed to this, so I want to make sure that this is one area they do not neglect

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!

Did National Instruments forget about Virtual Instruments?

Jim Kring — Wed, 23 Jan 2008 03:00:53 +0000

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.

Using XML Data in LabVIEW is Hard

Jim Kring — Tue, 22 Jan 2008 00:00:34 +0000

XML, which stands for eXtensible Markup Language, is text-based data format (or language) that is human readable and can be used to create arbitrary data structures. It is designed to facilitate sharing structured data across many different systems. Here is a simple example of XML data:

John
Doe

Figure 1 – simple XML data representing a person

You’ll notice that the data looks a lot like HTML, or Hypertext Markup Language (and in fact, XHTML is XML formatted data). In XML a “schema” defines the set of the possible elements and the constraints on those elements (what sub-elements and attributes they can have).

LabVIEW’s XML Schema

There are several tools for dealing with XML data in LabVIEW. First off, LabVIEW includes some VIs for Flattening and Unflattening LabVIEW data to and from XML. Figure 2, below, shows how to use the Flatten to XML function to convert a cluster to an XML string.

Figure 2 – LabVIEW’s Flatten To XML function is used to convert any LabVIEW data to an XML string.

What you’ll notice is that LabVIEW uses a special XML schema for flattening data. The schema that LabVIEW uses is defined by the XSD file located beneath the LabVIEW installation, here: \vi.lib\Utility\LVXMLSchema.xsd. Generally speaking the LabVIEW XML schema uses the following format:

<{Data Type}>
{Data Label}
<{Attribute Name}>{Attribute Value}
{Data Value}

One of the disadvantages of this format is that it does not allow you generate or parse arbitrary XML. For example, the XML data shown in Figure 1, which represents a person, does not conform to the LabVIEW XML schema, so we cannot use LabVIEW’s Flatten To XML or Unflatten From XML functions to generate or parse that data.

Creating Arbitrary XML Data

A natural and straight-forward approach is to use the Format into String function to create XML data when some special schema is required.

Figure 3 – Converting LabVIEW data to an arbitrary XML schema

The downside of the technique shown in Figure 3 is that whenever we want to change the XML schema we have to change the items in the cluster and in the format string. And, if we are changing the number of items in the XML, we have to add or remove items on the Unbundle by Name and Format into String functions — that’s a lot of work and leaves a lot of room for mistakes (a.k.a. “bugs”).

Parsing Arbitrary XML Data

Converting arbitrary XML data back into LabVIEW data is a bit more complicated than it is to convert LabVIEW data into arbitrary XML. For this task, we really need to use an XML parser. An XML parser analyzes an XML string and creates a document object that can be accessed using a Document Object Model, or DOM, API. There are a variety of XML parsers available, including one from National Instruments which is bundled with the LabVIEW Internet Toolkit. Also, the Microsoft XML Parser is available from LabVIEW via ActiveX and .NET and usually pre-installed on most Windows systems (and if it’s not, you can easily download it for free).

Figure 4, below, shows how to read an attribute of an XML element using the functions provided with the LabVIEW Internet Toolkit. As you can see, the process is quite tedious. And, we haven’t even extracted the person’s name, yet. That is even more tedious!

Figure 4 – Parsing an XML string to extract an element’s attribute

Conclusion

Dealing with arbitrary XML data (that does not conform to LabVIEW’s XML schema) is generally very difficult, requiring a lot of duplicate and excessive code that is tedious and risky to maintain. XML parsers do the work of validating and parsing the XML, but there is usually a lot of additional coding required to extract element and attribute values from the document object. Certainly, there must be an easier way…

Are you using XML in your LabVIEW applications? Are there specific XML schema that you have to use? Which aspects of working with XML data do you find difficult? What solutions have you found?

[Update: I have posted a follow-up to this article called Using XML Data in LabVIEW Just Got Easier. I hope you enjoy it.]

Rant: Why don’t desktop applications have a “rename document” option?

Jim Kring — Sun, 07 Oct 2007 22:02:20 +0000

One of the things that annoys me about most software applications is how the File>>Save As... dialog doesn't have a "rename" check box (or some other easy way to rename and/or move a file on disk).

When renaming a document, you usually have to do it one of two ways:

1) Close the document, rename it on disk, reopen the document

2) Select File>>Save As..., rename the document, and then go into the folder where the old file exists and delete it.

Each of these two methods significantly breaks the user's work flow, which is a terrible thing to do. It can cause you to loose the context of what you were doing and it increases the likelihood of making a mistake (like deleting the wrong file, etc.)

Google Docs has a rename document feature and it is really nice. I guess that this was more obvious to web app developers (especially the smart folks at Google), since the user doesn't really interact with files on a PC and the fact that switching between web pages to rename a file is even more tedious than doing it on a desktop computer. But, desktop apps are going to be around for a while, so it would be nice we could standardize a document renaming feature.

Also, LabVIEW (starting in version 8.5) has a nice way to rename files from the File>>Save As... dialog. And, I think I can take a little credit for inspiring this, since I created a LabVIEW extension that adds a File>>Move/Rename As... menu-option back in 2003. Now that I think about it, that was before Google Docs, too