Projects, application builder LV7/LV8

I realize that this is a general question so I'm hoping someone can just point me in the right direction.
I have been using LV8, but recently had to work on a cRIO application that was written in LV7. I was able to make the necessary changes and solve the problem but there were a few things that left me confused.
The LV7 application was as follows:
an FPGA program
a RT program
some windows .exe program that, when run, would download all the appropriate programs into the cRIO and run it.
In order to make changes to any of the programs, and have those changes "stick", I had to run the Application builder. Fortunately the previous developer left a profile that I could load, and everything worked, but before I found out about this, I struggled with getting the application builder to correctly assemble all the necessary files.
My question is, does there exist a tutorial on using the application builder? Does it include writing an application that will find the RT VI, the FPGA VI, and put them in correctly?
I am familiar with LV8 and I understand how to have the VIs loaded automatically (stored on the cRIO). I'm just not familiar with LV7.
Just looking for pointers and tips on using the application builder I guess.
Thanks
Jeff

Jeff,
Here are a few links that should help you out.
Creating Executables with the LabVIEW Application Builder - This is a general overview of the Application Builder (version 6.0 and 7.0)
http://zone.ni.com/devzone/conceptd.nsf/webmain/4ef810ee05bef63c86256bf30062ec31
Deploying and Launching a Real-Time Application - This is more specific to deploying a real time application
http://zone.ni.com/devzone/conceptd.nsf/webmain/9ac4955881bd7b4d86256d0b0061dd1c
Hope this helps,
Justin D.
National Instruments

Similar Messages

LV8 Application Builder Folder Structure

I have a folder structure in my development environment.
When I build an application, using the application builder, I want to get the same folder structure.
Example:
I have folders ..Application\Drivers\DMM\Agilent 34401 and ..Application\Drivers\DMM\Fluke 45.
There are subfolders containing VI:s in each folder (..Application\Drivers\DMM\Agilent 34401\Subs\sub.vi)
In the application builder I add ..Application\Drivers to "Dynamic VIs and Support Files".
I create a new "Destination".
Now all vi:s from ..Application\Drivers goes to this folder, not to subfolders.
Is it possible to get a folder structure?
Staffan Ekstrom
Sony Ericsson Mobile Communications AB
Lund, Sweden

Hi Staffan,
When you build an application all of the VI:s will be integrated in an .exe file. The reason for this is that the user of your program not shall be able to do changes in the source code.
When adding files to the "Dynamic VIs and Support Files" these files are for example help files that you want the program to find no matter where you install your program on the computer. Before adding files to this you need to build the relative path in the program using strip path.vi and build path.vi.
Dynamic VI:s are not the same as sub VI:s.
The short answer to your question is no, there is not possible to get a file and folder structure when building an application.
Regards,
Andreas E
Applications Engineer
National Instruments

Creating Builds Programmatically LV8.0.1

Salut.
From LV8.0.1 help :
QUOTE
Creating Builds Programmatically
You can use the BuildTargetBuildSpecification VI located in the vi.lib\AppBuilder directory to build source distributions programmatically from build specifications. If you have the Application Builder installed, you can use the VI to build stand-alone applications, shared libraries, Windows installers, and zip files programmatically. The VI is not available on the Functions palette.
Note The LabVIEW Professional Development System includes the Application Builder. If you use the LabVIEW Base Package or Full Development System, you can purchase the Application Builder separately by visiting the National Instruments Web site.
The BuildTargetBuildSpecification VI creates a build from a build specification that you specify in the Name of build specification input. If you do not specify a build specification, the VI creates builds from all build specifications in the specified LabVIEW project. You must specify the path and filename of the project to use in the Path to project input.
If you want the VI to create a build from a build specification located in a target that is not My Computer, specify a target in the Name of target input.
After you run the VI, you can view the path to the completed build files in the Generated files output.
END QUOTE
1-
QUOTE After you run the VI, you can view the path to the completed build files in the Generated files output.END QUOTE
Does someone know how to also get the created installer files? (i only get the exe output files)
2- How can i start the build status feedback window when using the BuildTargetBuildSpecification.vi?

Hi jacemdom,
I hope you're doing well. I have tested building an Installer specification on my end, and I am seeing the same results. The correctly passes in the appropriate build specification reference, but no files are actually generated as you have noticed. I am currently looking for more documentation for you on the BuildTargetBuildSpecification as it is a relatively new feature. Regarding the status window with this VI, it looks like that feature is currently unsupported. I will verify this an update you with what I find. Have a great day!
Thaison V
Applications Engineer
National Instruments

