I admit to spending much more time than seems reasonable reading Slashdot. Is following commentary on Apple’s new MacBook Pro (horrible name but I want one anyway) really that good a use of my time? Sometimes, your brain just needs a break. Other times, you stumble across really good articles (check out Guy Kawasaki’s new blog). Joel on Software is running an update to the book he wrote years ago on design. In the introductory article, he mentions
Every new feature is a tradeoff, between the people who could really use such a feature and the people who are just going to get overwhelmed by all the options.
...even if you think your new feature is all good and can't hurt because "people who don't care can just ignore it," you're forgetting that the people who allegedly don't care are still forced to look at your feature and figure out if they need it.
LabVIEW is running into a bit of this. After 15 years, we’ve added a heck of a lot of things that are useful or even necessary for developers. They hopefully make your job easier or allow you to get things done faster. However, for those of you who are brand new to LabVIEW, all of those cool little options must be overwhelming. Sometimes we get a bit nostalgic for “LabVIEW 2” because it was simple.
Well, we’ve gotten a chance to think about what LabVIEW would be like if you strip it down to the basics and you can get your hands on it real soon now. My latest secret project is finally starting to reveal itself with the announcement of the Lego Mindstorms NXT. There are very few public screenshots of the software, but here are a few
It will be very interesting to see the difference between a 12-year old using LabVIEW (via RoboLAB) and that same child using the Mindstorms product. I’ll bet we’ll learn how to make your lives easier too.
Technocrati Tags: User Interface, LEGO, Mindstorms, LabVIEW
One of the interesting characteristics of LabVIEW is that the source code to the application and the object code of the application are stored in the same file on disk. In languages like C or Java, the text file with the source code is run through a compiler to generate the code that can be executed by the computer. This code is stored in a separate file, an object file (the .o file) on disk. Once the source and the object files exist on disk, there is no real relationship between the source files and the object files any more.
LabVIEW comes from a different heritage. The code for the VI is stored in the VI file itself. Rather than the object code being a separate representation of the application, it’s more like a cache of the results the last time the VI was run through the compiler. There is no explicit “compile” step in LabVIEW. You hit run and it works, the rest is all magic under the hood. The executing code re-uses the “source code” of the application when it is running. It may open the front panel (which is, after all, part of the source code of the VI) and display it. You can open the block diagram of the application when it is running and probe wires.
As a LabVIEW user, then, you are only dealing with one file, the .vi file. It contains the ingredients you need to run the application and it contains all of the information LabVIEW needs to rebuild itself if the environment changes. You can give the file to someone else and they can use it. You don’t give someone else an object file and then have them say “but I want to modify it, can I have the source code?” It’s a very collaborative way of providing code.
However, the ease of distribution of a LabVIEW program does expose you to some interesting phenomenon.
- What if you don’t want to give the person the source code? You don’t want them to see how you made the application.?
- What if you want to bundle up the application into one file rather than a collection of files?
- What if you want to make an application that can run without LabVIEW?
- What if you want to make something small, without all of the source code in it?
- What if you want to store the source files in a version control system?
As LabVIEW evolves, people want to do more and more with it. Thus, we need to keep up with the times. The current answers to these issues are:
If you don’t want to give the person the source code, you have two options. The first option is to password protect the VI
. The second is to remove the source code of the VI. In versions of LabVIEW before 8, you could do a “save with options” to do this. In LabVIEW 8, you make a source distribution target and use the “Customize VI Settings” button to tell it to remove the block diagram (and/or front panel)
Normally, an application is a collection of VI files. You can manually take all of the files and put them into some archive such as a ZIP file, or you can save them into a LabVIEW LLB file using a deployment target.
LabVIEW VIs can be built into stand-alone applications. For that, you build an application using the application builder. This used to be a stand-alone tool but is now integrated into the LabVIEW 8 project as a deployment option
Making a small application is the same as items #1 and #3. The application builder will strip out all of the block diagrams and front panels automatically or you can do it manually through the source distribution as described in #1
Storing files in version control is still the most common question we get around this issue. LabVIEW does integrate with version control systems
. However, a common problem is that the VI files may have to change even if the source code doesn’t change. This means that you have to check out the file and check it back in even though the source code didn’t change. It’s a known issue that we continue to look at.
Technocrati Tags: LabVIEW