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

[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.


log and vi.zip:
http://forums.ni.com/attachments/ni/170/130185/1/log and vi.zip

[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...
 
 


log and vi.zip:
http://forums.ni.com/attachments/ni/170/130451/1/log and vi.zip

[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]

Uh yup, you're right everything was getting written--except the data. Oh well... It was getting late last night.
In any case, I have played a bit more and attached is a version of the VI that does save the data and cleans some other stuff up as well. For example, note how I write the data to the subvis. Although I have heard that this method is not quite as efficient as using indexed control references, I prefer it because it is more robust in that it isn't dependent upon a hidden parameter (tab order) to stay connected to the right controls.
Note also the data passing. To maintain the polymorphism of your interceeding code layers, I converted the application-specific data types to a variant data type. In this way Remember Values and Make Current Default can handle the data without worrying about what the real data type is. (Actually something you might want to consider is whether the you still need both of these VIs...) The only other impact to passing variants is that the template VI has to make the conversion back to a LV datatype so I had to add a Run VI before saving the new defaults. Reading the data shouldn't change because the "Read" case bypasses all the code so all you'll see is the output's default value.
Using variants as a polymorphic data type is a very helpful technique, take some time to be sure you understand it. You will want to use it again sometime...
I have also cleaned up the error passing so all errors will eventually find their way back up to the top level VI and be reported. In addition, I added a case structure to prevent the creation of an extra spurious data VI. The problem is that the database assess node doesn't assert EOF until you have read past the end of file. You might want to look up how to access the log files using the standard file IO VIs. That approach might be more flexible is you have several log files of each type to convert.
If you have any other questons on what I have done just ask...
Mike...


log and vi.zip:
http://forums.ni.com/attachments/ni/170/130473/1/log and vi.zip

[Brock Greman]

I'm going to have to spend a bit of time familiarizing myself with the
new system.  One of the advantages to the system I had used before
was that it was easy for a user to create a new template and writer for
his own data type, which could be readily incorporated into the
polymorphic VI.  This is of importance because my position in this
lab isn't permanent, so I won't always be there to guide them through
updating the software.

If my understanding is correct, the new version of make_current_default
now requires that certain controls on the template VIs have very
specific names.  The software itself does work like a charm,
although I believe the 'read' and 'write' cases in the template VIs may
need a bit of altering to make them make more sense.  Basically,
the user should be able to drop a data VI into another block diagram
and access the data from an output terminal.  I'm also going to
eventually write a data browser which will be able to accommodate all
the data types.

This is not to underscore the extreme help you've been to me.  The
software has become so much more sophisticated thanks to your
assistance.  If you send an e-mail to me a bgreman[at]gmail.com
with your name and institution, I'll make sure to credit you as a
source and collaborator on the software package.

Thanks again,

Brock

[Brock Greman]

This had been my goal from the start, but I eventually abandoned it
when I determined that, as far as I know, you can't dynamically add or
remove cluster elements and maintain their naming properties. 
Since being able to access the cluster elements by name is of paramount
importance, I decided that teaching the others to build their own
templates was an acceptable solution.

[Brock Greman]

He seemed quite pleased with the current incarnation, and requested
that I move on to another project.  I'd previously created an
importer that reads data from a WaveMetrics Igor(TM) binary wave file
(.ibw) and now I have to write a program that can go the other way as
well.  All in addition to my real research project.  I may
eventually come back to DataVIew in the future, but for now they'll
have to be satisfied with the exhaustively in-depth step-by-step guide
I wrote concering the procedure for creating new templates.