Ideas in Wiring

Deploying LabVIEW Code

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.

1. 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.?
   
2. What if you want to bundle up the application into one file rather than a collection of files?
   
3. What if you want to make an application that can run without LabVIEW?
   
4. What if you want to make something small, without all of the source code in it?
   
5. 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:

1. 
   
   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)
   
   
2. 
   
   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.
   
   
3. 
   
   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
   
   
4. 
   
   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
   
   
5. 
   
   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.

posted by Joel @ 8:25 AM