12-08-2005 08:10 PM
12-09-2005 12:36 PM
Hello,
I think the issue here comes as a result of upgrading code, then saving for
previous. The LabVIEW.lib file is a library file used to interface
external code with LabVIEW primarily to handle memory management
operations. There is a different version of the LabVIEW.lib file for each
version of LabVIEW. My guess is that when you modified your code in
LabVIEW 7, you began using the 7.0, and when you switched back you were either
still calling the 7.0 version, or you had a call in the code to a function
(specifically the FDestroyPath) that does not exist in 6.1.
You might want to start with a mass-compile of your LabVIEW project before you
build your executable
(http://digital.ni.com/public.nsf/websearch/A4C3AEF93240280A86256931006FB66C?OpenDocument).
Maybe delete or rename the LabVIEW 7 version so that you are positive that you
are never using it in your LabVIEW 6 project.
In either case, it’s probably best to find where exactly you are attempting to
use LabVIEW.lib, and troubleshoot from there.
Hopefully this helps! Please let us know how things go, and if you have
any additional questions.
12-13-2005 01:07 AM
12-13-2005 01:17 AM
Hi Travis,
First of all thanks for your help.
As per your comment I changed the VI's using LabVIEW 6.1.
The modification was addition of a Strictly Typedef Enumeration Control as VI's parameter.
The compilation and Build process was smooth.
But when we RUN the executable or the Source VI, itself, the same error occurs.
Eagerly waiting for your reply.
Thanks in Advance
Aneesh PS
12-13-2005 04:34 PM
Hello Aneesh,
I think I failed to ask a very important question: does this behavior only
happen in built LabVIEW executables, or does it happen in the runtime
environment as well?
If it happens in the development environment as well, you will need to do some
more debugging to determine exactly where that function is being
used. I don't think I've ever heard of anyone using LabVIEW.lib FROM
LabVIEW -- its used by your external code to call LabVIEW memory routines.
I would attempt to track down any external code which links LabVIEW.lib and
make sure the right version is called. It might also be the case that
something in your install of LabVIEW 7 went wrong and modified the location of
or the actual LabVIEW.lib file. If you don't have access to the external
code you might consider backing up your LabVIEW 6 code, removing all versions
of LabVIEW on your computer, then reinstalling the one that it used to work
with. Before you do this, though, I would make sure that you only have 1
instance of LabVIEW.lib on your computer. Attempt a search for that
filename, and rename/remove all other copies. If you still get this
error, I'm betting either the error is in the code of your external code (i.e.
you are calling a function that does not exist), or the external code requires
a different version of LabVIEW.lib than is present on your computer (either a
newer, or older version depending).
If it does not happen in the development environment but it does with the built
application, we might need to take at a few other things to get to the bottom
of this.
Please let me know how it goes!
12-13-2005 10:38 PM
12-16-2005 04:45 PM
Good afternoon,
I am sorry to hear that you are still experiencing these errors. I really
think that we need to narrow down which specific node is resulting in an
error. It is possible link against LabVIEW.lib in LabVIEW code, but it is
also very likely that your error could be coming from one external code
module. In your first post you mention that you are building an
executable, but in a later post you mention building a llb. If the error
comes from the llb we can try to isolate it by running individual
Hope this helps!
12-16-2005 08:43 PM
12-19-2005 11:02 AM
Hello Aneesh,
Glad to hear that the process of narrowing down the
offending VI was able to resolve the error!
I am a little unclear on what you mean when you say “we convert them to Folder and make the changes”, and I don’t know
how your customer modified the Snd Play Wave File VI. However, I can say that that particular VI
does call a DLL (the one you mentioned) which is responsible for playing the
wave file. I am almost certain that using
you customer’s VI resulted in LabVIEW calling a different version of the DLL somehow. Though both of the sound
Hope this helps!