Build Installer LV8.0 - is this real??

Hi all
I recently received LV8.0. After playing around and test some new features, I wanted to start to bring all testrigs that run under LV to LV8.0. Therefore I chose one of them, made a LV-project, modified the source code, created a application build script and an installer build script. I run the application build script without any problems. OK - everything's fine up to now. But as I wanted to create an installer, it obviously just creates a lot of "nonsense".
I checked some additional installers (Datasocket, LV8.0 runtime engine, MAX 4.0, Fieldpoint, Scope and VISA) to make just one Installer, which would be very nice to handle. When checking NI Datasocket, I saw in the distribution title on the right side (see attachment) LabVIEW 8.0 Real-Time Module. Why???? There is no need to include the rt-module, as I don't use it.
I thought "ok, maybe a wrong string displayed - let's create the installer" and run the build script. While running it asked me for the device driver cd's (ok - could be logical) and out of a sudden it also asked me for the cd of the LV realtime module. Well - I inserted it an continued the build.
In the end I got a directory structure (Volume/bin/lotsOf"pXX") with a size around 650 MB - for a simple application of approximatly 10MB.
When I browse some of these "pXX" directories I discover subdirectories like "p14/LV711RTE", "p15/LVBrokerAux71" and lots of different msi-files (for instance "NIRegistrationWizard.msi" - but why?).
Is there anyone out there who can help me quickly?
Thomas
Using LV8.0
Don't be afraid to rate a good answer...
Attachments:
Installer.JPG ‏167 KB

Thomas,
Thanks, I too have been waiting for us to have the ability to build installers that include all the drivers and related software you need. There was a lot of work that went into it by a team of people here at NI. Their work is being used in LabVIEW, CVI and TestStand now for generating such installers. I'll pass along your complements to the people involved.
So you unchecked DataSocket yet your DataSocket communications are still working? I think that might be due to DataSocket being included through one of the other installers. When you check an item we'll include all the dependencies that you need. Most of the time those dependencies don't show up in the list of additional installers, because they are lower level drivers and software you don't interact with directly and don't need to know about. Some of the items that are dependencies for other installers do appear in the list such as DataSocket, LabVIEW Run-Time Engine and MAX. FieldPoint for instance is dependent on MAX and will include it if you are including FieldPoint. If you check MAX too, the Installer Builder will only include one copy of MAX. I'm not sure which of the other items is dependent on DataSocket but it could be getting included that way. Another possibility is some older LabVIEW Run-Time Engines are being included in your installer because of MAX and they include an older version of DataSocket as part of their installer not as a dependency so it could get included that way, but that would be an older version of DataSocket and not what you are using on your development machine. Since you know you are using DataSocket I recommend checking it, so you know the version you are using will get included.
When you uninstalled LabVIEW Real-Time, the core portion of LabVIEW Real-Time was removed, however any dependencies it had that are also a dependency of another NI Installer would not be removed. As I mentioned earlier LabVIEW 8.0 installed DataSocket and the Real-Time Installer upgraded it. The installers have the necessary logic to know that just because RT installed a newer DataSocket we cannot remove it with RT because LabVIEW depends on it as well. When you ran the RT installer the progress bar probably showed installing part X of Y, and when you uninstalled it there was also a progress bar that showed removing part X of Z. Where Z is a smaller number than Y because some dependencies of other products were updated and they can't be removed until all the installers that need them are removed.
So the next question is "I want to rebuild this installer without having to put the CD in. How can I do that?" The ideal answer would be for us to have a check box on the dialog when you are prompted for the distribution that says something about copying the necessary files to your hard drive and you could choose to uncheck it. We didn't get around to putting that in for LabVIEW 8.0 but if you happen to use CVI you'll notice they have such a check box and as I said we use the same installer building technology so it wouldn't be unreasonable to see that in the future for LabVIEW . But what can you do right now?
One options would be to always copy your CDs over to the hard drive before you install them and leave the installers on your hard drive, that way the last place they were installed from was somewhere on you hard drive that can be found without user interaction. We don't do that by default since copying the LabVIEW CD(s)plus the driver CDs would really use up your free space. This is messy though because you have to uninstall everything and reinstall it.
Another option is to copy the distribution you are being prompted for (the entire disc) to your hard drive and then in the Installer Builder select NI DataSocket and change the Installer location path to the location you copied it to (the top level folder that has a nidist.id file in it). The press OK on the dialog, now the Installer Builder will look in that location for NI DataSocket, until a newer version is installed. We have had some problems with this mechanism not getting all the dependencies from the new location, so it isn't a 100% solution, but I just tried it for DataSocket and it worked.
The first option will catch 100% of the dependencies, where as the second option unfortunately won't.
Kennon

