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

[tommiejb]

No, I am currently working for Guidant.  I have worked on Medtronic contracts in the past, however.

Tom

[tbob]

Yes, I work for Medtronic in Tempe (Phoenix area).  The job is just as Tommiejb described.  A 5 minute change requires 3 months of paper work.  Horrible situation, but the pay and benefits, and the people here, are so great....  Dennis, if you ever come to Phoenix, please look me up.  It would be a pleasure to meet you in person.

[tbob]

Ahhh, the enemy!  I'm glad to see that the competition has to jump through hoops also.  Have you heard that the FDA is stepping in and will go over all documentation with a fine tooth comb, and will require an application to make any changes to existing production?  What a mess.  But it pays the bills very well.

[Dennis_Knutson]

I wish I could remember the names of some of the people in Tempe I worked with. Must be a sign of old age. I did enjoy the work (it was a VXI based test system) except the paperwork you mention. I still don't buy the "but it's a dry heat" comment, though.

[tommiejb]

Yes, I work for the enemy.  Er, wait, you're the enemy!  I'm so confused...

Seriously, back to the original discussion, I wanted to point out that the reason why I am asking this question is that I have a driver that is hanging, I believe because of TestStand clashing with Call By References.  While I am trying to get to the root cause (I've got another thread going on this subject), I am exploring taking out the Call By References.  The driver uses Call By References to avoid this very problem, that of calling VIs needing to be resaved.  So, the code itself won't change, other than call subVIs directly.  The question, how do I make the switch without the VIs that call these top-level driver VIs (i.e., application VIs) needing to be resaved?  I tried it, and some application VIs needed to be resaved, others didn't.  I suspect it has to do with how many nested cases there are, and what is wired up to each case.

Tom

[tbob]

It would be hard for me to tell why your calling VIs need to be resaved without looking at your proprietary code (I'm sure you wouldn't want to share this with the enemy ).  Maybe you should just package all the code (main vi and all subvi's) into one package, and with every change you just issue a new package.  The validation can stick to the actual change in the subvi, and the total package change would not care if the calling VIs are resaved because you are in effect releasing a new package.  If code in the calling VI is not changed, there is nothing to validate in that VI.

[tbob]

Dennis:  It's not only a dry heat, it's DAMN HOT!!!  Like a blast furnace.  But the "dry heat" only lasts for about 4 months.  The other 8 months are great.  I couldn't find a better place to live and work (well maybe Hawaii).

[tommiejb]

I am trying to avoid having to revalidate 20 different applications.  If I can make these changes in this one driver set, then I only have to revalidate one driver set.  In any case, I don't think they are going to rearrange the entire directory structure of the applications just to satisfy me.  I'd have 20 different engineers getting on my case.  😉  I should point out, however, that we do bundle each driver as an entire package.  We don't release VIs one at a time.  So once I make this one change, I shouldn't have to revisit this again.  I guess one big question is, how far up the chain does the recompiling go.  For example, let's say you have 4 levels of VIs and and subVIs.  If you make a change to a bottom level VI, VIs on level 3 might have to be resaved, but what about level 2 and level 1?  (In case it's not obvious, what I mean by levels is level 1 would be your top-level VI, which calls VIs on level 2.  Level 2 VIs call VIs on level 3, etc.)

BTW, I have a brother who lives in Phoenix, so I know all about the heat there.  I live in Minnesota.  Just goes to show how polar opposites we are.  😉

Tom

[tbob]

I once upgraded DAQ drivers and had to revalidate everything that was run on that tester.  Fortunately it was only one product test, and all I had to do was to run it several times and compare the data to before and after upgrading.  I'm afraid you may be stuck having to revalidate everything that has a newer file timestamp.  Anything less would not be accepted by the FDA, and those are the guys that rule.  The only way to tell how many levels up it would go is to do it and look.

I guess we are polar opposites too, I couldn't stand the cold weather up there.  Just one winter and I'd be dead.  Being hot is uncomfortable, but being cold hurts (at least at my age it does).  I dread the day Medtronic decides to shut down the Tempe campus and move everything to Minneapolis.

[Dennis_Knutson]

What about the Medtronic facility outside of Boulder? I have no idea what they do there but the weather here is great.