Missing Build Specifications in LV8 Full Development package

After installing LV8 Full Development Version, the only Build Specification option available is "Source Distribution". The options "Application", "Installer", "Shared Library" and "Zip File" are missing. The correct serial number appears on the About screen so I assume I activated the package correctly.
How do I make those other build options available?

Buy the application builder - or upgrade to the professional version...
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Similar Messages

Scrambled destination view in installer build specifications LV8.5

I don't think this build specifications bug has been mentioned yet. I am using LV8.5 Pro under Win XP.
When configuring a new installer build specs, under Source Files, I select my application item in the Project View and click on the arrow button to add it to the Destination View. The latter then faithfully reproduces the application files hierarchy, for example:
Application Directory
    Manuals Directory
       Manual.pdf
    Application.exe
    Application.ini
    Startup.exe
    Startup.ini
However, after I close and reopen the installer properties, the Destination View hierarchy appears scrambled, for example:
Application Directory
    Manuals Directory
       Startup.ini
    Application.exe
    Application.ini
    Manual.pdf
Supporting files get moved around the directory tree, some disapper, and others actually appear in duplicate. The outcome is exactly the same every time I repeat this process, but there is no apparent pattern to it.
Now, when I actually build the installer and later use it, the application gets installed properly, with correct files hierarchy. What doesn't work are the shortcuts. For instance, in the above example, if I create a shortcut to Manual.pdf, it will actually point to Startup.exe. And if I need a shortcut to Startup.exe, I cannot create it because the target is not part of the Destination View.
Thoughts?

Dear Zador,
Bug number 4CM921LJ titled "Shortcuts Added in Installers Are Not Created Properly" is a LabVIEW 8.5 Known Issue. More information on the bug can be found in Knowledge Base 4EGEL6HY: Wrong or Incorrectly Disabled File Names Displayed in LabVIEW
8.5 Installer Builder. If you need an alternative to the workaround presented in the Knowledge
Base, you can create separate folders for each file you need to have a
shortcut created for instead of putting them all in one.
This issue has been fixed in LabVIEW 8.5.1. Please post back bug 4CM921LJ does not describe your problem.

Build specification missing properties

I have created a build spec for my project but the tabs for Dialog Information, Shortcuts and Additional Installers are missing. See attached screen shot. How do I make them appear?
David
Solved!
Go to Solution.
Attachments:
My build spec.png ‏81 KB

You will create two specifications: (1) build the exe. (2) build an installer for the exe. One you have both in your project, you can do a "build all" when right-clicking the build specifications section header.
LabVIEW Champion . Do more with less code and in less time .

The VI is not executable. The full development version...

"The VI is not executable. The full development version of LabVIEW is required to fix the errors." That is the error I've been dealing with all day. Actually it is repeated 3 to 4 times in the error message, seen when first launching the EXE. Also of note is that the run-arrow is broken. This is in an EXE that was developed well before version 2013, but I recently upgraded it to 2013 to hopefully fix some random LVRT crashes. There is obviously no issue running the code on my development machine, only once it's deployed.
The good news is I've been able to solve the problem (mostly). My EXE now runs without the errors. I found that the problem wasn't actually in the EXE.
We have a separate project with no files, but in the build specification we have the LabVIEW 2013 Run-Time Engine, as well as NI-VISA for serial support. We then bundle the deployment in a self-extracting RAR and it does its business. In the past this has worked just fine, but with LV2013, it seems that there is a component missing from the deployment.
I found that if I download the Run-Time Engine directly from NI.com and run it, the only things I need to install are the Run-Time Engine, and the DEPLOYABLE LICENSE. If I do this, my EXE runs great, but with the custom installer, it is not included for some reason!
Putting aside the fact that I don't know why the Deployable License package is needed (we aren't connecting to remote panels), I can't seem to modify my custom installer to install the Deployable License. There are versions for LabVIEW 2009 and 2011 SP1 in the Additional Installers list, but I don't see 2013.
Can anyone explain why this is??? For now I will just distribute the 257MB Run-Time Engine and the NI-VISA installers separately I guess. But I'd really like to get back to a single, simple package to install all the prerequisites we need. HELP!

iannicholson wrote:
Yes, but then every installer I build will contain the runtime engine. That gets very large very quick. So I have an installer for JUST the runtime engine and VISA runtime.
Just remove them from the "Additional Installers" tab of the Installer dialog.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Use of "Open FPGA VI Reference" function --- Build Specification vs VI vs Bitfile

When using the "Open FPGA VI Reference" function in a LV2012 cRIO application, there are 3 options: Build Specification, VI, or Bitfile. What would be the reasons for selecting one over the others? Does it affect the resulting startup.rtexe when the cRIO application is built? I searched through the help and in these forums, but I don't see criteria for selecting one over the others; maybe I missed it.

Hello Chris,
Apologies in advance for a long reply.
The reference method won't change the functionality of your rtexe.exe. They all end up dropping a bitstream, based on a bitfile, onto the cRIO's FPGA.
To a degree, the method used to reference the FPGA code is a matter of taste, but there are situations where one method is better suited than the others.
Reference by VI:
Setting the configuration options to open reference by VI is helpful during development when you are making changes to an FPGA VI often and building/testing using the same spec. When this option is used, a bitfile is selected based on the default build specification for the project. A project may have only one default build specification. You can make any build the default by checking the option under the Source Files category in the build properties. The default build is indicated in the project explorer by the green box around the builds icon.
Reference by Bitfile:
This option references a bitfile directly. Through the configuration window, you can select one specific bitfile to open a reference to (this is not dynamic and does not change unless you physically go make a change to that path). If you're using this method, it helps to give your bitfiles more meaningful names than the ones that are automatically generated by LabVIEW. When you run subsequent compilations off of the same build specification and do not change the bitfile nname or path in the build configuration, the old bitfile is overwritten and replaced with the new one. When you are using this option, it is critical that you keep up with which bitfile is the one you want to be using. There is an option now that will help alleviate any problems referencing by bitfile through the Open FPGA VI Reference function. There is a new VI called Open Dynamic Bitfile Reference. It is typically used when you want to chose a specific bitfile to load depending on something in your host code (a configuration option etc) - but it allows you to dynamically reference a bitfile on the block diagram by path.
Referency by Build Specification:
This option is good for when you want to always use a bitfile that is associated with/compiled with the same build configuration. Say you have two options for top level FPGA VIs in your project (each with its own build spec). Both of these VIs have the same interface (read/write controls, DMA) but they run different algorithms or something. This is nice because you can easily switch your host application between them by picking the build spec associated with the FPGA VI you want to use. In this type of sutation, referencing by VI is no good because you can only have on default build spec.
cheers.
Matthew H.
Applications Engineer
National Instruments

