Build application

Hello all
I have LV7.1
I want to create application
I receive the error:
Application Builder: A Source File VI or one of its dependencies does not exist. Open all VIs in the Source Files list, recompile them, and save them to update their dependencies.
What do I do?
Iskander

Hi Dennis,
I am plagued by this same error no matter what i do. When i force compile ctrl+shift+run and close the VI, It is asking me to save LabVIEW VI's such as clear task VI. WTF is this. I may be a beginner, but that seems like suicide. In a previous post the advice to create a new project from scratch, so i did. I even get an error on type def controls (ERROR 7). And interestingly enough, the dependicies are asking me to find VI's that are in the project! I've lost it man, I'm nutty.
I was able to get an exe and installer to work on a smaller application,but only because I copied all VI's to a LLB.
I have little experience building source dist, exe, or installer. I can not make heads or tails of this.
I appreciate your advice in advance,
Chris
Attachments:
After force compiling.doc ‏129 KB

Similar Messages

Problem building application using Report Generation Toolkit, LV 2011

I'm using LabVIEW 2011 under Windows 7.
I tried to use Application Builder to create an executable from a large body of code. One thing the application does is load VIs into a subpanel and run them.
Application Builder created the executable and gave no error message. The built application ran except that it couldn't run any of the dynamic VIs.
I finally succeeded in doing a screen grab on a transient dialog (about 1/10 sec. appearance). The dialog showed an attempt to load <vilib>:\Utility\NIReport.llb\NI_report.lvclass.
In one dynamic VI I commented out the call to the only VI that uses the Report Generation Toolkit (called only from dynamic VIs, all of which call it). Sure enough, when I built the application with that change and ran it, the dynamic VI that didn't invoke the Report Generation Toolkit did successfully load into the subpanel and run.
So, trying to prove to myself that that was the only problem, I wrote a VI that does nothing but load a VI into a subpanel and run it. User can choose one of two VIs: one that doesn't call the Report Generation Toolkit (or do much of anything), and one that does. Both VIs run fine standalone.
The not-much-of-anything VI loaded and ran in the subpanel. The other VI didn't--the same dialog, mentioned above, popped up for 1/10 second or less. Screen grab is attached.
When I included LVClass and NIReport.llb folders in the project (from vi.lib\Utility: Snapshot folders), and "Always Included" those folders (per a suggestion on this forum from a few years ago), the result was the same. The result was also the same when I included either one of those folders but not the other. Likewise it doesn't matter whether I add the dynamic VIs as "Always Included" or not.
Another piece of information that may be pertinent: when adding the NIReport.llb folder, I got a message that it was impossible to add a certain VI that's part of some report-type class, because a VI of that name already existed in the project. Screenshot of that dialog is also attached.
VIs and project file are also attached along with the two screenshots. I hardcoded VI paths, so put everything into C:\Testing if you want to see what the code does--or hack as desired, etc.
I will be deeply grateful for any help! And I apologize in advance if there's already some exact or close-enough solution posted--but I doubt there is. I looked around.
Thanks very much,
mws
Attachments:
Test-App-Build.zip ‏336 KB

Hi again,
If you extract all files in the original zip attachment to a folder called C:\Testing on a Windows 7 machine running LV 2011, and then use the build script within the project file to build the application, you can run the application and see what happens. You can also play around with the build parameters, rebuild, run, and see what happens then. You can also open my VIs and see what I'm doing.
The application lets you pick one of two dynamic VIs to run in a subpanel. One VI contains calls both to Report Generation VIs and some functions from the Advanced File Functions palette. The other VI does not.
When you pick the first VI to load and run (the one with the Report Generation and Advanced File Functions calls), it loads into the subpanel but is not executable.
When you pick the second VI to load and run, it does load into the subpanel and execute. So there's nothing wrong with the way I load and run a VI in the subpanel.
In the development environment, the whole thing runs with no problems.
Evidently the built application has problems resolving paths of something called by Report Generation VIs and by the Advanced File Functions I use.
I've done a lot of experimenting and no luck. I've looked in forum archives, etc. etc., for possible solutions. I'm hoping there's some simple solution I've missed.
Thanks very much for any help!

