LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Application Builder error in LabVIEW 7.0

Solved!
Go to solution

Yes Dist Copy Non-VI Files and its callers should be pasword protected, but it is calling Librarian Copy.vi dynamically and Librarian Copy.vi should not be password protected.  That dynamic call is the only possible source I can see of a 1003 error in Dist Copy Non-VI Files.  Dist Copy Non-VI Files I believe is always called but if there are no files to copy it the loop inside of it won't do anything, but I do see in the code that it will try to open the reference to Librarian Copy.vi and that Open VI reference I think is the source of your 1003 error.  So open up Librarian Copy.vi and see if it is broken.

Message 11 of 18
(1,141 Views)

Son-of-a-gun -- I'm missing the VI "Copy from Folder to Folder"!  Where did it go?  Where does it belong?  How do I get it back?  [These are sort of rhetorical questions -- feel free to answer, but I'm going to "crawl around", looking for them ...].  I'm assuming this VI is supposed to be installed "inside" vi.lib, perhaps even inside Libraryn.llb, and somehow got clobbered/deleted by some other routine -- pretty mysterious.

 

In any case, my apologies to Microsoft, who qualified as Suspect #1 (I think it highly unlikely that an update patch would cause a VI to vanish from within LabVIEW ...).

 

Bob Schor

0 Kudos
Message 12 of 18
(1,134 Views)

Hi Bob,

 

Have you tried mass comping your main VI before building an application? Have a look at this KB for a few other troubleshooting steps. Reinstalling LabVIEW would also be not a bad option in case some of the App Builder files are corrupted.

Sev K.
Senior Systems R&D Engineer | Wireless | CLA
National Instruments
0 Kudos
Message 13 of 18
(1,130 Views)

Yes, I "mass compiled" the While Loop with a Stop Button :-).  See the next reply.

 

BS

0 Kudos
Message 14 of 18
(1,128 Views)

Well, I now "understand" the error and can "patch" it, but I don't understand how it occurred.  Within Program Files\National Instruments\LabVIEW 7.0\VI.lib\Utilities is a filed called libraryn.llb.  On the systems that cannot build, the VI "Copy Folder to Folder" is missing from the LLB.  On the systems that can successfully build, the LLB contains two VIs, Copy Folder to Folder and Copy Folder to Folder__Buggy.  [I find having two VIs with similar names, one with the suffix "Buggy", peculiar -- I wonder if some "repair" mechanism plucked both of these VIs out of the LLB, causing the problem I'm seeing.  Of course, it could have been a defective Install file or installation ...].

 

Being a good biologist, I did the obvious test -- I plucked out the "good gene" (the libraryn.llb file from the "good" installation) and "transfected" the "bad" installation by replacing its libraryn.llb file with the "good" file.  [There's also a libraryn.bin file, which I also replaced "for good luck"].  I can now successfully build applications!

 

My plan is to "repair" those of my installations that have this problem.  I'm still very puzzled why some installations are "good" and some "bad", but once I have all "good" installations, I'll be able to notice if it "goes bad" again, and maybe understand what's going on here.

 

Many thanks for the helpful suggestions, especially the one that pointed me to the Librarian utilities.

 

Bob Schor

0 Kudos
Message 15 of 18
(1,125 Views)
Solution
Accepted by topic author Bob_Schor

Bob,

 

My only guess is some installer (NI or instrument driver or otherwise) blapped libraryn.llb.  Since .llbs don't have a windows version number to them installers will generally replace the file if a newer one is being installed.  So I would suspect some NI module/toolkit/driver or 3rd party toolkit/driver of overwriting it.  Taking the good gene as you call it and spreading it to the bad systems is the way to repair it without having to uninstall and reinstall LabVIEW.

 

Kennon

0 Kudos
Message 16 of 18
(1,120 Views)

I concur with this hypothesis.  I'm in the process of testing it by cloning a VM with the "bad" library, uninstalling OpenG, then uninstalling LabVIEW, and then reinstalling everything, testing as I go, to try to isolate, if possible, who is clobbering the Librarian.  If so, I can bring it to the Developer's attention, and perhaps forstall other "mysterious 1003 errors" for other users.  Fortunately, a lot of the work can be done "in the background", so it doesn't take too much of my time ...

 

BS

0 Kudos
Message 17 of 18
(1,118 Views)

Have done some more "poking around" to try to understand why the VI "Copy From Folder to Folder" goes missing from libraryn.llb in LabVIEW 7.0, thereby "breaking" Build Application.  I've taken a (broken) LabVIEW 7 system, completely uninstalled LabVIEW, then reinstalled it.  The Librarian is fine (file is present).  I noticed, however, that when I install the OpenG utilities (using Virtual Instrument Package Manager, VIPM), that there is a specific package "ogpatch_Librarian_BugFix" that renames Copy From Folder to Folder by adding the suffix "__buggy" and replacing it with another VI having the original name but a different icon.

 

On the two systems I have that "work", this patch has clearly been applied (because both VIs are present, and the date on the Librarian LLB matches the date for installing VIPM, and other OpenG packages).  On the "broken" systems, neither file is present.

 

Two hypotheses suggest themselves -- 1) VIPM might (in some versions on some systems) "mis-install" the patch, causing the original file to disappear but not replacing it with the patched file.  2) Whatever the "bug" was that the patch is designed to fix, maybe when one tries to do a Build App using the "unpatched" VI, something goes awry resulting in the VI being removed from the LLB.

 

I've submitted a Bug Report/Query to JKI (who distribute VIPM and are the current "custodians" for OpenG).  If we get a definite answer, I'll update this post.

 

Bob Schor

0 Kudos
Message 18 of 18
(1,103 Views)