Application builder error.llb

Hi all,
I'm using application builder to compile an executable of my VI. Compile runs without a hitch.
However, when I try to launch the .exe three subvis from error.llb are missing : Not Found Dialog.vi, Details Display Dialog.vi and Set String Value.vi
The compiled .exe seems to be looking for these VIs in instr.lib, which is nowhere to be found in the compile folder.
This happens even on my developpment machine, on which, of course, the VI runs fine from within LabView.
Did I miss something during the compiler setup ?
Thanks in advance for your help !
Nico
Solved!
Go to Solution.

I've had this before, and it was reported by NI as being a bug that comes from loading up a project that was built in an older version of LabVIEW and creating an application from it. For me it was loading a LV8.5 project into 8.6.
The only workaround was to add the three missing vi's to the project, and ensure they are added to the Always Included list within the application builder.
You will find these vi's in Program Files\National Instruments\LabVIEW 8.x\vi.lib\Utility\error.llb. Simply add them to your project somewhere, then in application builder made sure you select them as Always Included in the Source Files section, then rebuild your application.
Message Edited by Thoric on 03-13-2009 03:52 PM
Thoric (CLA, CLED, CTD and LabVIEW Champion)

Application Builder does not work with Eurotherm 24XX-Driver

Hi,
I have to programm the software for a new teststation including some Eurotherm 2216 and a Keithley 2700-instrument in Labview 8.0.
Labview offers drivers for the Keithley 2700 instrument and a driver for the Eurotherm 24XX-series that works well with the Eurotherm 2216.
But if I try to build an application with the application builder, I receive an error message:
The following files include incorrect links to help files. Open the files and correct the links:
C:\Programme\National Instruments\LabVIEW 8.0\instr.lib\ET24XX\_ET24XX.llb\ET24XX Utility Multiple Write To Registers - Floating Point.vi
I checked this file - there are no links to help files included.
I receive a similar error message for the Keithley-Driver.
I attached the file making the problem.
Would be fine, if someone could help me.
Attachments:
Eurotherm testen ohne Messwerterfassung.vi ‏10 KB

Hi,
I had the same error with my application after I transferred it from LV7 to LV8. I used some external files for documentation of the VI's. LV8 does not find these files anymore (old and new location) Open the VI and add the help file again.
Hope this helps.

Report Generation for Excel does not work after using the Application Builder

I have a VI that writes data to an Excel file using the Report Generation Toolkit. I recently compiled the VI into a single Application (EXE) using the Application Builder. My VI runs its tests properly, but no data is written to Excel. What could be the cause? I don't receive any error messages.

Hi
I usually build exe-files, which sometimes also have report functionality.
Open the Application Builder and check the following things:
1. Add the following vis: _Word Dynamic VIs.vi, _Excel Dynamic VIs.vi They should be located in the directory ..\LabVIEW X.X\vi.lib\addons\_office in the llbs _wordsub.llb and _exclsub.llb (report1.jpg)
2. If you use an Installer, go to the Advanced Settings. There you can select some things to include in the Installer. Check if "NI Reports Support" is selected. (report2.jpg)
These are the things I always do, if I need reports and I never had problems up to now. I made two screen-shots of these settings.
Hope this helps.
Thomas
Using LV8.0
Don't be afraid to rate a good answer...
Attachments:
report.zip ‏25 KB

Build dll error in application builder 8.6.1

Hello,
I get always an error in the LV 8.6 application builder, when I build a dll. There is only one function in it, that has a string and an error input, and nothing else. I attach a screenshot of the VI prototype, and hier is the error description:
Error 1 occurred at Building DLL.
A component needed for Application Builder does not support the required functionality. This might have been caused by installing an older version of LabVIEW after this version was installed. Reinstall the current LabVIEW version to correct this issue.
Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.
After that I reinstalled LV8.6, I tried to reinstall only the 8.6 app builder, but no success.

