What happens to a VI when it is compiled?

[GerTheDwarf]

Does LabVIEW put date-time stamps into the VIs or make linking changes or something unique to each compile?

Is the compiled version of the VI only in memory? Would that mean all VIs saved on disk are not compiled?

[Norbert_B]

Your question is somewhat... strange to someone who knows LabVIEW quite good.
The reason is that LabVIEW always compiles the VI (or at least part of it) when you change something. So, there is no "compilebutton" and LV does not compile if you press the run-button. If you save a VI (because it is marked with a *), the compiled AND the not-compiled part (Blockdiagram!) is saved on disk.


hope this helps,
Norbert B.

[GerTheDwarf]

I disagree. Take a look at the Keyboard Shortcuts in LabVIEW Help.

Ctrl-Run button Recompiles the current VI.
Ctrl-Shift-Run button Recompiles all VIs in memory.

[tst]

By default, LV recompiles each VI (or maybe only a part of it?) every single time you make a change. That's why the VI can immediately break. When you save a VI, the compiled code is saved as part of the VI.

Sometimes, things can break without LV noticing and they might even continue working (e.g. when using ActiveX or .NET objects). Ctrl+Run or Ctrl+Shift+Run force LV to compile the current VI or all the VIs in its hierarchy even though no change was made to them. It's not something which usually needed - note the Ctrl and Shift parts, which are not usually used. When you do this, LV will ask you if you want to save each and every VI in the hierarchy, because it recompiled them and the new recompiled code needs to be saved as part of the VI.

The only place where I have seen the need for this is when you build an application with .NET and COM objects - the application builder does recompile all the VIs (that's why it takes some time to build an application) and if you have VIs which broke but continued to work in the IDE, it will throw an error without giving you any good indication of the reason for the error. Force compiling all the VIs will then show you which VIs are broken so that you can go fix them.

[Norbert_B]

To add some additional info to tst's infos:
If your blockdiagram gets very huge, LV tends to compile only a part of it when making changes. This is done because LV ponders that in the inteface to the part recompiled doesnt change and it shortens the time immens till you can run the VI or see the broken execution arrow.
But it is possible that the newly compiled part does not fit to the rest of the code so the VI wont work but still shows a normal execution arrow. In those cases, a force-compile (as it is called) can uncover this because the whole blockdiagram is compiled.
Please note that huge blockdiagrams are not recommended by NI's Style Guides!

hope this helps,
Norbert

[GerTheDwarf]

Back to my first question, does LabVIEW put unique identifiers into the compiled code? Does the compiled code contain LabVIEW version information? Or is the LabVIEW version determined from the format/sequencing of the compiled code? Does it contain a date-time stamp? Does it contain anything other than just the front panel and block diagram?

I'd like to add that one of the projects I'm working on uses ActiveX, and my projects use different LabVIEW versions but share code (why? because of management red tape), hence my need to compile the whole project before I can build, and my strange questions.

Message Edited by GerTheDwarf on 10-05-2007 09:13 AM

[JamesR]

The compiled code does contain LabVIEW version information.  The date/time stamp of when a VI was last saved is stored in the operating system.  Is this useful to you?

[altenbach]

---

@tst wrote:
The only place where I have seen the need for this is when you build an application with .NET and COM objects

---

Just a side comment: Forcing a recompile is also a quick and dirty way to clear uninitialized shift registers. 🙂

[rolfk]

---

@altenbach wrote:

---

@tst wrote:
The only place where I have seen the need for this is when you build an application with .NET and COM objects

---

Just a side comment: Forcing a recompile is also a quick and dirty way to clear uninitialized shift registers. 🙂

---

And I sometimes use it for an entire hierarchy followed by a save all VIs, to find out on disk what Vis in my project directroy tree are not used anymore and why as well as if that could be a problem.

Rolf Kalbermatter

[tst]

---

@rolfk wrote:

And I sometimes use it for an entire hierarchy followed by a save all VIs, to find out on disk what Vis in my project directroy tree are not used anymore and why as well as if that could be a problem.

---

If I do that (which I don't always do), I prefer doing a programmatic check for callers in the hierarchy. I wouldn't want to save NI VIs or have to commit all the VIs to SCC for no reason.

I believe E. Blasberg posted a find unused VIs to LAVA once which can be used if people don't feel like writing their own.