So, how do you deal with all the unsaved VIs in your project that are not in an area that you “own”?  If you don’t save them, then LabVIEW will keep bugging you to save the VIs.  And, sometimes your LabVIEW code will even run slower until you save all your VIs.  But, if you do save these VIs, then it’s hard to tell which VIs that you’ve saved have “real” changes and not just recompile changes.  And, if you commit all the changed VIs, then you might increase the likelihood of creating a conflict with other developers.

Here’s a good process you can follow to deal with this issue:

1. First, commit your real changes, separate from the recompile changes.  This will give you a specific svn revision (changeset) associated with your real changes.
2. Then, save all the recompiled VIs and commit them.  For your commit log message, use “Recompiled due to typedef changes” (or similar).  This will indicate to other developers that the changes can be ignored, in the event that this revision conflicts with their own changes.
3. Finally, Alert your team that you have committed a recompile of code (with no real changes).  They can then easily resolve any conflicts, because they know that the commit contains no real changes.

Now, if you know that other team members are actively working on the code and you don’t want to inconvenience them with having to deal with conflicts, you can defer the recompile until a later time or schedule a time for the recompile with your team.

Note: Even if you use a locking system (such as svn locks or a check-in/check-out SCC model) where files for which you don’t have the lock are read-only, you will still have the slow-down issue and will periodically want to do save all to recompile.

Have you had this issue?  What solution or process do you use?

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?

 

The slow death of the monolithic reuse library

• As the monolithic library grows large in size, it becomes hard to distribute -- it consumes large amounts of disk space and network bandwidth
• Users must choose a single version of the entire monolithic library for use in their projects -- it's all or nothing 

• Users fork the reuse library -- Users make a copy of the library locally in their project and modify it.  They possibly only copy subsets of the reuse library, breaking the monolith.
• Users stop upgrading to newer versions of the reuse library -- Users forever stick with an out-of-date, stagnant version of the reuse library, even though they might be able to take advantage of improvements made to some parts of the library.  The cost of upgrading, due to the possibility of breaking code is not worth the possible benefits of the new features and fixes.

• Improvements to the library stop, because nobody ever upgrades to newer versions of the library.
• Improvements to the library happen in project forks.  Either these changes never make their way into the main reuse library or are copied between projects adding tremendous uncertainty and ambiguity as to which versions of library components are being used.

Enter the modular reuse library

•  
  • downloads are faster and less project disk space is consumed
  • upgrades can be done on a per-component basis, minimizing the risk of upgrades and the amount of testing required to re-validate code

• there are more software products for library developers to manage -- each has its own life-cycle
• there are more components for users to obtain -- these have to be found and downloaded, and if one component depends other components, these have to be identified and obtained, too 

VIPM 2.0, a modular reuse library development tool for LabVIEW

• 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).

Monolithic vs. Modular Reuse Libraries

src="http://thinkinging.com/wp-content/uploads/2008/02/el_cap.png" style="padding-top: 10px;" align="right" border="0" hspace="4" vspace="0"> zid="34"> Monolithic wins the short race

• 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. zid="55">

But, there are scalability concerns

The solution is a modular system

What is your experience?

• 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?

• 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.
  

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

• Programming Strategies for Multicore Processing: Data Parallelism
• The Future of Programming and Innovation
• A Picture of the Multicore Crisis
• You’ve Already Had a Multicore Crisis and Just Didn’t Realize It!
• NIWeek 2007

One the reasons that NIWeek 2007 was the Best NIWeek Ever was that I got to present four times! I gave the following two presentations (I presented the latter at three different times):

• Using Free and Open Source LabVIEW Software
• Developing Commercial Software Applications in LabVIEW

The first presentation, “Using Free and Open Source LabVIEW Software“, was given on Alliance Day (Monday, Aug. 6th, 2007) and was not open to the general public. However, the material is not confidential and I’m happy to make available everyone. This presentation discussed the different flavors of open source software licensing, why open source is an important part of our lives, and how LabVIEW developers can leverage open source software.

The second presentation, “Developing Commercial Software Applications in LabVIEW“, outlines some key issues that LabVIEW software developers should consider if they are thinking about selling their software. These are things that JKI had to learn about from our experiences working on our own commercial software product, VI Package Manager. Certainly, this presentation doesn’t cover every aspect of commercial software development, but I only had 45 minutes — and this topic could easily fill a whole book.