Hello,
thank you for the reply.
I have solved the problem. I uninstalled the last installed LV version, this was 8.0. Then ran appbuilder again in 8.6, then I have got an instruction to run applibs\lvdllbuilder\lvdb.exe. Since then works.
regards
Mitulatbati

Application Build Failure on Excel.Print Report call

Developing software in LV2009 that uses Report Generation Toolkit to read/write from Excel templates. Program runs fine in development mode. AppBuilder crashes on *.exe build when adding NIReport.lvclassrint Report.vi
Digging down, I find a broken run arrow on the NI_Excel.lvclassrint Report.vi as shown here:
According to the Show Errors dialog, there is an unwired or bad terminal on the PrintOut invoke node; however I have not made any changes to this shipping VI (that I know of). I did try wiring all the unused inputs (empty strings to From, To, and PrToFileName; false booleans to Preview, PrintToFile, and Collate) after I ran into the error, but that had no luck either. Also tried inserting To Variant conversions for all input elements, just in case there was a problem in the implicit data to variant conversion.
I have also tried a ctrl+shift+run compile of the whole application, but that doesn't seem to get it to un-break, either.
Has anyone run into this problem before? It's weird that it would just break like that--I had actually compiled this particular executable before, using pretty much all the same Report Generation Toolkit VIs that I am using now. The only difference since the last build was that I replaced a Report.SaveAs function with a Report.Save function.
Also of note: I have included all the Report classes in my project and build specification in order to compile the dependencies into support libraries to minimize the number of labview files included with the executable distribution. This is probably why an error with the Print Report.vi calls is crashing the AppBuilder even when I don't explicitly call that VI anywhere in my code.
Solved!
Go to Solution.

Hey Guys,
I know this post if kind of old but I hope maybe one of you can help me out. I'm using an invoke node similar to what is above to print out an Excel spreadsheet to the default printer. My issue is that when I try to print from the spreadsheet from the executable, the executable crashes. I know it is that invoke node. The reason why I say that is because until recently I had two development computers, one running on Windows 7 LabVIEW 2010, and one running on Windows XP LabVIEW2010. The original .exe was built with the XP machine, when I tried to make some changes with the Windows 7 machine and open the project it would say that there was a missing connection to the invoke node even though I did not touch that part of the application. I would then remove the invoke node, add it again and it would clear the error for whatever reason. I would then build the .exe with the Windows 7 machine and when it would run, the application would crash at the point where it goes to print the spreadsheet. I got around this by building the .exe with the Windows XP machine, and it worked fine without any issues. However, my Windows XP machine cra**ed out so i'm no longer able to build the .exe on the XP machine . I needed to make some changes to the .exe not anything involving this section of the code and for whatever reason when the application goes to print it crashes. I get some criptic crash report from Windows that is pretty much useless. I think its a Windows thing. This was workign correctly though until I did a build on the Windows 7 machine.
Attachments:
Printout Invoke Node Excel.png ‏70 KB
crash1.png ‏22 KB
crash2.png ‏23 KB

Display Bug in LV 8.20 Application Builder

There seems to be a minor bug in the displaying of the "VI Settings" in the application builder for LabVIEW 8.20.
The problem is in an executable build spec, in the "Source File Settings" category.
Select a sub VI in the tree, then uncheck the select box for the "Remove Panel" property. Now select any other VI in the tree, then go back to the one you unchecked the "Remove Panel" box. You should see that the box is now checked.
If you don't do anything else and just select "OK, then go back into the build spec, you'll see that the property was correctly saved as unchecked. So it looks like it's just a display problem.
I've made sure the VI I try this with does not use any property nodes and it is not marked as a dynamic VI. I can reproduce this on two machines running Windows XP Pro SP2 and LabVIEW 8.20.
Ed
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.