I recieve the following error when running an executable ("This VI is not Executable. The full development version of Labview is required to fix the errors"

I recieve the following error when trying to build and run a labview executable. I am able to build the executable but when trying to run the executable, a pop up window comes up asking the user to select a dll. (please see screen shot attached). Once the DLL is selected, I get the error that This VI is not Executable. The full development version of Labview is required to fix the errors. (please see screen shot attached). I have also attached a snapshot of the project window.
I have the professional development system
I can run the main VI
all the required DLL's are in the dependencies section of the project window.
I am trying to find the root cause of this error but to no avail. can anyone give me a clue to what i am missing here. Any suggestions on where i should look to find the problem ?
Thanks in advance to all labview users for your help
Attachments:
project window.PNG ‏36 KB

other PNG
Attachments:
Broken Arrow on EXE.PNG ‏179 KB

"VI has error of type 1002288.The full development version of LabVIEW is required to fix the errors"

Hi,
I had created an executable in LabVIEW 8.6 on a windows XP 32 bit PC. The application uses some Vision VIs. The executable runs in most of the PCs except one. the PC is a windows 7 64bit. Initially i got the error "Labview Load error code 3: could not load front panel". I fixed this by changing the source file settings in the application builder. Now i am getting the error "VI has error of type 1002288.The full development version of LabVIEW is required to fix the errors" and the exe shows a broken run button.
But if i build the exe in the same PC i get no errors and it works fine. Moreover i have tested this exe in a different PC with the same configuration, it works there. I have tried reinstalling labview in the PC the problem still persists.
Solved!
Go to Solution.

Hi Rajshekar.
> Which version of LabVIEW are you using on PC with Win7 64bit? would like to check if there are any issues with LV2009 32bit on 64bit OS..
- The version of Labview on the win7 64bit PC is also lv8.6 full development system.
> Do you get the same error on the other PC with same config(Win7) when running the .exe generated using LV 8.6 on WinXP 32bit? just to make sure the problem is with OS or LV..
- the same problem occured at one more PC with the same configuration. but when i tested in an another PC of the same config it worked i am not able to isolate and decide that the error is based on one particular PC config.
I have listed the environments in which application ran and how the application was put in to the PC.
I would also like you to know that i have created an installer for the exe. I am also using NI vision in my application and this is the error "An error occured loading VI 'IMAQ GetImagePixelPtr'. LabVIEW load error code 3: could not load front panel"....and rest is what i said in my previous post
1. Use the installer to install the application.
2. just copy the exe created in LV 8.6 into a PC that already has LV development system installed in it
3. The PCs might either be a blank one with no history of LV installed in them
4. The PCs might have diffrent versions of LV development systems installed in them (8.2,8.5,8.6,2009)
All PCs that have LV development system(s) installed in them, was able to run the application except the one with win7 64, where i have tried uninstalling all NI software and use only the installer to install, install LV 8.6 full development system and try runnning the exe, nothing works.
Thanks

A full development version of labview required to fix the errors.

When i tried to run my exe file, it gives following error.
"A subvi is not executeable.A full development version of labview required to fix the errors."
i do have full version of 6.02.
Am i missing something something when i built exe?
any Help will be appreciated.

Well, here we go again...
I have seen this error way too many times in my day.
The problem is you have a bad linkage, or unsaved or compiled VI in your hierarchy when you built the application.
Open your main, or otherwise open (into memory) ALL VIs in your hierarchy. Then, do a save all from the file menu. This should solve the issue.
The other reason I have seen this is if you have bad linkage. As there is no real way to tell what your linkage is, you need to go into the hierarchy, select View Full Path in Title and make sure everything is where you think it is. I have often seen this occur even when the application I was building from was in perfect condition. Often times, when the app builder is used, VIs will be called from locations you
don't expect.
You have to be VERY careful about developing in a hierarchy. I actually got to a point where I had to even place all the NI VIs into my directory structure.
Take a careful look at the hierarchy. Chances are the executable is calling the wrong code, or is compiling with the wrong version.
If in doubt, go to a fresh machine, and move all of your VIs (individually if you have to, or as a .llb preferably) to the new machine and build it from there. Alternatively, you can try doing a save as from your main and select "application distribution" this will resolve any issue with VI locations, except where Dynamic VIs are being used.
Good luck, 'cause you are going to need it.

Please help suggestions for solving built-only compiler error: 'The VI is not executable. The full development version of LabView is required tofix this error.'

We have develoepd a software tool and build it on regular basis. It currently runs error free when compiled in the editor, but when we built it and run the executable stand alone we get the error.
'The VI is not executable. The full development version of LabView is required tofix this error.' plus a broeken error.
This menas an compiler error that is not present in the editor but in the stand alone version. We tried to identify errors as suggested in several posts in this forum, but so far unsuccesfull.
As the editor and its compiler do not see the error and are running fine and the stand alone version just syas 'find the error in the editor' in this case LabView is of no help.
Can anyone suggest a sensible or 'good practice ' way of searching for the source of this error?
Our project comprises hundreds of Vis over several libraries.
Thanks,
Chris

Thanks Craig for all your suggestions.
We seem to have located the problem in a new vi just added to the package causing conflicts by using the same vi names as other vis already present in the package. Excluding this vi removed the error.
It seems related to a conflict by having two vis with the same name, which was mentioned by LabView and interactively resolved when running the main vi from the editor. When successfully building the main vi the builder did not mention this conflict and reported a successful build, but when trying to run the executable it gave the cryptic error. The error caused us problems because there was no hint for the cause, just the suggestion to solve this in the editor, while at the same time in the editor the VI was running fine.
We will post about this in detail after we have positively proven that this actually was the case.
The .net version issue was already checked.
Performance was the same on all machines we tested on including the dev machine.
Debugging was tried nut did not help as the vi could not run (broken arrow). We assumed that debugging only helps in running faulty functioning vi''s. We did not check for broken arrows in sub-vis (after connecting), that could have helped, although our application has hundreds of our own vis.
In relation to your remark:
'Are you using many classes? Have you verified that the proper access scopes are set for functions calling those vis?'
Could you elaborate on setting access scopes. We were not aware of this option in LabView, although we realize this is a basic element of the underlying c code.
Ragrds,
Chris

Build Specification does not include all files for my VI.

Hi!
As a part of a semester project i have build a VI to control a filtration unit. The VI is working fine on my computer, but I graduate next month and I have to deliver the files on to a person on the university. The problem is that even though i use the "Build Specification" function (i use LabView 2011 Professional Development System), files are still missing when the program is started on the new computer. A warning in the project file indicates that files are missing or removed to a different location. A file named pid.lib is not found, and it seems like the path to each file is the same as on my computer, but the build specification doesn't change that to fit the new computer.
I am a LabView newbe, and I have searced this forum and help files to try to solve this by my self, but now my time is becoming limited. Can anyone help me with this?
Henrik jepsen
Masterstudent Chemical Enginnering
Denmark
Solved!
Go to Solution.

Hi Henrik
You can see what versions of LabVIEW and which Toolkits is installed in Measurement and Automation Explorer (MAX). If you Open MAX, and Select "My System" --> "Software in the left menu, then you can see all software installed.
If you click on the LabVIEW installation. In this case LabVIEW 2011, you can see all toolkits installed.
When you run a LabVIEW project / application on another PC, LabVIEW will use a defined priority of where to load the files from. This is specified in Tools --> Options --> Path --> VI Search Path.
So LabVIEW will frist try to find the VI/VI library in the folder of your project and if the VI is not located there it will look for it as a build function in the vilib, userlib or instrlib folders of LabVIEW. These folders contains VI's and VI libraries installed with LabVIEW.
In this case, as mentioned above you properly don't have the same toolkits installed on both machines. Therefore the PID.lib is not found in the vilib folder as it should be, and thereby you get the error. You can confirm this by reviewing the installed modules as mentioned above.
Best Regards
Anders Rohde
Applications Engineer
National Instruments Denmark

Development packages in Arch [SOLVED]

Hi all,
I need some development packages to build some programs, but I cannot seem to find them in Arch. I was wondering if anyone knew if they existed.
Examples are:
freetype2-devel
libjpeg-devel
xorg-x11-devel
Obviously if you ignore the -devel part, I can almost always find every single package in Arch. For example freetype and libjpeg and xorg are here, but their -devel counterparts are missing. As these are required to build packages, and Arch sometimes requires us to do so, how can they be missing?
Thanks

I just missed your post! Was about to come here and thank you for the solution
Cheers miqorz

Why does Build Application vi work in development environment but not in executable; error 1025

Hello,
I have an application ("A") that I am trying to build using another application ("BuildA").
I can create an application for A manually from its project using the Build Specification, and it works fine (A.exe).
Also, when I run BuildA.vi in the development environment it calls the "Build.vi" correctly and again builds application A.exe just fine.
Then, when I make BuildA an application (manually) and run BuildA.exe, I would expect it to also create A.exe just like BuildA.vi did in the development environment.
However, it fails with the error:
Code: 1025
Open VI Reference in NI_App_Builder_API.lvlib:Build (path).vi->BuildA.vi<APPEND>
VI Path: <b>C:\TEMP\AppBuild\BuildA\vi.lib\AppBuilder\BuildTarget.vi</b>
I noticed this thread , which looks like a similar problem, but no conclusion was reached.
Why does BuildA.vi work fine in the LabVIEW environment, but the application BuildA.exe does not work? All paths are hard-coded, so it shouldn't be a path issue.
Thanks,
-john
Solved!
Go to Solution.
Attachments:
AppBuild.zip ‏175 KB

Interesting code. I'm curious how you came to decide 324ms in your while loop, and 58 in the other, and then 5136ms at the end. In any case I suspect this has to do with this line of text in the help of the Build.vi.
If you plan to run a build specification on the LabVIEW Run-Time Engine, do not include the Build VI in any of the VIs for the build specification.
I don't fully know what this means but it might be why it isn't working.
The Build.vi opens all Context (application instances) and then looks for the one named "NI.LV.MxLvProvider". This I assume is a application instance NI uses to build applications. It then uses this and opens some other VIs in this instance for the building. The error you are getting is "Application Reference is invalid" meaning it couldn't find the NI.LV.MxLvProvider instance it needs to build. Again I believe this maybe because you are in a run-time environment and that instance doesn't exist there.
At the end of the day I'm guessing since Application Builder is not free, NI probably doesn't include it in the Run-Time engine, which is free. So you can't build the way you want. You could have and EXE running in the run-time open an instance in the development, then run your VI from there if you must make this an EXE. It maybe easier to just edit the BuildA.vi to have a "Run When Opened" so that you double click the VI and it runs which behaves like an EXE sorta.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

Instrument Control Build Specifications

Dear Sir:
      I am trying to build a working *.exe instrument control program. This is a simple program which only queries my test instrument with a *IDN? command.
      The program fails to call my instrument driver and the program also runs on boot up when (running under normal conditions) it should wait for me to input the GPIB address of my test instrument.
      Let's begin with the failure of Labview to communicate with the instrument driver.   This is some background information.
       When I run the program as simple *.VI in the Labview environment, the program runs perfectly.    No issues.
       When I use Agilent Connection Expert or MAX to communicate to the test instrument, communication is established and there are no issues - I receive a reply, connectivity is established.
        After I build the *.VI into a *.EXE program, this is where the program's issues arise.
       The *.EXE program fails to initialize correctly and fails to establish connectivity with my test instrument.
        Here are some issues that I have noticed about the program running in *.EXE mode
1) The program runs on "boot up" when you click on the *.EXE program.   In *.VI mode, the program does not run on boot but waits for the user to input the GPIB address of the test instrument - program run is designed to be enabled by the user.
      I do not believe this is the source of the problem but only an incidental consequence of the problem.   If I stop the program and input the GPIB address, I receive a message about not being able to communicate to the driver.
2) Once the *.EXE program runs, there is a condition whereby the operating system cannot close the program and WINDOWS itself cannot shut down itself unless I manually close all the programs associated with the *.EXE program in the WINDOWS operating environment.
3) If the labview program and *.EXE program are closed but the operating system is still running, Agilent Connection Expert and MAX can no longer communicate with the test instrument.   They no longer see the test instrument.
It is obvious that the *.EXE program is making a change which is causing the operating system to "hang" on shutdown and is also preventing the other programs from operating as they should.
I believe the source of my problem may be how I programmed my build specifications.     In reply, can you please tell me what are the minimum requirements for the build specification so that my test instrument can reply to a simple *IDN? query?   What files are normally required for a successful build?
Other information as to the source of my issues are welcome as well.
Thank you.
Solved!
Go to Solution.

Thanks for you advice.
I think this problem is a lot easier than you might think.   I just started using Labview and the *.VI is super simple. I am away from my development computer right now so I can't post it.
The information I need to know right now are the typical files that are needed to be added in the build.
I found this quote that I found on a webpage to be interesting, (although I am not building an installer):
" Do I need to include NI-488.2 2.7.3 module if I use only basic GPIB Write.vi and GPIB Read.vis in my project?
Yes, if you are making an installer ..."
This is a link to the webpage:
http://forums.ni.com/t5/LabVIEW/Uninstalling-LabVIEW-after-an-application-EXE-build/td-p/1553310
My program involves only simple reads and writes using NI-488.2 calls to a test instrument.   A simple list of files specified with filename extensions to get me started would be appreciated.

[SOLVED] Confused about development packages

To build an embedded linux image using minifs utility, I need to install some development packages. The packages listed in the tutorial are named for Debian based distros, with the "-dev" suffix. Some of the listed packages are: libz-dev, libelf-dev, libelfg0-dev, libncurses-dev, etc.
I can't find these packages, and I'm a bit confused. I have read that these packages in Arch Linux have different suffixes denpending on the origin (-cvs, -git, etc.), but I can't find any packages with that suffixes. For example for ncurses:
$ pacman -Ss ncurses
core/ncurses 5.9-3 [instalado]
System V Release 4.0 curses emulation library
extra/cmus 2.4.3-1
A very feature-rich ncurses-based music player
extra/finch 2.10.1-1
A ncurses-based messaging client
extra/moc 20110528-5
An ncurses console audio player with support for the mp3, ogg, and wave
formats
extra/naim 0.11.8.3.2-2
An ncurses AOL Instant Messenger and IRC client.
extra/ncmpc 0.20-1
A ncurses (command line) interface for MPD
community/echat 0.04beta1-3
vypress compatible ncurses chat (can work without server)
community/ekg2 0.3.1-2
ncurses based Jabber, Gadu-Gadu, Tlen and IRC client
community/ncdu 1.8-1
Disk usage analyzer with an ncurses interface
community/rtorrent 0.8.9-2
Ncurses BitTorrent client based on libTorrent
community/ruby-ncurses 1.3.1-3
Module for interactive text console applications (ncurses)
community/sniffit 0.3.7.beta-11
very good packet sniffer for unix with ncurses interactive mode.
community/vifm 0.7.2-1
Ncurses based file manager with vi like keybindings
community/yacpi 3.0.1-3
ncurses-based acpi monitor.
No ncurses-cvs, ncurses-git, ncurses-svn or the like is found. How can I find development packages?
Last edited by doragasu (2012-03-09 22:38:03)

