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

Similar Messages

  • How can I programmably extract the project build information set in the project build specification. So I can then use the information in an 'About' dialog.

    Extracting Project information
    How can I programmably extract the project build information set in the project build specification.
    So I can then use the information in an ‘About’ dialog.
    Dave

    In the labview\resource\appbuild folder their are some VI's that can deal with build specs! They return a variant containing the data!
    It's the reason I build a variant probe.
    Be aware that the build info is not present in th lvproj file of the built 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!

  • Programmatically get labview project executable version

    Hello,
    I would like to programmatically get the executable version number from the build specifications in my LabVIEW project so I can display it on the Title bar in my application. 
    I looked at the application properties and was able to get to the build specifications property from my project, but I could not find out how to retreive the version number. 
    Attached are screenshots of the project build specification window with the version number information I want to retreive and VI project example that I did in LV 8.2.1.
    Thank you,
    Russell
    Engineering Team Leader
    G Systems, www.gsystems.com
    Certified LabVIEW Architect
    Certified Professional Instructor
    Attachments:
    LV project executable version.zip ‏42 KB

    A LabVIEW executable doesn't have a project (that's a development tool), but this thread should help you
    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!

  • Exporting build specifications to other project

    Hai all,
    I have created the build specification for developing a exe in my project.  There are too many destination directories am creating in the project and its a lengthy process too.  Is there a way to export the build specifications (of a exe) to another project and reuse the specification there.
    I am using LabVIEW 8.5 Professional development system.
    Previous versions of LabVIEW has *.bld file that can be called while creating new exe's is there any such option in 8.5
    With regards,
    JK
    With regards,
    JK
    (Certified LabVIEW Developer)
    Give Kudos for Good Answers, and Mark it a solution if your problem is solved.

    Hi JK,
    you can open your project file with a normal editor. It is a xml file. There is an item with name = build specification. If you copy this part to another project, then it shall be possible to use it there.
    Hope it helps.
    Mike

  • Build Specifications gone with LabVIEW 2009

    I'm using LabVIEW 2009 and I still have the same problem as described in the following post (where all the answers were for older LabVIEW versions):
    http://forums.ni.com/t5/LabVIEW/build-specifications-gone/m-p/625815
    When I move a LabVIEW project from one PC to another, parts of the build specifications are gone. In the specification for the executable I have to redefine the start-up VI, the included files and the icon.
    Is this a known issue and is there a fix for it?

    Hello,
    this might be a corrupt project file. Does this only happen with this project?
    If so, then I'd suggest recreating the project and the build specifications on the original PC and trying to migrate it again to the other PC.
    Regards,
    Joseph Tagg

  • Can't access variables in specific S7-1200 DB's in LabVIEW project

    Hi all,
    I'm trying to establish a connection between LabVIEW and a Siemens S7-1200 though Ethernet and SIemens OPC Server.
    The physical connection is OK (I can ping S7-1200 with no problem).
    When I needed to access variables from specifics DB's inside S7-1200 ( I want to access variable DB190,X0.4), I called Siemens support and they said I had to modify the variable's definition when using OPC Scout, from "MX0.4" to "DB190,X0.4", and then it was possible to access this variable.
    Same solution (renaming the path) applies to NI OPC Client, I can read and write variables properly.
    My problem is that when I try to add variables in LabVIEW Project, I can't find those variables whose address were modified, so I can't access the correct variable in my program.
    I tried to change the variable path in Multiple Variable Editor, but it doesn't work either.
    Any suggestions on what I can try??

    First: Avoid the ODBC/JDBC Bridge if at all possible.
    It's the worst JDBC driver I've ever seen. It's buggy
    and a great hindrance both to learning and to
    producing usefull code.I agree that there might be problems with M$ Access, but there are problems with all databases, including MySQL (e.g., no referential integrity in free download version). It's capable enough for the query the OP is trying to execute.
    The problem is with his code, not Access or the bridge driver. He'll go through a lot of effort to switch databases and still have this problem. Better to understand what HE'S done wrong and fix it so he'll do it correctly for all databases, including Access.
    You just need to be more careful with your query, I'm sure.
    %

  • 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

  • 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.

  • 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.

  • Programmatically Changing Build Specifications from command line

    I use a batch file that calls a VI to build several LV projects.  I found the article http://zone.ni.com/devzone/cda/epd/p/id/5051 to get started and build projects; however, I was wondering if anyone has been able to change build specifications without opening the Application Builder dialog?  -> I would like to build an app. with a version number using the command syntax:  labview.exe <mybuild.vi> -- "project1.lvproj" "version number"
    Any thoughts regarding this problem?
    Thanks,
    Adam

    I have done some research and there doesn't seem to be a way to change the version number when building a project with this method.  If I find out otherwise I will post to let you know but I don't think it is possible.  I would look for another way to accomplish what you want by incorporating the version into the file name or something like that. 
    Eric A.
    National Instruments
    Distributed I/O Product Support Engineer

  • Some build specifications change on different machines

    Hi all,
    I often need to move my LabVIEW projects from a machine to another one. In this cases, I copy all the contents of my project folder in the new machine.
    My projects are built without errors, but some build specifications are not kept.
    Build specifications that are not maintained are additional installer list (see attachment).
    In the machine 1, I include only Math kernel Libraries and NI VC2008MCMS.
    When I open the same project on the Machine 2, all the elements in NI LabVIEW Run-Time engine 2012 SP1 f3 list are checked. (see attachments)
    Thank you
    Attachments:
    machine1.png ‏5 KB
    machine2.png ‏5 KB

    Hi AC_85,
    have machine 1 and machine 2 the same installed software? Is it the same version? Maybe on the machine on which you copy your project some additional installer is not installed.
    You could try to Duplicate the entire project (from project explorer File >> Save as >> Duplicate project >> Include all dependencies) before moving it from machine 1 to machine 2.
    Hoping this will help you.
    Best Regards.
    Cla_CUP
    NI ITALY

  • Build specifications menu empty

    Hi there,
    Im currently trying to create a dll from a Labview project, following the instruction from this webpage : instructions on creating a dll from LV.
    My problem is, when I right-click on "Build Specifications" I only have one item to choose from the "new" menu, which is "Source distribution".
    How can I get the other options ? (I had the same frustrating problem when I tried to create an executable file).
    My version of LV is 11 btw.
    Thanks in advance for any help

    Hi Johndoe77651244,
    Do you have application builder installed into your computer?
    You will need it to create a dll.
    More information of application builder can be found from the below link,
    http://sine.ni.com/nips/cds/view/p/lang/en/nid/210592
    Best regards,
    TuiTui

  • Build specification Destination Does Not Preserve Hierarchy

    I have a destination configured in my build specification (application) so that I can include required LabVIEW and non-LabVIEW files in my builds.  This destination is configured as a directory with "Preserve disk hierarchy" checked.  Under "Source File Settings", I have one of the folders in my project configured to use the aforementioned destination.
    There are two issues that occur when I build my application.  The first is that it ignores empty folders entirely.  The second is that I have one folder that contains files (this folder is a child of the folder that is listed in the build spec) and when I build, it completely ignores the child hierarchical step.  I.e. It omits the child folder completely and put's the child folder's contents in the parent/top-most folder.  E.g.:
    Source:
    source/ParentFolder/ChildFolder/file1.ext
    source/ParentFolder/ChildFolder/file2.ext
    Build Result:
    builds/ParentFolder/file1.ext
    builds/ParentFolder/file2.ext
    If I put a dummy file (or another child folder with a dummy file) in "ParentFolder", it will then actually preserve the hierarchy of the files (empty folders are still ignored though).  Note that the ParentFolder is "Always Included" under the build spec's "Source Files".
    I need to be able to preserve the hierarchy without having to use a dummy file (this would be extremely confusing and could get deleted easily by future developers) or having to remove this hierarchical step in the folder structure (this code was inherited).
    I'm using LabVIEW 2013 SP1.

    Actually this has been discussed before -- a lot. The builder will not create an empty directory, and it only counts files as contents.
    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

  • 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 .

  • Project build includes wrong dll path

    Hi everyone
    Im doing a test project for a customer at the moment.
    The project is based around TestStand 4.1 and LabVIEW 8.6 and is to be executed on a platform consisting of a pc connected to a PXI
    rack with a SCXI in series. The software on the pc is a custom operator interface configured with a TestStand Base Deployment engine
    license, and LabVIEW 8.6 RTE.
    The LabVIEW source part consists of around a thousand VIs organized in a single project, nicely divided into grouped blocks of related code, forming small modules that can be called from TestStand.
    One of these module uses functions from a .NET class library and contains a single master VI
    that keeps track of all the tedious tasks the library performs.
    For nearly every module in the project there's a build specification so that each module can
    be linked into a single .llb file surrounded by the shared functions across llb's.
    Because of the way the project is organized i've defined the build specification in such a
    way that the DLL is included as 'always-included' and has it's own destination folder.
    Also FYI, the whole project is under source control by means of Tortoise SVN.
    Now to the weird part:
    When i build the distribution that references the class library, the path reference in the
    VIs doesn't seem to reflect the destination path for the library.
    Using a simple ascii viewer i'm able to see that the distributed main driver VI still contains the SVN source path to the DLL.
    Is this expected behaviour or did i miss some information somewhere?
    This is giving me a headache at the moment since TestStand reports a broken VI whenever the
    driver function is used.
    I would expect that LabVIEW updated the path in the VIs referencing the DLL to wherever the
    specification states the DLL to be placed, but this seems not to be the case..
    Any feedback or links to information about this would be greatly appreciated!
    Thanks

    Thanks for your answer..
    However the library is a .NET class library and as far as i know there's no way to do late binding to .NET libraries in LabVIEW?!?
    Please correct me if i'm off course here..
    My solution has been to define the build specification so that the library always gets copied to the same folder as the VI that uses it.
    Also i forgot to mention that building the class library as strong named so that it can be registered in the GAC is not an option at the moment!

Maybe you are looking for