In addition to Ed's
comment, I would like to say that this unexpected behaviour is not
always appearing. I have just seen following while editing this text :
I have unchecked the Remove Panel box for all the UI VIs (all are
located in the same directory). When scrolling through the different UI
VIs in the Soure File Settings, the box was unchecked for all the VIs.
Without closing the Source File Settings window, I switched to
Developer Zone and switched back to the Source File Settings. For some
UI VIs, the Remove Panel box was checked. I closed the window and
opened it again, the box was unchecked again for all the UI VIs.
But I have also encountered the case that when scrolling through the
VIs to try to uncheck this setting for all of them, it suddenly appears
checked again for a VI for which it was unchecked or unchecked for a
before checked VI.
You finally end with a very unclear situation and it may be that the
Remove Panel is really checked for some VIs. At least, in some cases,
the built EXE could not run because of missing front panels. I can't
remember the exact error messages when running the EXE but they
mentionned the name of the VI and something about missing ressources. I
opened the .lvproj file and noticed that the "Remove Panel" property of
these VIs was set to TRUE. After modifying these settings and
rebuilding the EXE, it ran as expected.
In development, I
normally uncheck "Allow user to resize window" of the UI VIs because
this setting can unfortunately not be changed when configuring the
executable. In the "Source File Settings" I uncheck all options of "Use
VI Setting" for these UI VIs and I only check "Auto-Center" (all VIs)
and "Window is Modal" (some VIs).
There is another problem with the application builder that I would like
to mention. For (at least) following settings, the development settings
of a VI will not be overwritten by the Source File Settings when
building the executable :
- Window has title bar
- Show Menu bar
- Show Toolbar
- Show Scroll Bars
This is also very annoying because you will need to change these
settings in the development environement in order to get the expected
appearance in the executable.
LV8.2 English / WXP SP2

Error message "VI is not executable"! Need help with Application Builder

Hello,
I have a problem with an application, built with the Application Builder. I have read some threads about the problem I have, but I still don't know a solution.
When I run my front panel from LabVIEW, everything is good. So, now I created an application (and an installer) to be able to run it on other PCs as well. This application does not work. Everytime I start it on my PC, I get the error "VI is not executable. ...". I read in several forums solutions for this error, but I cannot fix it! I've changed my properties for the builder, but with no success. Perhaps, anybody has more ideas, what's the problem.
To get a better idea from my project, here a little description of it:
In the block diagram there is a while loop which is continuously runned. In this loop I only set some properties for the layout of the front panel, such as decorations which will be hidden/shown and changes of colours of indicators... For the rest, it waits for a click on the button "Start" in the front panel. After that, a DLL is called to communicate with a USB device. Some measurements are carried out and the DLL is closed. I hope, you can get a global idea from my block diagram...
I use LabVIEW 8.5, the DLL is a third-party DLL, which we wrote on our own. But I think the DLL works properly, if it is called from a C# application it works and it works, too, by calling it from LabVIEW when I am in development mode.
It's a project for university and I'm just a beginner in LabVIEW, so I don't have so much experiences in it, but I think i improved my knowlegde about LabVIEW very well in the last weeks!
So, i hope to get an answer soon (the deadline for the project is not soooo far away )
If you need more information, please let it know...
I would be very grateful if there is someone with a working solution...
Kind regards from the Netherlands,
Sebastian

Sebastian,
Your architecture makes it very difficult to debug this and other problems. Does the error message mention which VI is causing the problem? It is very important to wire your error clusters everywhere. In LabVIEW, when a node throws an error (Error.Status = T), future nodes do not execute. At the end, place an error cluster indicator that you can see on your front panel. When an error posts, you can right click the indicator (even in a compiled application) and select "Explain Error".
This is a start, but you really need to push this into a queued-state machine before this gets any more complicated. As it were, if anything in your loop hangs, your whole application hangs. See attached for a queued-message handler (not advisable for actual applications, but you get the point. You would want to have a type defined enum in lieu of strings, and shared data between states differently, etc.)
-Jason
Message Edited by LabBEAN on 01-20-2009 08:36 AM
Certified LabVIEW Architect
Wait for Flag / Set Flag
Separate Views from Implementation for Strict Type Defs
Attachments:
State Machine.vi ‏18 KB

Can't remove Front Panels in Application Builder