doragasu wrote:So in Arch, packages include not only binaries + resources, they also include header files? If I install for example ncurses, also header files for ncurses get installed?
headers, pkg-config, everything in one package, that is required for a compilation. we keep stuff simple
Last edited by wonder (2012-03-09 22:37:46)

Labview project build specification

I created a LabVIEW8 project. WIthin it I have a few folders that organize my code. I'm trying to create a Build Specification (found at the bottom of the project view). I created a new Build Spec and began populating it. I can add information to all fields, except the Source Files category. When in the Source Files category I'm able to specify the Dynamic VIs and Support VIs in the bottom box by selecting Full OI - Top Level VI.vi. However, when I try to select any single file (Launcher.vi in this case) as the Startup VI, all my VI files become grayed out. I can't select any of them. I tried placing my launcher file in a new folder (apart from the majority of my code). It allows me to move the folder into the Startup VIs area, but when I say 'OK' or 'Build' at the bottom, it comes back telling me that it can't continue because I haven't selected a Startup VI. Any ideas?

Have you tried saving the project and trying again. I tried to create one on the fly and it wouldn't allow me to select it as a top level VI until I saved the project and the VIs in the project. Give that a try and let us know how it goes.
Tyler H.
National Instruments

Missing Build Specifications in LV8 Full Development package

Similar Messages

Maybe you are looking for