Is there a way to programmatically remove VIs from memory?

[Brock Greman]

Hi, I'm a new poster here.  I'm also working with an implementation of 'Make Current Values Default' and I've got to say, it works for me.

My work involves saving data files in the research laboratory where I work.  I'm developing an overarching system that will allow for a fail-proof data storage system.

Basically, I have a bunch of 'template' VIs corresponding to the particular data needs of a user.  It consists of an an input and output terminal in the form of a cluster that contains the data.  There's also a case structure with a blank constant to pass to the output terminal while saving to keep file sizes down.  This template is used in a 'write data' VI.

In this higher level 'Write' VI, the data is passed into the template VI, which executes itself.  LabVIEW is nice to me, and keeps this VI in memory even after execution, which allows me to open a reference to it, set its current contents (i.e., the data) as default, and then save a copy as my 'Data VI'.  I call the system DataVIew, because (corny slogan warning) "The Data IS the VI".

It works like a charm.  With one little problem:  This method doesn't work at all if the 'write' VI is involved in any sort of loop structure.  For some reason, the template VI doesn't revert to edit mode after its copy has been saved, so the second (or further) time it tries to set default values, I get the 'not in edit mode' error.

So basically, my question is: Is there a programmatic way to unload a VI from memory?  I'd like to do this after the copy is saved, so that a fresh 'instance' of the template VI is opened on the next iteration of the loop.  I'm willing to deal with the computational overhead involved.

(I made a new thread as someone mentioned that new messages are searched more often)

LabView 7.1

[mikeporter]

What you're wanting to do should work. Can you post your code? I use templates extensively and have never had problems with them.

Mike...

[Brock Greman]

Here you go.  File paths might be a bit messed up.

[Brock Greman]

I perhaps should explain, and provide another necessary file.

One of my collaborators had previously been storing his data in LabView VI log files.  One of the goals of my project is to convert all legacy data to the new format.  This is the purpose of the VIs in the 'importers' folder.

The logfile I'm experimenting with (attached) contains 11 records.  I'd like to be able to run the "HongZhou Data Importer" either in a loop itself, or containing a loop, to access and save each file.  It doesn't work.  It DOES work if you manually increment the record number, run the VI, increment, run, etc.

I'm fairly certain that the problem lies with the template VI being kept in memory and in an active state, ready for the next iteration of the for loop.  I need to prevent that from happening.

[TylerS]

Brock,

I have to admit that I'm fairly confused about your application. In the attached VI, there is nothing on the block diagram, so I assume that you are writing datalog files through VI Server from some other VI, but I'm not sure why you're going about it that way rather than writing the data directly. I'm curious about that.

But as far as releasing a VI from memory, there is a function on the All Functions>>Advanced>>Data Manipulation palette called "Request Deallocation". This function frees the VI from memory in which it is placed. So if you wanted a subVI cleared from memory after it is called, you could place this function in that subVI to clear it from memory after it is run. This might be what you are looking for.

I hope this helps. Have a good one!

Tyler S

[mikeporter]

OK Brock;

I see your trouble. 1st off you don't have any template VIs in your code. You may have VIs you're using as templates, but that's not the same thing as a template VI. Template VI have the extension *.vit. Next, the reason you are getting the error is that you have the top level VI (your importer function) that is still running and so everything in its hierarchy is still marked for execution even though its not actually running.

I'll fix this for you and send it back in a bit. Wanted to get back to you with an update first...

Mike...

[mikeporter]

Brock,

Here's your code back and its working.

To begin with, the file "HongZhou Data Template.vi" is now "HongZhou Data Template2.vit" and the name is in a constant. You will want to come up with some better way of getting the path to this, but for now just make sure the path is right before you try running it. If you forget to set it, you'll get an error about not being able to find a file. Needing to specify the path in this way is an issue because you can't have the template VI itself on the diagram.

I have also cleaned up the other code to give better response. The only problem is that the routine for saving the template is so fast now that it doesn't have time to open its front panel completely before it closes--you'll see what I mean when you run it. A progress bar of some sort would probibly give better feedback.

MIke...

[Brock Greman]

First of all, Mike, I want to say thank you.  You've solved what was seeming to me an impossible problem.  I wasn't even aware that such a thing as a 'template' vi existed.  I just 'called' them templates.

I must admit, however, that I'm not quite sure how the new implementation is working.  On the write VI, there's an input terminal, but I don't see how it's connected to the template VI.

Am I correct in assuming that previously, the 'make_current_default' VI was receiving an input before it had finished executing, and that this is one of the reasons for my problem?

Again, thanks a million times for the fix.  It fixes the last problem I had with the software suite, and I can begin implementing it full scale in my lab.

[mikeporter]

Yes, the input terminal on the write VI isn't connected to anything at this point it's primary function is to allow the polymorphic vi to link up the right version of the write routine. Beyond, that the code pretty much works the way you had it before--just more efficiently...

Yes, also to your question on the source of the error. I found it because after getting the template VI part sorted out the code worked if execution highlighting was on in the top-level but failed at full speed. You see that happen and two words should pop into your head "Race Condition". I looked back into it and that's when I noticed that you weren't waiting for the VI to finish before continuing.

On a similar point, notice I also rearranged things so the front panel wasn't opened until after the subvi was running. The advantage of this is that it looks better to the user. The other way around and you can see the window open in non-runtime form for just an instant. The way you had the window appearance set the change was very noticable. The only cost to doing this way is that you have to programatically wait for the subvi's execution state to become Idle before continuing.

Mike...

[Brock Greman]

I can understand everything up until how the data actually gets into the template.  That's rather confusing to me at the moment.  How is the template instance loaded with the input data?