I have had a few issues using Application Builder (v7.1) in regards to it removing or not removing front panels for my subvi's when I was trying to compile. Here are the conclusions I came to if anyone else runs into the problems I had.
Problem 1) Some of the front panels were being removed for dynamically loaded VI's, which were not set as dynamic VI's in the Application Builder, but which were static-linked VI's in the program (so they were loaded in memory as linked subvi's but called dynamically). When the Application Builder decided to remove the front panel for those VI's, there was an error when loading them dynamically.
Problem 2) Some of the front panels were NOT being removed for subvi's that I didn't want to have their front panel built into the compiled program. Loading front panels that are not needed uses extra memory, but there was no way to change the option to not load the front panel for certain particular subvi's in Application Builder--the option was grayed out.
For problem 1, I decided not to worry about linking the files dynamically in the Application Builder, but to just make sure the Application Builder would include their front panels. For problem 2, I had to figure out what was making Application Builder force the front panels to be included when I deemed it unnecessary, so that I could fix them not to be included. Basically then, going through my VI's that were forcibly included, I came up with a list of stuff I began checking for each time I would run into one where I didn't want to include the front panel. I have attached my list to this post.
My solution for problem 1 was then to use a customized appearance for my static-linked / dynamically loaded VI's, and disable the menu bar (forces the front panel to be included by Application Builder without changing appearance, since I never actually see the FP). My solution for problem 2 was often to remove property nodes referencing text on the front panel controls. Sometimes I was able to perform a numeric->text or enum->text conversion instead of referencing the text of the control itself, and sometimes I realized I didn't want anything to change and that it was ok to include the front panel so I could (for example) get a list of strings for my enum control.
I have attached the reference list I came up with of things to check for to make sure your VI properties are set correctly if you are trying to get Application Builder NOT to include the front panel of your subvi. The list might not be complete, but it's helped me to narrow down things very quickly and find the problems I was having.
Attachments:
ThingsToCheck.doc ‏61 KB

m3nth wrote:
Problem 1) Some of the front panels were being removed for dynamically loaded VI's, which were not set as dynamic VI's in the Application Builder, but which were static-linked VI's in the program (so they were loaded in memory as linked subvi's but called dynamically). When the Application Builder decided to remove the front panel for those VI's, there was an error when loading them dynamically.
This is expected behaviour. The application has no way of knowing that these VIs will at some time be called dynamically. That would require analysing and understanding the entire program and in cases where you calculate the dynamic VI to be called at runtime it still wouldn't be feasable to do so.
m3nth wrote:
Problem 2) Some of the front panels were NOT being removed for subvi's that I didn't want to have their front panel built into the compiled program. Loading front panels that are not needed uses extra memory, but there was no way to change the option to not load the front panel for certain particular subvi's in Application Builder--the option was grayed out.
There are several reasons why a front panel is needed. One of them is when the VI is called dynamically, even if the FP is never displayed and AppBuilder will account for that for VIs which have been added as dynamic VI to the project.
The other is when a VI uses some Property Nodes or Attribute Nodes as they are called now.
So to solve your problem 1) you could also just drop some property node in the diagram of such VIs and be done with it.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Application Builder and Corrupt VIs