Error message in application builder in Build Application.vi

Hello,
I'm trying to make an executable file but I recive the following error message:
Error 1003 occurred at Open VI Reference in Dist Copy Non-VI Files.vi->Dist Build LLB Image.vi->Dist Build App Image.vi->Build Application.vi
Possible reason(s):
LabVIEW: The VI is not executable.
Does anyboy know the reason for this message?
Thanks.
Javier de Pablos

Hello Jaime,
I've tried to compile a very simple VI (there is only a while loop that executes nothing and counter is wired to an indicator.
I've attached you.) and I've got the same error. So the code or any dynamic VIs are not the problem.
I've repaired the Application Builder within Control Panel > Add and Remove programs but I haven't resolved the problem.
Javier de Pablos
Attachments:
Untitled.vi ‏13 KB
gg.bld ‏1 KB

I'm getting an "Error 1003 occurred at Open VI Reference in Dist Call Create Installer.vi- Build Application.vi." whenever I try to create an installer for my app.

I'm running LabVIEW 6.1 on Win XP Pro, and my application
builds fine, but I can't create an installer.

Dependency Walker will show all of the DLLs NIMSIDistKit.dll is dependent on. There is a tree view in the top but the flat list at the bottom will probably be more helpful. It should show the following dlls (at least on a Windows 2000 system):
ADVAPI32.DLL
GDI32.DLL
KERNEL32.DLL
MSI.DLL
NIMSIDISTKIT.DLL
NTDLL.DLL
OLE32.DLL
RPCRT4.DLL
USER32.DLL
If one of these DLLs is missing it will have an error message displayed beside it. I think all of them are regular Windows DLLs so if you are missing one of them your computer might be having other problems. You could try to reinstall LabVIEW to see if it will install a copy of the dll, but you might have to reinstall Internet Explorer or some portion of the OS to get all
of them.
Probably the most important dll is the MSI.dll. If it is missing or too old it might be the problem. I have version 2.0 but I think version 1.1 of this DLL will also work. If you don't have the dll or the right version run \applibs\distkit\redist\InstMsiW.exe (if on Win NT/2000/XP) or InstMsi.exe (95/98/ME). This will install/update MSI (Microsoft Installer) on your machine.
You can also press F9 to toggle showing just the filename and the whole path to the dlls. Besides NIMSIDistKit.dll all of them should be loading from your system folder. If not you may have multiple copies of that DLL and the correct one is not being found.

Building application exe USB-9215 DAQmxBase LabView7.1 errors

Hello
I’ve been building DAQ applications using the NI 4-channel USB 9215 module. It has a sampling rate of 20ks/sec and with four channels the maximum I can sample per channel is 5000s/sec.
It works with no problems at this rate and lower rates, however when I compile an application and run it, I get the following message:
Onboard device memory overflow. Because of system and/or bus bandwith limitations, the driver could not read data from the device fast enough to keep up with the device throughput. Error code: -200361
This message appears irrespective of the sampling rate, even down to 1s/sec !!. I’m using Labview 7.1 with the ‘DAQmx Base Read.vi’ in a while loop. The PC spec is very high and no other applications are running. The PC has 4 USB ports; only two are in use, one for a mouse, the other for the 9215.
Any ideas would be welcome
Thanks in advance

Hi there,
What operating system are you running on and what service pack version?
It seems that there have been occurences of errors similar to this (with other USB devices 9201/9221) reported on machines with Windows XP service pack 1. In particular the version of the Windows file usbehci.sys, as reported in the following knowledge base article.
http://digital.ni.com/public.nsf/websearch/ADC80B3995042EB98625704C006B5753?OpenDocument
If this applies to your situation, I would suggest upgrading the service pack as recommended in the knowledge base article and see if this helps.
Regards
Hannah
NIUK & Ireland

Why do I get Error 1 when building applications

