Problems building exe that includes dsc (vi's always in memory, causing an error) 
Author Message
 Problems building exe that includes dsc (vi's always in memory, causing an error)

Hi,
Thank you for your time and expertise.  I am trying to build an
executable (Win2000, labview 6.0.2 and DSC) but am consistantly being
told that a group of vi and ctl files are already in memory.  I have
removed all non-essential cards, restarted my computer and attempted
to build from a blank vi.  Nothing should be in memory.  Would there
be a service running (from boot up) that is causing this?  There is
nothing left in my icon tray that would indicate that this is so.
Please note that one of the vi's is entitled "dsc_Engine Status.vi."
Nathan


Sun, 25 Apr 2004 09:10:57 GMT  
 Problems building exe that includes dsc (vi's always in memory, causing an error)
Here is the problem:

You are attempting to build an application that uses VIs that are in
memory.  They are in memory for two reasons:  One, you are using VIs
that are used by LabVIEW, and two, they are used by LabVIEW DSC when
it runs, by the service manager.

There are two solutions.  One will get you there quickly.  The other,
will solve all of your applications building problems now and forever.

I will give you both and let you decide, however, I recommend the
first, as it will solve your problems anytime you build an
application.

Solution 1:
Open your top level VI(s).  Open the VI Hierarcy.  Select the option
that allows you to view the path of the VI when you do a mouseover.
Go to each and every VI, global, and control.  Ensure that each is in
your development or deployment directory, and NOT in /National
Instruments/LabVIEW...etc directories.  These are NI Core functions,
and you should build with a copy only.  This will take a lot of time,
and may cause crashes (I had problems changing things in the
hierarchy.)  Try doing a "save all" about every 3 or so VI that you
change.  To change the location, you must first stop all services.
Goto the Service Manager and select "Stop all Services".  This should
unload all the callers for these functions.  Now, go to the hierarchy,
and for everything in the LabVIEW directories, open it, and "save as"
in your directory.  This will cause the callers to look in your
directory for the copy you are using.  As I said, save all once in a
while.  Also, when prompted to affect the change in all VIs in memory,
select YES.

When you have copied all resources, save all once again, and close
everything, including LabVIEW.  Now close LabVIEW.  Take the directory
into which you moved all of these functions, and move it off the
computer temporarily (don't rename, remove to a different drive, or a
zip drive).  Then restart LabVIEW.  If anything got moved incorrectly,
you will be asked to search for it.  Open a new VI, and select save
all, to remake the file search paths stay with LabVIEW.  Do NOT have
your project open when you do this.

Now, replace your folder where it was originally, and restart LabVIEW.
You can now build your application.

Solution 2:

Start LabVIEW.  Goto the Service Manager and select "Quit Service
Manager".  When prompted, select yes to stop all services and quit.

Now build your application.

The reason the first solution is better is because you always want a
copy of all NI Resource VIs, Globals, and Controls in separate
location for your build.  This not only prevents issues such as the
one you mention above, but also solves a lot of other issues,
including any changes to those core functions that may occur in newer
versions of LabVIEW that may affect your program.

Good luck.



Wed, 28 Apr 2004 06:05:57 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Problems building exe that includes dsc (vi's always in memory, causing an error)

2. Building an Application with Instrument Driver VI's Included

3. Built EXE file always crashs on initiation

4. Problems with DAQ vi's after building application

5. tclsh81.exe causes memory access violation under Alpha/NT

6. MS 5.1 .exe is causing GPF in user.exe

7. What is the cause of this error (Memory block free'd twice)

8. What's causing this memory usage?

9. convert's labview 6.1 vi's to labview 5.1 vi's

10. Create an Exe of a VI that controls another VI

11. No build option for some vi's?

12. Running vi:s after building application doesn't work

 

 
Powered by phpBB® Forum Software