Soon, JKI will be making Michael Aivaliotis’ presentation on XControls available as a video — that’ll be very exciting. Michael’s presentation was really good — I heard that someone comment to him that it was the best NIWeek presentation given by a non-NI presenter in the 10 years they have been coming to NIWeek. Hopefully I didn’t set your expectations too high (I’m really excited, too, because I didn’t get to see Michael’s presentation)

In order to decide whether you should be cross-platform compatible, first consider whether you need to. For example:

• Does your application depend heavily on platform specific components that cannot be found on other platforms or implemented in pure G (LabVIEW)?
• Is it targeted at functions that only exist on a single platform (for example, a tool for creating Excel reports)?
• Is there a market (paying customers) for your application on each of the platforms?

I’d like to throw in some useful data. JKI’s market research for VI Package Manager (VIPM) indicates that:

• Windows has 98% of the market share of LabVIEW installations,
• Mac has 1.1%, and
• Linux has 1.0%.

With numbers like that, it might not make direct business sense to support those platforms. However, there is a lot to be said for having cross-platform support. For example:

• It makes it easier to migrate to new platforms that might show up in the future (including new versions of Windows, such as Vista).
• It is a good exercise and you learn more about cross-platform considerations.
• It may uncover bugs by exposing your application to new operating environments.

Another reason that that we’ve chosen to support Mac and Linux on VIPM is that it is a tool for obtaining and installing the OpenG (open source) VI reuse libraries. JKI is very passionate about the LabVIEW community and we want Mac and Linux users to be able to use OpenG, too. Some of the most passionate LabVIEW users are using LabVIEW on platforms other than Windows.

In order to make this decision for your commercial software product, you’ll have to weigh all the factors and decide whether it makes sense for you. In my opinion, the benefits of being cross-platform may not be immediately tangible, but it does pay off in the long run.

The basis of my argument is that, behind the scenes, LabVIEW accesses a VI’s block diagram to recompile it for other platforms (operating systems and processors) and newer LabVIEW versions. This means that:

1. Some people within NI can access your block diagrams.
2. Someone outside NI, if they were sufficiently clever (and there are many clever people in this world), might be able to fool LabVIEW into unlocking your VI’s block diagram.

Password protecting VIs is a scheme that relies on “security through obscurity”, which is, IMO, a very bad idea. (But, don’t just take my word for it — google “security through obscurity” and read some of the articles.)

So, why do I bring this up? LabVIEW is becoming more and more of a general purpose programming language and many people are building commercial products using LabVIEW, including reuse libraries and components. Customers of LabVIEW reuse libraries and components expect to be able to use them in future versions of LabVIEW as well as use them on any platform or execution target supported by LabVIEW (such as LabVIEW RT and FPGA targets). The only practical way for vendors to achieve this is to ship the reuse libraries with password protected block diagrams.

What would happen if, some day, a hack were to be discovered that could unlock the block diagram of any VI? What would be the implications for NI? What would be the implications for LabVIEW users? What would be the implications for LabVIEW tools vendors? I’ll bet you that many people would be VERY pissed off and there might even be legal actions taken.

The longer we rely on the fallacy of password protected VIs, the more catastrophic the consequences to all of us, once the scheme is cracked.

So, what now?

1. First, do not rely on password protection for any VI with intellectual property that must not be made public.
2. Second, demand (from NI) a better scheme for cross-platform execution of VIs.

So, what can NI do to devise a better scheme to lessen the need for distributing password protected VIs?

1. Give VIs the ability to store the executable code for multiple platforms and execution targets
2. Use platform-independent byte code that runs on a LabVIEW virtual machine
3. Support old versions of VI executable code (for example, a VI saved in LabVIEW 6.1 on Windows without a block diagram should be callable by LabVIEW 8.5 on Windows). This can almost be done right now by building your reuse library into a DLL and providing VIs (with source code) that wrap the DLL. However, this technique still requires one version of the DLL for each platform (Mac, Linux, and Windows) and would not work well for targeting LabVIEW RT or FPGA.

Is the world coming to an end? No, not really. But, things are getting worse as time goes by. The longer people rely on password protected VIs and the more popular LabVIEW becomes, the larger the consequences when the scheme is eventually cracked.