I'm creating an executable using the Labview 6.1 application builder but I get this error: Error 1 ocurred at Gsim Sintax Check.vi. I didn´t install the Simulation and Control toolkit I copied the vis I needed to use them.
What can I do?
Thanks

yen,
Do you get this error at build of the application or from the executable itself? Does the VI run in the development environment?
I would build the executable from the development machine that has the toolkit on it.
Brett B.

Error 1073 (on Clear Errors.vi) When Building Application in LV 8.2

I have seen numerous posts about this problem when building an application without a block diagram in LV 7.x, however, I am recieving this error on LV 8.2. Whats most disturbing about it, is that it always hangs when processing Clear Errors.vi. I have tried my source on two different machines, to no avail. Also I tried to do a mass recompile of the entire vi.lib again no help. It is very important that this program compiles, however I cannot get past this error. Any suggestions?
My specific error message is here:
Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 1073 occurred at ABAPI Dist disconnect td-poly.vi -> ABAPI Dist Chg and Save VIs.vi -> ABAPI Dist Build LLB Image.vi -> ABAPI Copy Files and Apply Settings.vi -> EBEP_Invoke_Build_Engine.vi -> EBUIP_Build_Invoke.vi -> EBUIP_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: This property is writable only when the VI is in edit mode, or this method is available only when the VI is in edit mode.
-Paul

