Separate Compiled Code from Source

[This article was originally published on our Company Blog]

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. 

Why bother?

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

Pros

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

Cons

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

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…”):

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: