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

*Update*

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.

About the author: Michael Aivaliotis has been working in the test and measurement industry since 1993 with LabVIEW 3.0. He started his career as a test engineer and quickly fell in love with the graphical programming paradigm that LabVIEW provided. Since then, he’s worked on or developed an incredible number of complex test systems in electronics, semiconductor, automotive, telecom, biomedical and other industries. He’s an Certified LabVIEW Architect and a Certified LabVIEW Instructor. He also has the distinction of being among a select few LabVIEW Champions. In 2002, he created the LAVA Forums which have now become the largest independent online LabVIEW community. Email Me

  • http://www.facebook.com/people/Mohan-Ram/1806214486 Mohan Ram

    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

    • http://vishots.com VI Shots

      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?

    • http://vishots.com VI Shots

      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