Hello Paul,
I am sorry for not elaborating previously. This issue has been documented previously for further investigation to our R&D group (# 3ZK9LGP2). In the report I found that this error, though vague in the description, is fixed by enabling MathScript Support.
To enable MathScript support, check the checkbox in the application properties for the 'Enable MathScript support' option.
-Bob
-Bob

Build application based on queue message handler template

I programmed an application, using QMH template in LV and made a build out of it. The build has the "main.vi" and it is always included. But, after build is complete, the application starts by clicking on my apllication.exe and immediately terminate itself !!!! any idea about why? (I have one global function ("exit" which set to false at initialize state of the application" and shared variables, but both seem not the items to be blamed !!

I recently (about two years ago) started using the QMH fairly heavily, "re-inventing" my usage of it several times (that means taking a LabVIEW Real-Time project of several hundred VIs and almost "starting over"). I've attached a Demo Snippet to illustrate some Lessons Learned.
First, an admission -- see all of those Queue wires? I've gotten rid of most of them by using a Queue Action Engine that handles all of the Queue actions except Dequeue. In place of the Obtain Queue, Enqueue, and Release Queue calls, I have a Message Queue VI that takes an Enum (Obtain, Enqueue, or Release) and (optional) inputs (such as the Element to Enqueue). The only Queue wire in my diagram is the one from the call to Enqueue Initialize to the (necessary) Dequeue Element (but I don't need the Queue wire coming out of Dequeue Element as I use my VI instead of Release Queue). Not only don't I need a Queue wire going into the parallel Event Handling loop, but I don't need a wire going into a sub-VI that needs to "send a Message", which makes spawning asynchronous parallel loops easy.
You'll notice my Messages are Strings, not an Enum. I'm a little conflicted here -- I like the "error-checking" feature of Enums, but especially when designing, it is so much easier to say "Hey, I need another State here to do this" and simply name it and add it.
The Event Handling Loop, for the most part, should do nothing except generate a message, passing the Event New Value (if needed) as the Data part of the message. In particular, the Exit message is just another Message -- it doesn't need to be "filtered out" for special handling.
To stop all of the loops, I use a Local Shared Variable (you could use a Global or FGV/VIG as well) -- the TimeOut case in the Event Handling Loop wires this variable to the loop Stop, and as you can see, the Exit message sets it;
You may notice the 500 msec timeout on the Dequeue -- this allows you to catch cases where no messages come in. Here I "do nothing". But you'll notice that this makes my Stop code work. The User pushes Stop, generates an Event, calls the Stop Message, sets the Stop Shared Variable to True, but that (probably) does not stop the lower loop, as the earlier False value was probably read and "connected" to the Stop indicator when the loop was entered. 200 msec later, the Event Timeout fires, sees the Stop Shared Variable = True, and stops the Event loop. After another 300 msec, the Dequeue times out, enters the True Case and does nothing, but now the Shared Variable is True and the lower loop stops.
You are correct that if you want to do repetitive things with this model, you need to repeatedly call the State you want to run. It depends how much of your code you want to put into a single QMH -- it might be just as simple to have yet another parallel loop do the same thing every 100 msec, and use the State Machine to handle the User Interface (I've done it both ways, depending on circumstances).
Have fun!
BS

Error in Build Application (EXE)

Hi,
There is an error is prompt as attached when I was trying to build the exe.
Both my Labview 2012 & Database toolkit are evaluation version.
I have no idea how to choose the different option as the error message mentioned.
Is there any alternative way to build the exe?
By the way, my PC still has the full activated version of Labview 8.5.1, can I get any assist from there?
Thanks.
Attachments:
Capture.JPG ‏51 KB

Hi tantan,
If you have activated 8.5 then why you are not using this for building exe ?
Any specific reason ?
Kudos are always welcome if you got solution to some extent.
I need my difficulties because they are necessary to enjoy my success.
--Ranjeet

Build application error

i am now getting a build application error. i tried a vi that had been build previously, stilll get the error. the program runs ok in labview.
Problem Description :
Hello, i never had a problem 'building application' before.
now i get an error and message:
Visit the Request Support page at ni.com/ask to learn more about resolving this
problem. Use the following information as a reference:
Error 1502 occurred at AB_Source_VI.lvclass:Close_Reference.vi ->
AB_Build.lvclassave.vi -> AB_Build.lvclass:Copy_Files.vi ->
AB_Application.lvclass:Copy_Files.vi -> AB_EXE.lvclass:Copy_Files.vi ->
AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi ->
AB_EXE.lvclass:Build.vi -> AB_Build.lvclass:Build_from_Wizard.vi ->
AB_UI_Frmwk_Build.lvclass:Build.vi -> AB_UI_FRAMEWORK.vi ->
AB_Create_Build_Application.vi -> EBUIP_Global_OnCommand.vi ->
EBUIP_Global_OnCommand.vi.ProxyCaller
Possible reason(s):
LabVIEW: Cannot save a bad VI without its block diagram.
NI Software : LabVIEW version 2011
NI Hardware : Select one if your issue is related to hardware device
Driver Version :
OS : Windows 7
Thank You

Timmar wrote:
I get this a lot,
I mean an awful lot.
Caused when Labview Corrupts a project VI, usualy by one of it's ever so frequent crashes.
It won't tell you it's broken but it is,
Indeed, there is an inconsistency between what's shown on the BD and what actually is there in compiled form. Specially obvious with XControls. The BD's can be completley empty, but still LV searches for the XCtl reference when you open the empty FP and void BD???
Several tricks:
Save the VI with another name, close the old one, overwrite the old VI by renaming the new one.
On the block diagram press: CTRL-A -> CTRL-X (select all and cut it out) Create a new vi and paste in the code. Overwrite the old broken VI with the new one.
Only do class name and move path's when the projects are in memory. Not always feasible if you have a lot of re-use, some projects end broken searching for old paths. So that is a bit painful to update all your projects, specially with some ref's are correct and other's not.
CTRL-SHIFT->Run VI, forces a recompilation of the VI hierarchy
Mass compile to find broken stuff.
Good version control is a must to revert if things go haywire and badly out of control with LV.
Br,
/Roger

Labview 2013 slow after building application

I have Labview 2013 with the DSC module installed.
I am running on Windows -64bit with 4 GB RAM
After I build my application, Labview slows to a crawl. There are no errors when I create my application and my application runs fine
All other programs run fine.
The windows task manager shows CPU use ranging from 2 to 20%
I have to shut down the computer and restart it. Then Labview is again running fine. Until I build my application again.
My application was originally developed in Labview 2012
I have not yet tried to create a new application to see if it is specific to my application or my Labview setup. I will try that next but I wanted to see if anyone else had this issue.
Thanks

Is this Windows 8, 7, Vista, etc?
Are you running 32-bit LabVIEW or 64-bit?
I would definitely recommend seeing if this problem happens when you try to build any application, or just your specific application?
Assuming the problem only occurs with your specific application, I would recommend that you try to build it on a different machine (assuming you have access to one) and see if LabVIEW behaves the same way on that other machine.
When you originally built your application in LabVIEW 2012, did you encounter this problem?
You could also try repairing both LabVIEW and the DSC Module to see if that makes a difference.
Regards,
Ryan K.

Build application with LabView 8.2 Prof

Hello,
in the past (V 6.1) it was possible to build LabView application with a complete setup routine, not only *.exe. In Version 8.2 I dont find these option. Anybody knows where to find it?
Best regards
Robert

I think that what you want it's to create an installer. See the steps on the attach picture.
Software developer
www.mcm-electronics.com
PS: Don't forget to rate a good anwser ; )
Currently using Labview 2011
PORTUGAL
Attachments:
teste.png ‏333 KB

Build Application with all files inside .exe

Hello,
I have a labview project consisting of a few classes and subvi's. Nothing really special. Now when i try to build an .exe file, i get the .exe, an application.ini, an Application.aliases and an data folder (has the classes and dll's within). What i want however is the .exe file with all files inside. So that at the test setup, there is only one file on de dekstop, and not 4. Is it possible to do that?
Greetings wcm

LabVIEW 2009 and later have a build option (set on per default) that embeds all the classes inside the executable file.
The ini file will always be created, however you can delete it during startup of your executable.
I think you don't need the data folder since that has some DLL already present on your system.
However my advise is to create an installer that puts the executable (and the other files) inside the program files folder. And the installer can create a shortcut to the executable.
Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas
LabVIEW, programming like it should be!

Build application freezes, USB-6501

I am running LabView 7.1.1 on Mac OS X 10.3.9. I am controlling a couple of instruments via GPIB and the USB-6501 with DAQmx Base. My VI works fine. I'm trying to build a stand alone application with the application builder and it freezes during the build. I have unchecked the box to "Disconnect type definitions and remove unused polymorphic VI instances" in the Application Settings of the Application Builder and it still freezes during the build. I've tried to recompile the VI by holding down the option and shift keys while clicking the run button and it locks up then too. I have successfully built applications without the USB-6501. Can anyone offer some help? Thank you.

Hi All-
Unfortunately MAX is not available on Mac for troubleshooting, Mike. Vob, can you please verify whether you installed NI-DAQmx Base prior to or after installing the LabVIEW 7.1.1 patch? The driver must be reinstalled after installing the LabVIEW patch and after mass compiling your directories. You should not mass compile after the NI-DAQmx Base installation.
Also, this line from from the NI-DAQmx Base ReadMe might be pertinent:
If, when building an executable or shared object project using NI-DAQmx Base VIs, the Application Builder catches an error, you must restart LabVIEW before running any NI-DAQmx Base VI.
Please give these suggestions a try and repost if you are still experiencing problems.
Thanks-
Tom W
National Instruments

Build Application problem // external subroutine

Hey,
i was build an stand alone application (.exe) and i have a problem with external subroutine to subVi.
I was trying to add the missing .llb as support file in Source Files but still doesnt work.
It works on my computer, on another computer doesnt work (please look attached file)
I have LV 7.1.
I read on forum about this problem and i didnt find any solution for me.
Thanks for help.
Attachments:
missingSubVi.JPG ‏12 KB

crossrulz wrote:
Mark, a lot of things changed going to LabVIEW 8. LabVIEW 7 didn't have projects or the fancy build specs. I don't have LabVIEW 7 anywhere, so I can't play around in the menus of the very old build dialog.
I know a lot has changed. I don't recall myself exactly how LV 7 build specs looked. It should have some type of similar option though.
If it doesn't the OP may need to be very specific with his paths for calling the dynamic VIs and makes sure he distributes them and place them into the correct directory where his application will access them.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Build applicatio​n

Similar Messages

Maybe you are looking for

Build application