Howdy All,
I'm developing a Medium-sized application in LabVIEW 7.0 used for instrument control. This application has grown over-time, and currently contains approximately 400 VIs. The basic structure of hte appliation is one main VI that has an instrument status display on the bottom, and a sub-panel on the top, into which all dialogs are loaded for user interaction. Each major task has it's own VI that is loaded into the subpanel as appropriate.
I've read a few stories on the developer exchange about VIs becoming corrupt. I thought these were freak occurences, because by and large, it appears that LabVIEW is fairly stable. However last week I had a VERY scary experience.
I was demonstrating to a collegue the properties of an XY graph control. We changed the colour of one of the plots, then hit cancel. LabVIEW complained of an internal error involving undo.cpp and proceeded to crash. I figured the crash was caused by some strange sequence of events, didn't think much of it, and reloaded my application. After making some changes, I went to the Application Builder to build the application. However the application Builder was complaining about a "missing board" in the DEFAULT build file. I knew immediately that something was VERY wrong. (When I say default build script, I'm referring the default script that is loaded when you press the "Build application or shared library..." button in the tools menu).
(As a side note, does anyone know why the LabVIEW application builder gives such terrible error messages? I always get that "missing board" error when either: one of my support files cannot be found, or one of my dynamic VIs is not executable. Since the error doesn't pinpoint a file, I neeed to go through the files one by one - which is a pain because I have a lot. Another question, why does the application builder ALWAYs ask if you want to save changes to build script, even if you haven't made any changes?)
After loading my build script for the application (which I've used HUNDREDS of times), I got the "missing board" error. I didn't think there was a problem with any of my paths or VIs, but I went throgh each included support file and dynamic VI in the build script to make sure it was there. Though there seemed to be no problems with any of the files, LabVIEW continued to complain.
I figured the problem was specific to the computer I was working on, so I copied the source to another development machine to complete the build. I was VERY scared to find that I got the SAME error on the DEFAULT build script! Also, my actual build script refused to load properly.
This was late at the end of a long day, so I decided to turn of my machines and go home. The next morning, everything worked fine - I was able to build the application, and I haven't had a problem since. (Maybe it was a bad dream, but I have clumps of hair on my desk from the night before...)
I found this experience to be UTTERLY TERRIFYING. Once I had to revert to an archived copy of one of my main VIs, because the current version refused to open, claiming it was corrupt. Since I don't know what's going on behind the scenes in LabVIEW, I'm afraid that tiny internal LabVIEW errors might be adding up. I back-up the source very regularily, since it is such a large project, however I have *real* way of inspecting the integrity of the source.
Does anyone know (A) why this might have happened - especially when the problem reproduced itself on multiple machines (B) has anyone had similar experience with internal LabVIEW errors or corrupt source (C) what sort of internal errors might be piling up that might cause a VI to claim it is "corrupt".
All input is appreciated.
WG

Hi Robert,
For the undo.cpp error, I got a couple different line numbers but didn't write them down. If I get them again, I'll be sure to get the specifics for you.
As for the "missing board", I also got that description a little wrong - the error I'm talking about is:
"Error 7 occured at Inovke Node in Dist read linkages.vi->Dist Cmp Settings to Disk Hier.vi->Build Application.vi
Possible reason(s):
LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for hte operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Unix.
NI-488: Non-existent board."
As you can see, I meant "non-existent board". This error is very easy to reproduce - m
ake a build script and include some extra files. Save and close the build script. Move or rename some of the extra files included in the build. Reload the script. You should get that not very helpful error.
Now that I think about it though, maybe that NI-488 error refers to GPIB control, which I think I have installed, but don't have a GPIB card installed... hmmm... no reason that error should be popping up *there* though...
I could have *sworn* I would also get that error when one of the dynamic VIs in the build is not executable, but I can't seem to reproduce that right now.
Tying back to the original thread - what makes a VI corrupt? I imagine if you cracked the binary file open yourself and messed around with some bits you would probably make the VI corrupt, but I'm assuming that editing a VI normally (ie through LabVIEW) should NOT cause the VIs to become corrupted. Any information on VIs becoming corrupt? Is it somehow related to the undo.cpp errors?(when trying t
o undo some last change that wasn't recorded properly, the VI is modified improperly - after you save and close, it won't reopen?)
Victrick

Application builder exe does not load excel

I have used application property node and invoke node to cerate a set of VIs that read and write data to an Excel sperad sheet. This works fine in when running in LabVIEW, however when I run myApp.exe as build from application builder, the data does not get logged to Excel. The file dialog appears to open the XL Spreadsheet but not data gets logged nor is any error reported?
What is going on? All the VI are in the same project folder? Is there some additional addon run-time the must be installed on the target machine? I am uisng LabVIEW 2012 on the development station with Win7 Pro and Office 2010 on both the devleopment station and the target system. Is there one document that describes using Application Builder? It was not clear that I needed both LabVIEW and VISA run-time engines to get my application.exe to run on the target. Is there something simialr I must do to get Office to work as well?

I was finally able to track this back through by starting from scratch and received an error code, which led me to this post:
https://forums.ni.com/t5/LabVIEW/Error-2147319779-Excel-ActiveX-and-Broken-LabVIEW-Icon/td-p/2354776
Deleting the "1.7" items solved the problem.

"file already exists in the destination" during application build

I am trying to build an executable and have gotten the following error:
The file already exists in the destination.
C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Sentech LV 82\Shared Library - Trigger SDK\StTrgApi.dll
WHen I start the build I go to "Build Executable" then click "Build"
The VI for the project I have open is the Startup VI and I do not list any Dynamic VIs or Support FIles.
I am using Labview 8.2
I installed a user library for a USB camera from Sentech wich I am using and it works fine in Labview 8.2
When I try to do the build I get the error shown above. The file it is referencing is there along with the .lvlib file.
I tried removing the file shown in the error message to see what would happen and I continue to get the same error even though the file is not there. I even restarted LV and still got the same error.
I am new to the application builder (v7 ?) and have not been able to find any good tutorials. Does anyone have any ideas on this error or a good place to learn more about app builder.
Thanks
Keith

I am new to the application builder (v7 ?) and have not been able to find any good tutorials. Does anyone have any ideas on this error or a good place to learn more about app builder.
Thanks
Keith
Hi Keith,
you can check this Link out for a tutorial on app builder.
Regards,
Denver

Projects, application builder LV7/LV8

Similar Messages

Maybe you are looking for