≡ Menu

01 VISV Separating Compiled Code From VIs


By default, LabVIEW stores compiled code together with the VI file. This is something transparent to us and we don't pay much attention to it. However, this can cause problems which appear when editing your VI. Sometimes when we edit a single VI, we notice that a number of other VIs require saving. Even though we haven't changed them directly. This is especially painful when trying to keep things in order with source code control.

In this video tutorial, I go through the new feature in LabVIEW 2010 which allows you to separate compiled code from your VIs. This allows you to avoid the problem of propagating changes.

Download: Code used in this tutorial (LabVIEW 2010)

Have you started using this new feature? Let me know in the comments.


I have some additional information that I learned after making this video. Thanks to Danny for commenting which prompted me to do some more research:

  • Any diagram that contains a ExpressVI or a Statechart VI cannot separate source and object code due to how LabVIEW embeds those subVIs inside their caller. Also a PolyVI can't be marked, because it doesn't really have a diagram (although an instance of a PolyVI can be).
  • The term now used to describe a VI that does not have its compiled code separated, is: “uni-file”
  • At the end of the video, I describe a caveat. To clarify this a bit more. What this basically means is that in order to do dynamic loading of VIs from the LabVIEW Run-Time engine, (as is the case in built executables which call VIs) you must not separate compiled code from VIs. In other words, you must create uni-files.
  • In the video, I show how to turn this on for a VI or even the contents of a Project file, but there is a way to enable this feature by default so that any and all new VIs are saved as “source-only” VIs.  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.

Hey, this is Michael Aivaliotis! Thanks for reading my post, listening to the podcast or watching the video on this page. When I’m not posting content on this site, I help companies develop automation powered by LabVIEW. If you want to find out how I can help you succeed with your next LabVIEW project – Contact Me.

  • i am trying this one…

  • Danny

    Best EVER feature in LabVIEW IMHO :-)

    Some comments

    * Not all VI can have there source & compiled code separated, VI containing Express VI cannot and there are a couple of other things I cannot remember.

    * If you have a big project with source & compile code separated it will take a long time to load first time.

    * It can be quite hard (well painful) to convert a large project over to separate source & compile see here for help http://lavag.org/topic/12886-experience-with-separate-compiled-code-from-source-lv-2010/page__p__80368__hl__%2Bseperate+%2Bsource__fromsearch__1#entry80368

    • Thanks for your feedback Danny. I’ve updated the post with some of your info.

  • GGT

    I may be missing something but shouldn’t this be default behaviour?

    • I agree with you GGT. However this capability was not available to us until the most recent version of LabVIEW, which was released in August 2010. From what I understand by talking to people within NI. We should expect this to be the “new norm” moving forward so we should all start getting used to it.

  • Pingback: 002 VISP Interview With Darren Nattinger — VI Shots()