Separate Compiled Code From Source

Usually, LabVIEW stores the compiled code used to run a VI together with the graphical code of the VI in the same file. LabVIEW automatically recompiles all changed VIs together with all callers, modifying a lot more files than were actually touched. Your SCC won’t like that! Luckily, there’s an option to separate the compiled code from the graphical source code.

"Separate Compiled Code From Source File" VI property
“Separate Compiled Code From Source File” VI property

At the ALA Summit last November, we touched on the topic of the “separate compiled code” option in LabVIEW. Another little discussion yesterday on one of the ALA Slack channels sparked the idea to this article. Here’s a little refresher as to why it is a good idea to enable this useful option:

When you change a VI, LabVIEW will update all VIs that have this changed VI as a dependency, and recompile every VI hat is calling that VI, and every VI that is calling the calling VIs, and so on. That’s why you end up with so many “dirty dots”. Technically, LabVIEW does not really change the VIs (i.e. the front panel or block diagram) but only recreate the compiled code for it, which by default is stored together with the front panel and the block diagram in the same VI file.

As long as you’re not using Source Code Control, it’s not too much of a bother as you don’t need to do anything but say “Save all”. When you use SCC, though, it will want to update all the VIs that changed on disk, so you lose track of which VIs you actually modified.

Thankfully, you can tell LabVIEW to “Separate compiled code from source file”, which will do exactly as it says: It stores the compiled code somewhere else (in the compiled object cache).


  • This feature makes it possible to leverage all the advantages of source code control with LabVIEW, when developing large applications and/or in teams, or even a small application on your own (thanks, Danny Thomson, for pointing out the importance)
  • No dirty dots, hence no unintended side effects in SCC
  • Fewer merge conflicts as code on a parent/top-level or shared resources don’t change (thanks, @thoric)
  • Faster load times for source-only VIs (besides the first recompilation, see below)


  • The first time you open / load the VI, it takes longer as LabVIEW needs to recompile
  • VIs without compiled code cannot be used in the runtime environment, so if you make an application with plug and play extensions, loaded dynamically from file, the extension VIs need to have compiled code in them (thanks again, @thoric)
    (edit: Alex points out in the comments that building the source into a packed project library addresses this issue)
  • Potential problems: When deploying to Real-Time targets, and/or when deploying updated FPGA bit files, it happened to us a lot that LabVIEW would not actually notice that files changed, and would not deploy correctly. Clearing the compiled object cache seems to help with this and other oddities.

Enable The Options

There are different ways to enable this feature. For a single VI (or library or class), you can change this setting in the Properties dialog in the General Settings tab (see screenshot above).

You can also configure your project file to separate the compiled code from new project items and mark existing items, too:

Separate Compiled Code From New Project Items
Separate Compiled Code From New Project Items

Finally, you can tell LabVIEW to separate the compiled code from all new files. The setting can be found in the “Environment” section of the Options dialogue (menu “Tools” -> “Options…”):

Separate Compiled Code From New Files
Separate Compiled Code From New Files

Check Existing Files

There’s also a VI Analyzer test that checks for this setting in the VI Analyzer Enthusiasts group. Make sure to browse the listing of available community-created VI Analyzer tests while you’re there!

Modify Existing Files

If you want to scan your existing files for VIs or libraries or classes that miss this setting, and also programmatically enable the option for those files, you can use a little scripting VI that we came up with. You can find the VI in our public hse-scripting-tools repository:

Separate Compiled Code From Source

7 thoughts on “Separate Compiled Code From Source

  1. I remember when that feature came out in LabVIEW 2010, it finally made it possible to treat LabVIEW as a professional language in source control terms. Without this feature source control of LabVIEW was like trying to do source control of C or C++ where every developer was keeping all the build object and link files in the control system.

    I really think the Pro, Cons section does not stress enough the huge benefit of selecting this option for any person or team who are using source control and lets be honest here, by 2019 everyone should be.

    A key feature of source control is the identification of what changes occurred in what files to implement a bug fix or feature. So if you do code review the reviewer code look at those changes or if suddenly you working production software stop or breaks you can identify the files concerned.

    As somebody who can from a source control background in text languages I remember how impossible it was before this feature was introduced. It would not be uncommon for a team member to change say 5 VIs and then have to check into the source control system maybe 50 or more VIs. It made it very difficult to then identify the original 5 ( there were method of doing and controlling this all horrid and time consuming).

    Knock on effects of this made it significantly harder to develop large applications in a team with LabVIEW, as cascading recompiled of VIs from different developers working in different areas of the code based could cross in a totally unexpected way.

    1. Danny, thanks for your comment. You make some very valid points, and I agree – I’ll edit the pros section to make the huge benefit stand out more. Cheers!

  2. Using this option in TestStand with LabVIEW adapter configured on RunTime lead to the second con problem.
    This option is enabled even on native NI VIs suchs as VIs in the TestStand palette in LV.
    So as you mentionned in the article, building .lvlibp is the only way I found too as a workaround.

  3. Thanks for the great instruction Joerg, it was very helpful
    I have found that setting the flag in a class doesn’t extend the change to the member VI’s in that class. It also doesn’t apply to VIs that are dependencies of a project. Have you found an approach that works for either of those situations?

    1. Thank you for taking the time to comment, Carlos. Actually, I do not have a solution for the use cases you describe – we resort to setting “separate compiled code from source” as default in the LabVIEW settings, and we have VI Analyzer tests and scripting to check/fix existing projects. Currently, 100% of our code uses this setting.

Leave a Reply

Your email address will not be published. Required fields are marked *