Why does LabVIEW give all my VIs ‘dirty-dots’ when I only changed one VI? (and how do I prevent this)


For those of you using source code control (I hope that’s everyone reading this), you may have run into this situation before: You make a simple, seemingly trivial change to one your VIs, and then LabVIEW starts asking you to re-save a dozen other VIs you didn’t touch.  Although this may befuddle you, it may go unnoticed for the majority of you reading this.  However, if you have to justify, track or even validate any and all changes to your source code, this can be extremely frustrating.  In addition to the fact that you have to check-in ‘modified’ VIs that you didn’t touch, this may raise some red-flags in a regulated environment, especially if someone else insists on examining your changes.

So first off, why does this happen?  Unlike other programming languages, the VI file format not only contains the source code, it also contains the compiled code (also referred to as object code).  For the vast majority of LabVIEW users, this simplifies application management and avoids having to keep track of the compiled code separately.  However, one simple change may cause LabVIEW to recompile other parts of your application – this can be attributed to optimization routines and the propagation of datatypes.  When this happens, the new object code is saved into the respective VIs, which have then been modified by LabVIEW, even though the source code hasn’t changed.

LabVIEW 2010 introduced a new capability to address this problem.  You can now remove the object code from VIs and store them separately on disk.  As a result, the only thing that can cause a change to a VI is the modification of source code, which is what anyone from a text-based background would expect.

The LabVIEW 2010 Help documents how to turn this on for a VI or even the contents of a Project file, but we’ve had several requests from users to enable this feature by default so that any and all new VIs are saved as ‘source-only’ VIs.  Thankfully, this can be done using an ini token: SourceOnlyEnvironment=True.  As with any ‘secret’ ini token, it’s not supported and it’s considered experimental.  One side affect to be wary of is that you cannot create a normal ‘uni-file’ with this setting enabled (the VI Property setting is ignored), which is required for dynamically loaded VIs.

Visit the LabVIEW 2010 Help for more information on this topic.

UPDATE: Many people have asked why this isn’t just on by default in 2010.  The original plan was that it would be on by default, but benchmarks showed that the operation required to check the cache of object files ‘mod date’ slowed down load time to the point that we were not comfortable turning it on for everyone.  We also weighed the ramifications for people who were calling VIs directly from a built executables (not a recommended practice, by the way).  Because the RTE does not have a compiler, the executable would not be able to create the object files for source-only VIs and would not be able to run source-only VIs.  As a result, you either have to build VIs into something that includes the object files, or include them with the executable when it’s built.  If this affects you, consider packaging your VIs as packed project libraries (new in 2010), DLLs, separate executables or including them in the main executable.  Before you protest, consider the fact that you would never call a .C file directly from an EXE.

Anyway, R&D has been hard at work looking for ways to address the problems we saw with load time and they’ve come across some very promising solutions using databases.  Without making any guarantees, I strongly encourage everyone to assume that this feature will be the only available option for future versions of LabVIEW.  The bottom line, is that if you have applications you’ll know you’ll be upgrading to 2011 and beyond, turn this setting on sooner, rather than later.

– Elijah Kerry

Advertisements

One thought on “Why does LabVIEW give all my VIs ‘dirty-dots’ when I only changed one VI? (and how do I prevent this)

  1. Mauro Giacomet

    This is a good move towards enabling the use of source control, but isn’t enough.

    Here is why:
    1. LabVIEW stores breakpoints in VIs. With all languages/environments I’ve worked before (28+ years as a Software Engineer), breakpoints are an ephemeral element associated with a particular debugging session. (Granted, with some debuggers you can save your session and not have to set up all your breakpoints every time, but that information is kept somewhere else (not the source file!)) I never had to modify (and save) a source file to set a breakpoint. It is preposterous to have to check out a SOURCE file (a VI, in this case) just because you need to set a TEMPORARY breakpoint (and later remember to undo the checkout). Furthermore, if you check in the VI with the breakpoint, the next day your coworker working on something else will have their execution stopped unnecessarily at the breakpoint you set…
    2. The project file also has its issues; Sometimes when I close the project I get prompted to save it and the reason is (a very non-descriptive) “A property of the project has been changed”. If I save a copy of the old project and the supposedly modified project, they are IDENTICAL (byte-per-byte, even when comparing the files with a binary comparator) Apparently LV stores in the project some running/state configuration of the RT controller that I happen to be connected to. Like the breakpoint, issue above, the state of a particular controller that I happen to be connected to is NOT a property of a project (also a “source” file or the equivalent of a makefile, for those that know what that is) and should be stored somewhere else.

    Again, good progress towards enabling the use of source control but still a long road ahead before it can be considered that Change Management in LV isn’t an excessive burden.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s