What causes VI's Recompiles & how to reduce them.

[danny_t]

Hello  All,

This is my first post the the NI forums, so lets see....

I am interested in getting a better understanding of what type of changes to a VI, cause higher level VI's to recompile ? and what is the best approach to minimise this situation.

I understand the obvious changes, i.e adding  / removing a front panel control or indicator, or the changing  an indicator / control type and I can see how that will cause the calling VI to need to be recompiled. However often I do changes that I would not expect to affect the calling VI but still it recompiles.

The particular thing I do not understand is the rules to decide when to expect the ripple effect, whereby I change a sub-VI and not only does it's calling VI recompile but there is a ripple effect up the calling Hierarchy and often not for any reason that seems obvious or predicable to me.

I have looked around but have not really found any documents to help me understand this.

Following on from the above, what can I do the forestall the ripple like compile situation, in particular

• Is it affected by the project directory structure and the stored locations of VI's releative to each other
• I assume one of the best techniques to forestall this is to us a plug-in / dynamic loading of VI's type architecture.
• I had hoped that by moving to a LVOOP type architecture would reduce this but following a posting on the LAVA site I now believe that the effect would be the opposite.

cheers

DannyT

Working in LabView 7.0 on Windows XP.

[TheWay]

Hi DannyT,

I wouldn't have expected the caller VI to recompile unless you had changed the input and output connectors on the sub VIs.  You said you made changes to the sub VIs that you didn't expect affected the calling VI.  Can you give me some examples of those changes?  Also, how are you determining that the caller VI is being recompiled and that a ripple effect exists? 

Regards,

Way S.

NI UK Applcations Engineer 

[danny_t]

Hi Way S

Thanks for the reply........ even though you have caught me out in a way.

We use ClearCase source control to look after all our VI's. The way we work is we "checkout" the file we intend to edit and after an edit we "check-in" the file back into ClearCase.
If as you suggest we are changing the terminals of a sub-vi or inputs / outputs in any way we are expecting the calling VI to change and check them out as well.

So for example I am working on a single VI near the bottom of our calling tree and I do not expect any other impact,  I checkout that file work on it a bit and some time later I launch my top-level.vi.  When I try to close my top-level.vi I can a number of Vi's that need to be saved because Labview explains a subvi has been modified.  sometime I think oh yes, that makes sense but often I cannot figure out why... to me it seems inconsistent.

It does seem to be impacted on the project size.  Two examples I have seen are

a) A very low level Vi with several inputs one of which was a string control. The string control was wired into a case (no other use),   the case used the input string to decide what to do. Types of inputs were "Read", "Get", "Init" this was called by 50 odd VI's. When adding in or removing case's in the case structure all the Vi's that called this VI needed to be save and the reason provided by Labview was due to a recompile of subvi

b) We tend to do the standard thing with the error in going into a case statement, some on the input controls  were placed inside the no error case. To tidy up I moved the controls outside of the error case statement and that causes the VI that called it to need to be saved.

However, I cannot get either of these two example to repeat in simple circumstance. I will spend some time over the next week and see if I can come up with a couple of concrete example to give to you.

[AristosQueue (NI)]

There is an aspect of LV's diagram called "inplaceness." If the inplaceness of a subVI changes (based on changes on the diagram) then the caller will recompile.
You can search around for more details on what inplaceness is and how to control it. It's a pretty advanced topic.

There's no real documentation on this because it is almost never an issue for LV developers. I'm surprised that this has become a concern for you.

[danny_t]

Aristos, you asked why is this issue a concern for me.

In configuration control there is a common idea of an activity package. This defines a package of changes made to fix a bug or add in a new feature.  So we can track say five file were changed on this date by this developer to fix this problem and if need's be it is easy to revist change package at a later stage if there are problems.

In a typical compiled lanuguage situation, let us use C, you only change say five source code files, this might mean if one of the filse was a header file for example that your build rebuilds many more than five new object files and many links are done, but you always know that only five source files were change and have to olny look at those five files in the case of a problem after the software has been released.

My experience with Labview is that it is quite possible to actually only change five Labview VI's but actually have to save a great deal more files. Sometimes it can result in almost half a project needing to be saved.  This make life quite hard at a later stage to go back and see what were the actual files that really started it all.

It is just an aspect of Labview I find anoying and would like to understand better.

Thanks for the correct term "inplaceness."  I will do some searchs around this an see if it throws any light on the matter

cheers

Danny

[AristosQueue (NI)]

Gotcha.

You should know this then: If you edit a subVI in such a way that changes the inplaceness, the caller will recompile. If you exit LV without saving the caller, then it will recompile the next time you load. The solution used by several LV developers is to create a change list of the files you actually changed and then, after you record that, record a second changelist of the files that had to recompile as a result of the change. Then when you're looking back through logs of what changed, you just ignore any of the recompile-only changelists.

[danny_t]

HI Aristos,

That is an interesting approch to take and would work fine; not my ideal as it adds some overhead, but possibly the most pragmatic way to deal with it.

I just wanted to check it was not just a basic flaw in my artichecture or project structure, but it appear just to be something to live with.

Thanks for the replies

cheers

Dannyt

[dan_u]

Hi DannyT,

We face the same problem. What we sometimes do is to just check in the modified VIs (but not those that require recompiling due to SubVI changes). If changes get too much (for example if you modify a TypeDef that is used all through the software), we do a mass compile of the whole tree and check in everything that's changed.

Just my 2c.

Regards,
Daniel