What are the rules for when a Calling VI has be resaved after a subVI is changed?

[tommiejb]

We are planning on making changes to a driver set.  However, if one of our applications has VIs that have to be resaved because of these changes, then we will have to go through an extensive validation process for each application.  Therefore, it would be very helpful for us if we knew what changes can be made without the caller VIs needing to be resaved.  If a caller VI does need to be resaved, what about it's caller VIs?

For example, I know that adding or deleting a control would require the caller VIs to be resaved.  What other rules are there?  Sometimes it seems like I did nothing that would change the connector pane, yet the caller VIs have to be resaved (i.e., they get the asterisk).  Does anyone have a full list of when VIs need to be resaved when their subVIs are changed?

Thanks,

Tom

[Kenny_K]

I dont have a list of every action, but I think you can sum up what causes a resave is if you modify anything to do with that VI, including sub VIs.  Move, delete, change font, anything.  I tried to go through a VI of mine and find something that would not cause the asterik to appear and I could not change anything without it appearing.

Maybe some of the more knowledgeable labview programmers will have a specific case where you don't have to resave, but I cannot think of any.

Kenny

[tbob]

You can find out why the vi has an asterisk by closing the vi before saving, then when you get the message box asking for you to save, click the Explain Changes button.  This will list what has changed in the vi since last saved.  This could give you a clue as to why your subvi changes made you have to resave the calling vi.

[altenbach]

You can always go to "Menu...File... VI Properties...General" and look at the Current changes.

Also don't forget that if you e.g. upgrade LabVIEW, all files need to be resaved. They have been converted to the newer version, even if you don't make any changes.

[tommiejb]

First of all, I should emphasize that I'm talking about not making any changes to the VI itself, only changes to the subVI that it's calling.  In doing experiments with one VI and one subVI, I get the same explanation each time in the Current Changes field:  "VI recompiled." and "SubVI call(s) modified.".  Both are pretty generic.

Since no one has so far responded with a list, here is the start of a list:

1.  Adding or deleting controls and/or indicators.

2.  Changing the label and/or description of a control or indicator.

3.  Adding a for loop to the block diagram.

Those are the obvious ones.  There are others I could add to the list, but these don't seem to be very consistent.  For example:

4.  Connecting or disconnecting wires to controls or indicators.

5.  Wiring a control to a case statement (a specific example of #4).

In regards to #5, yesterday, in my experimental VI (I've enclosed them), I wired the numeric control to a case statement, then saved the subVI.  The calling VI then needed to be resaved.  I disconnected the numeric control and wired up the string control to the case statement.  Once I saved the subVI, the asterisk appeared on the calling VI.  This was very consistent.  Now, this morning, I do the same thing, but the calling VI doesn't need to be resaved.

So my question is, when does the calling VI decide it needs to be resaved?  Since I haven't made any changes to the connector pane, or to the controls and indicators, why does the calling VI need to be resaved?  Why should the calling VI care if a for loop is added to the subVI?

Since the driver I'm working on is called by 15 different drivers, which is called by 20 different application, all of which have been validated, I really don't want to have to revalidate all of these drivers and applications, simply because I went in and fixed a bug in a low-level driver.  So any information that helps me to understand what triggers a calling VI to recompile due to a change in a subVI would be greatly appreciated.

Thanks!

Tom

[Dennis_Knutson]

Simply changing which control is wired to the case statement should not have forced a save of the calling VI. I haven't seen this behavior and can't reproduce it. The behavior you saw this morning is what I would expect. However, even if the subVI did not cause the calling VI to be resaved, I don't believe that in itself is no reason not to revalidate and a forced resave is often not a reason to validate. For example, if you saved the subVI to a new location, that would cause a change in in the calling VI and you would have to save it. This doesn't change the behavior of the subVI or calling VI and I see no need to do any extensive validation. If on the other hand, you did some extensive internal changes to the subVI, this might not require a save in the calling VI but should be validated. Suppose an old subVI was returning a string of length x. You modify it and it returns a string of length y. The calling VI would not know this and would not force a re-save but you should make sure that the different string length does not affect any VIs that call it. I think you need to determine a set of rules for validation that's based on the actual changes you made.

[tommiejb]

Unfortunately, I don't make the rules around here.  One of the requirements set by this organization is that you can't be asked to resave a VI on the factory floor.  If the VIs in an application have to be resaved, that application has to be revalidated.  However, even if I make extensive changes to the driver VIs, as long as I demonstrate in the validation of that driver that the applications still perform the same, and there are no VIs in the application that have to be resaved, then the application doesn't have to be revalidated.  I'm not trying to defend the rules, I'm just saying that these are the rules I must live by.  I should point out that this organization is a medical device company. 

Any changes would require approval meetings, documenting and formal approval of those meetings, changes to documentation, meetings to approve those document changes, formal approvals of those meetings, etc.  For most things, a five minute change means at least a weeks worth of documentation.  We are switching from LabVIEW 5.1 to LabVIEW 7.0, and that has taken 2 years (and still going).  So you see, sometimes it's easier to just work within the rules then to try to change them.

Your ideas are certainly valid, I just want you to understand why I am rejecting them.

[Dennis_Knutson]

And sometime it's easier to work around the rules. I don't have rules as rigid as the medical industry but I have some to follow as well. I use TestStand and what I do is make all of my instrument and low level drivers DLLs. I can make a lot of changes to the VIs I build into DLLs without the high level test steps aware of it. Using the Call by Reference node can do much the same thing. Another thing I sometimes do is defer changes. I am required to do a new validation whenever new firmware for the product is released or there is an ECO to the product. For non-critical updates to the code, I will wait until one of these events happens and do everything at once.

I do understand your pain though. I once was contracted to write a program for a medical company. Each and every VI (about 200 in total) had to be separately validated starting at the lowest level and working my way up. I think the validation process took longer to do than writing and debugging the entire application. The company had a new employee just starting to learn LabVIEW. His first application was a huge VI with no subVIs at all. His reasoning was that he would only have to do a single validation step and could be done quicker. I wouldn't recomend this method.

[tbob]

tommiejb:  Do you work for Medtronic?

[Dennis_Knutson]

tbob,

Do you? The contract job I mentioned was for Medtronic. My primary contacts were from Phoenix but I had to travel to Minnesota as well.