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.

Similar Messages

  • 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

  • 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

  • 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

  • Build specifications gone

    LV 8.5 on XP Pro
    I have a project with the build specifications for an executable.  The problem is that the startup VI's that are designated in the properties keep coming up missing.  The ICON is still in the project, but when I go into the "source files" they do not seem to save.  The problem is intermittent.  I have tried entering the properties, saving and then closing and reopening LV and had no problems but then the next time I go to do a build I receive error "You did not specify any Startup VI's." 
    Also the installer properties continually are corrupted and I have to re-create the installer.
    Any suggestions?
    ~gold 

    Hey Gold,
    Thank you for contacting National Instruments.  I'm not exactly sure if I understand your problem, so I do want to clarify what you have going on.
    If I understand you correctly, you have a project with VI, documentation, etc, to create an exe as well as an installer.  All files appear in the project explorer, and there does not appear to be any problems with the files there.  When you go to build an exe, you select your startup VIs, and move them into the Startup VI's section of the build page.  When you go to click build, you get an error that you have not selected any startup VI's.  Is this correct? Are there any details you would like to add to that?
    Also, can you please explain what you mean when you say the installer seems to be corrupted?  Can you give any error messages, or a better description of what is going on?
    Thanks,
    Kevin H
    National Instruments
    WSN/Wireless DAQ Product Support Engineer

  • Dynamically configure build specification version number

    I have several build specifications in the same project under the same version control and I base my version numbers in part on my revision number:
    <Major>.<Minor>.<Revision>
    Right now, I'm keeping the full number in a text file which is distributed with all build specifactions. However, I notice the build specification configuration diaglogue contains an option to execute a VI before the build. I'm wondering if a VI executed at this stage can somehow edit the version number within the build specification that called it, such that I don't have to manually change the version number in every build spec, every time I want to build one.
    Are there any canned functions that let you edit build specification things like version numbers?

    Hi Kgolden and A. Zaatari,
    Maybe it's not a current feature (I have to believe a NI Engineer ) but it's possible to do it.
    I made a VI that automatically creates Build and Installer specifications and also changes their configuration (like name, path, and version number).
    So, here is how:
    - all this information are stored in the project file My_Project.lvproj
    - My_Project.lvproj is actually a !!! XML file !!!
    - Make a small VI that search in the XML for the following lines/properties:
          (1) App_fileVersion.build
          (2) App_fileVersion.major
          (3) App_fileVersion.minor
          (4) App_fileVersion.patch
    For the App_fileVersion.build it should look like :<Property Name="App_fileVersion.build" Type="Int">115</Property>. Search for the pattern and change the value 115. Do the same for all four of them.
    Pay attention!! After you change this value you have to restart (close and than open) the Project in order to apply changes. This can also be done automatically by using LabView Application invoke and property node: Invoke Node: Project/Close + App/Open.LV Document/Path. Be carefull that you should do this from a VI that is not added to the project.
    Regards,
    Paul

  • How do I include a dll in a build specification and/or installer?

    I have a custom "wrapper" dll built with VC++ that I need to include in a LabVIEW Build Specification and/or LabVIEW Installer.  It needs to be installed in the C:\Windows\System32 folder.

    Good morning!
    You can set your support files to install
    in a separate directory than your executable. In the build
    specifications for your EXE, select the Destinations category and change
    the path for the Support Directory to C\WINDOWS\System32 as shown
    below.
    Then go the Source File Settings category and set your dll to install in the Support Directory, as shown below.
     Let me know if this works!
    Take care!
    Tanya V
    National Instruments
    LabVIEW Platform Product Support Engineer

  • Control User Specific button in ALV report

    Hi,
    Can anybody please suggest me how to control "USER SPECIFIC" button in ALV report layout using authorization object. I mean if you can tell me which authorization object is responsible to control the "USER SPECIFIC" button.

    additional info to what Lakshmi already said:-
    normally the restrictions for saving layouts/display variants are done at 2 levels:
    1) The developer of an ALV list first predetermines the authorization in the 'i_save' parameter within the code.
    I_SAVE = ' '     -
    layouts cannot be saved
    I_SAVE = 'A'   -
    user-specific and cross-user layouts can be saved
    I_SAVE = 'X'   --- cross-user layouts can be saved
    I_SAVE = 'U'  ---  user-specific layouts can be saved
    2) The second level comes to us restriciting the S_ALV_LAYO which gives access to users to save global layouts if I_SAVE for that particular transaction is A or X.
    for example, a report has I_SAVE= 'A', which means
    it will allow to save  User-specific  layouts without any restrictions.
    and if user has S_ALV_LAYO then he can save both User-Specific and Global Layouts(variants).
    it would be better to keep this object separate.

  • Problem with register event callback in use of instrument control

    now, i use the register event callback to register a value change of a boolean control on the front panel, and wire the cluster's ref of the instrument control parameters to the user parameter input, then create the callback vi. In the callback vi, i select the pump-control subvi, and pass the user parameter to the subvi. The problem is that,  when i press the boolean control, the instrument (here is pump) can act, but immediately, the code crashes.
    I use labview 8.6
    Attachments:
    callback vi.png ‏8 KB
    register event callback.png ‏8 KB

    You would wire the event registration wire that comes out of the Register for Events node into an event structure.  You will need to right click on the event structure and check off "Show Dynamic Event Terminals" and it into that.  Then you can create a new Event Case that uses the dynamic event.  You can place your subVI in that event in whatever way you want.  (Just drop the subVI in or do a Call by Reference there, or whatever.)  Look in the Example Finder for "Dynamically Register for Events.vi".

  • Configuration Management/Change Control/Build Management contract help needed in Missouri*** *** **

    Configuration Management/Change Control/Build Management
    Needs to have instituted a config management process before.
    web development history
    Tools/Skills:
    CVS
    ANT
    Unit Testing
    Unix
    BEA Weblogic
    John D Allen
    CEO/President.
    Leveridge Systems INC.
    v1 (480) 899 9341
    mailto:[email protected]
    http://www.leveridgesystems.com

    Could you post an example of your problem ?
    CC
    Chilly Charly    (aka CC)
             E-List Master - Kudos glutton - Press the yellow button on the left...        

  • 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

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

  • User-specified DAQ interruptions, instrument control through serial communication

    I'm working on an instrument control program, and I've run into a structural problem that I cannot figure out.
    The instrument in question is effectively a thermostat.
    The program has two functions:
    1.)  Background sampling to record temperature in a log over time.
    2.)  Adjust temperature according to user input
    The issue is that the instrument uses EIA-232 serial communication to talk to the PC.
    This prohibits simultaneous execution.  Attempting to send a command while the program is taking a sample will result in serial blockage errors.
    So the program must interrupt background sampling until the specified command has been completed.
    I can't figure out how to do this.
    My best idea was to create a manual pause control.  If the user wants to adjust the temperature, he hits a switch to pause the sampling, sends the appropriate command, then hits the switch again to reinitiate sampling.  This method will suffice, but is not ideal.
    Beyond that, I really have no idea how to prevent the two functions from running into each other.
    Help structuring this program would be greatly appreciated,
    Thank you

    Look into Semaphores (icons with traffic light glyphs)
    Set up a Semaphore resource to the COM port that is wired to two parallel structures.
    One structure would do the background polling, the other would handle setting changes.
    Prior to background poll, lock the resource, then unlock it after the poll. Likewise for the setting change command.
    When a resource is locked, the other process cannot access it until it is unlocked. Be sure to dispose of the Semaphore when ending the program.
    -AK2DM
    ~~~~~~~~~~~~~~~~~~~~~~~~~~
    "It’s the questions that drive us.”
    ~~~~~~~~~~~~~~~~~~~~~~~~~~
    Attachments:
    SempahoreExample.jpg ‏256 KB

  • Can I download the instrument Control and Data Aquisition Device Driver CD for 7.1?

    Greetings,
    Can I download the instrument Control and Data Aquisition Device Driver CD for 7.1?
    I'm trying to find out if I can download
    the instrument Control and Data Aquisition Device Driver CD for 7.1. Instead of downloading all the upgrades?
    Is there a link to the image file for this CD?
    TIA

    Sam,
    Unfortunately, the Device Driver CD is not available for download. However, your Technical Sales Representative should be able to send it to you (Contact Information).
    Spencer S.

  • RT Build Specifications: Component Definition Category is unresponsive

    Hi,
    I am using LabVIEW 2013 SP1 f2, with Real-Time 13.0.1
    When I open the Properties page for a Real-Time Application build specification (to run on a cRIO-9075), and select the Component Definition category, I find that the following occurs:
     - LabVIEW becomes unresponsive, and thinks for a while. It takes approximately 20-30 seconds or so to finally show the Component Defintion page.
     - When I click on Create a component definition file (.cdf), nothing happens. As I write this, I see "Required software components", and then these are greyed out: "Software component description", and "Software version" - but there is nothing to select or change?
     - If I click on another category, it takes in the order of 20 seconds to finally show this category.
     - To close the build spec (by pressing OK), it also takes a long time (more than 60 seconds). 
     - Things are fine with the build spec if I never enter the Component Definition category.
    Is anyone else experiencing this?
    Any help would be appreciated.
    Christopher Farmer
    Certified LabVIEW Architect
    Certified TestStand Developer
    http://wiredinsoftware.com.au
    Solved!
    Go to Solution.

    Hey Chris,
    I believe the following patch is the fix that you are looking for.
    LabVIEW Real-Time Module 2013 SP1 Application Builder Patch Details
    http://digital.ni.com/public.nsf/allkb/D72B45C6905D327A86257CC800547992?OpenDocument
    There's a link to download the patch at the bottom of that page.
    Regards,
    Ryan

Maybe you are looking for