Why is Building an exe in LabVIEW 8.6.1 so slow?

I have a fairly large application (about 2000 VIs) that I am trying to convert from LV7.1.1 to LV8.6.1 and it is a very challenging process!
I was able to load all of the VIs into LabVIEW 8.6.1 and correct all of the mislinked VIs (such as VI names that changed in the Report Generation toolkit and others), but when I try to create an exe it takes about 1 second per VI to build.  Why does it take so long?
Also, when the exe is finished compiling, on the 2 computers I've tried it on, the exe doesn't load (it gives a windows crash!).  I tried creating the exe in a "clean" virtual environment and that worked which means I probably have version conflicts with the other 2 "real" computers (I have 4 versions of LabVIEW installed on the real computers).  I've also tried loading it into LabVIEW 8.5.1 and the creation of the exe is a lot faster but the exe still does not work.
This is getting really confusing and frustrating!
Thanks,
Bruce

It takes about 10 minutes to compile in LV851 and about 20 minutes to compile in LV861f1.  Both take about 5 minutes when the progress bar gets to the last VI.
I was able to get my code to
compile to an exe that is executable by uninstalling IMAQ 4.1 (Vision
Acquisition Software 8.6) and installing IMAQ 3.8 (VAS 8.5). I avoid
IMAQ 4.0 because the structure of the .iid (for instance img0.iid)
files is messed up (see NI forum iid file structure in IMAQ 4.0 changed). This bug is fixed in IMAQ 4.1 but apparently there are other new bugs that were introduced.
I'll try my luck with IMAQ 4.2 when it comes out, but until then I have work to do.
Days
lost, totally frustrating. Not a good LabVIEW/NI experience. And I'm
stuck using old software versions to get things to work.
Bruce
P.S. I've been cross posting to lavag forums as well (exe built with LV crashes) about similar issues regarding my upgrading experience.
Bruce

Similar Messages

  • Building of exe crashing on "saving NI_MAPro.lvlib" what's wrong?

    The majority of times I try to build an exe in labview 8.6, the compiler freezes on "saving NI_MAPro.lvlib". I have to restart labview and try again till it works. (and separately) On top of that if labview 8.6 crashes and I recover the file from the automatic file recovery function, labview again crashes when I try to save that file. So the file never can be recovered.
    Aaron

    Hi Michael,
          Thank you for the reply.  I'm using LV 8.5.1, but, at the moment, can't reproduce the problem when I develop a simple example project which builds an EXE that calls a plug-in.
    So it seems to be a lvlib-related problem on my development station.  I'll recompile the example there (later) and post the project if the problem recurs.
    Thanks/Cheers!
    "Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)

  • "applicati​on error" in LV8 when building an .exe .

    Hi All
    I am trying to build an .exe using LabView 8. I can generate a preview, fine, I can see all my files and where they will be, however
     I click the build button to star building the application and the application starts build fine. I get messages like:
    First "Initializing build"
    Then "Preparing File", "Loading items to build", "updating libraries" and "Processing .............vi"
    Suddenly just crash with the following error message pop up window:
    "dwwin.exe - Application Error
    The application failed to initialize properly(0X=0000142). Click on "OK" to terminate the application"
    Does anyone knows what 's wrong??
    Thank You Very Much in advanse

    Togos,
    Well at least you got it to build once.  So even with the exact same settings you were unable to rebuild the EXE?  That is certainly odd.  Since you are able to build the example, we know that it is probably the VI that is being built that is causing the problem.  I have a couple of suggestions for you at this point.  The first is to try to create a new Build Specification and just use the default options to try to get the EXE to compile.  Since you probably have already tried this, there is a more involved suggestion.  This sounds like a very large VI, so I might suggest trying to whittle down the problem by deleting code and attempting to rebuild the EXE.  Once you have deleted enough code, you will probably get down to a point where the VI will compile (hopefully before you reach an empty block diagram).  At this point we can test to see if the recently deleted past of the VI will compile by itself to see if it is a specific code snippet that is causing this problem.  As mentioned this is a lengthy and involved process, so before I tried this I might treat this as a VI corruption error, and try to copy and paste the Block Diagram from the problematic VI to a blank one to see if that makes any difference. 
    Let me know if any of that helps or if you have any other questions!
    Andy F.
    National Instruments

  • LabView 2010 Applicatio​n Builder for EXE Always Included files are not Included

    In LabVIEW 2010 F2, When I am using the Application Builder to build an EXE file, I have listed 10 or so files to Be "Always Included". But when I Explore the directory where the EXE was built, those "Always Included" files are not there or in any subdirectory under the EXE file.
    This frequently makes my EXE file not work properly because important files are missing. I have to spend extra debugging time to find out the the cause of my problem is missing files that the Application Builder should have transferred "Always".
    Why did the Application Builder, when building an EXE target, not include the files that should be "Always Included"?
    Why does the Application Builder ignore these files specifications?

    Dennis Knutson wrote:
    The build does include files you select. Post an example project with a small VI and some separate files where this does not happen.
    No, it does not appear that all of the files that I listed in the "Always Include" list are copied during the Build process to the Build directory or any subdirectory under that.
    The Build Source Files.jpg file shows most of the list of the files that should be "Always Included". Notice the .VI and .ctl files that are listed
    The Build Directory.jpg file shows the file in the Build directory that were built.
    The Data Directory.jpg file shows the data directory under the Build directory and may include some of the files listed in the "Always Include", but not all of them.
    The other subdirectories under the Build directory were created by me and do not include any files that were copied during the Build process.
    So not ALL of the files that were included in the "Always Include" list were copied into the Build directory area as expected. ALL of the files that are listed as "Always Include" should be copied, if they exist. Those files existed when then were selected for the List and they existed at the time of the Build.
    I can not include an example project that demonstrates this. I am prevented from doing so by the terms of an NDA. You are going to have to take my word that this event is real and happens the same way every time. This information should be sufficient for someone to investigate why do not ALL of the files listed in the "Always Include" list are copied into the Build directory area regardless of the file type or contents.
    Attachments:
    Build Source Files.jpg ‏151 KB
    Build Directory.jpg ‏125 KB
    Data Directory.jpg ‏131 KB

  • LabVIEW is crashing when i am trying to build the exe

    I am trying to build an executable from a program in which i am communicating with several instruments, whenever i am trying to build an exe labview is crashing and i am getting the error Exception: access violation(0xc0000005)at eip=0x10054DD1.
    after reading some posts on forum i tried builduing an exe on other system also, but still i am getting the same error.
    below i am attaching the program and the image of the error i am getting.
    Attachments:
    labview crash.png ‏53 KB
    automation.zip ‏4455 KB

    Ritu wrote:
    waiting for the reply....
    Realize this community is by a large majority volunteer based.  If you need urgent support contact NI directly 
    http://sine.ni.com/apps/utf8/nicc.call_me?loc=en-US
    That being said I would try to disable the large amount of code.  Say you have a Main that launches a bunch of stuff, put a disabled diagram code around the launching part and then try to rebuild.  It is a very slow process (especially when the build takes a while to fail) but by doing this you can more isolate the parts of the code that can cause the crash.  The only time I've seen a crash on build like you described, I simply rebooted and it was fine.  Usually because of my own fault by stopping code in a bad way previously leaving things in memory.
    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.

  • Labview crashing when building application (exe)

    Hi,
    I am trying to build an application from a simple labview (2011) vi. All the vi does is sets (boolean = TRUE) a line on the digital output card (NI 9472) when I start running the vi. The program works fine after I have coded it. But when I try to build an exe file (application) of that project, then labview crashes in the build process. Is this a known issue? please help. I am attaching my vi alongwith this email
    Thanks
    Solved!
    Go to Solution.
    Attachments:
    relayProject.lvproj ‏34 KB
    relay.vi ‏21 KB

    I'm sorry to hear that gascars.  I have downloaded your project and VI and have succesfully built an executable in both LabVIEW 2011 and LabVIEW 2012.  Can you please send me a screenshot of the error you are receiving?  Also, can you make a simple VI that just adds two numbers and see if that can be made into an .exe.  
    Thanks
    Chris
    Chris
    National Instruments
    Applications Engineer

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

  • How to build an .exe for cFieldPoint on a PC ?

    Hi all,
    A couple of weeks ago I installed a system with a compact FieldPoint running a in RT mode (cFP 2020 and LV 7.1.1).
    To load the .exe on the cFP, I connected my PC to the cFP (ethernet), selected the cFP as execution target for LabVIEW and then opened the application builder. I assume this is the normal way to do... but is this the only way ?
    In fact, my customer is asking for some more features, so my question is quite simple :
    Can I build an .exe for the cFP on my PC (without connecting to the cFP target), mail it to the customer and tell him to replace the .exe file on the module ?
    Thanks for any help
    When my feet touch the ground each morning the devil thinks "bloody hell... He's up again!"

    Hi Kahlid ,
    I noticed you were reply someone on pretty much close to same problem whatever i am having , I am working on LabVIEW8.2 with cFP. I created a project with an executable (run from My Computer),  the other executable is running in the field point , I used shared variable to transfer data from field point to host program. Now I want to Uninstall LabVIEW from the same computer but want to keep MAX  and one .exe file to run host VI. How to do that , any  suggestion about copying or moving only .exe file ? or lets say if I want to run the same program in another new PC with same Field Point hardware and program how to copy/install executable in the new PC?
    Thanks and best regards,
    Faiyaz Syed

  • Problems in using Application Builder to Build a exe file with Report generation Toolkit

    Hello,
    It's my first time to build exe. But I have Problem  when the VI have Report Generation toolkit VI.
    It's no problem in VI Format , But It can't work when I build as EXE format
    Can Anyone help me, and state step clearly in how to  solve the problems?
    Thank you!!

    If the code works OK in the development system but not in an executable there are a few things you can check. The two most likely causes are:
    There is an error occuring that your code isn't reporting.
    There is a file path that under the executable isn't valid.
    First make sure that all the error clusters are daisy-chained together in the subVI that you wrote to create and populate the excel file. Next make sure that the end of that chain goes to an indicator on the VI's front panel.
    Second, make sure there are indicators on other key parameters like the path the file is trying to write to.
    Third, temporarily modify the VI properties of that excel IO VI to open it's front panel when called, and rebuild your application. The next time you run the application the front panel will open when you try to write to the excel file and you should be able to see what is happening.
    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

  • Problema al crear .exe en labview 10

    Mi inconveniente surge apenas pongo en la opción tools Build Application (EXE) from vi me tira el siguiente error:
    Error 7 occurred at Open VI Reference in AB_UI_Load_Page.vi->AB_UI_FRAMEWORK.vi->AB_Create_Build_Application.vi->EBUIP_Global_OnCommand.vi->EBUIP_Global_OnCommand.vi.ProxyCaller
    el VI que estoy probando hacer ejecutable es un programa simple de suma de dos números con el fin de lograr hacer el ejecutable solamente.
    Agradecería sus respuestas.

    Hola ignazoni
    Me gustaría confirmar con usted,
    - ¿Que paquete de LabVIEW tiene ? Si es LabVIEW Base, Full, Professional.
    - ¿Intentó crear el ejecutable desde el Build Specifications ? Anexo los pasos para hacer esto:
    http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/building_a_stand_alone_app/
     Este problema esta relacionado con encontrar algún archivo que requiere la compilación. Al hacerlo desde el Build Specifications, cuando guarde su compilación y asigne el nombre del executable, procure no utilizar el mismo nombre en la compilación y el ejecutable, y procure no utilizar espacios en el nombre de los mismos. 
    Espero su respuesta. 
    Omar R.
    Applications Engineer

  • Problem with building a dll in labview

    Hello,
    I want to be able to run a LabView vi from Java and found that the best way to do this is to create a DLL in LabView and then call it in Java using JNI. I did a dummy program in LabView to test, but the problem is that the instructions I found don't seem to exist! For example, one tutorial I was following said to: "Open a new VI and select Tools»Build Application or Shared Library (DLL).". But I don't have that under tools, just Build Application (EXE) from vi, which gives a project file. In another place it said to "Expand My Computer. Right-click Build Specifications and select New»Shared Library from the shortcut menu to display the Shared Library Properties dialog box" but I have no idea what that means.
    I have the LabView 2009 trial version, could that possibly be making a difference? If not, what am I doing wrong? Or is there a better way to run a LabView program from Java?
    Thanks a lot!
    Hugh

    Actually, the second one is from LabView help. I tried looking up Application Builder like you said but again it begins with the instructions "Expand My Computer. Right-click Build Specifications and select New»Application from the shortcut menu to display the Application Properties dialog box" and I have no idea what this means What do they mean by My Computer? And Build Specifications? I don't have any of that... I'm sorry but I'm new to all of this, I've never worked with DLLs before in any language, and all I want to do is run my LabView program when I press a button on my Java interface!! If there is a better way to do it, that would be great!
    Thanks at any rate,
    Hugh

  • Why I build program display a loading dialog?

    Hello,
    I build a exe program use labview，the program include a lot of vi, the build is successful,and the exe program run is ok,but when the program is loading display a load dialog,how can I setting would not display the dialog?
    附件:
    未标题-1.jpg ‏117 KB

    Look at attached picture, it should get you started.
    /Y
    LabVIEW 8.2 - 2014
    "Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
    G# - Free award winning reference based OOP for LV
    Attachments:
    Splash.png ‏20 KB

  • How to remove the "int len" of my return string on the DLLS header when building a DLL on LabVIEW 8.5

    Hi all.
    I'm building a DLL on LabVIEW and I choose a string as an output on the terminals connectors.
    But LabVIEW creates another output, the lenght of the return string.
    This is a problem because I have other DLLs and I need them to be compatible.
    How do I remove this length from the header? What is the difference between Pascal String and C string and String Handle Pointer?
    String Handle Pointer removes the length from the header but I don't know the difference between this data types.
    Thanks in advance for the help.
    Daniel Coelho
    Portugal
    Daniel Coelho
    VISToolkit - http://www.vistoolkit.com - Your Real Virtual Instrument Solution
    Controlar - Electronica Industrial e Sistemas, Lda

    Daniel Coelho wrote:
    Hi all.
    I'm building a DLL on LabVIEW and I choose a string as an output on the terminals connectors.
    But LabVIEW creates another output, the lenght of the return string.
    This is a problem because I have other DLLs and I need them to be compatible.
    How do I remove this length from the header? What is the difference between Pascal String and C string and String Handle Pointer?
    String Handle Pointer removes the length from the header but I don't know the difference between this data types.
    Thanks in advance for the help.
    Daniel Coelho
    Portugal
    C string pointer is a pointer to a memory location whose string information is terminated by a 0 byte. Pascal String Pointer is a pointer to a memory location where the first byte specifies the number of bytes to follow. This obviously allows only for strings up to 255 character length.
    LabVIEW String Handle is a pointer to a pointer to a memory location where the first 4 bytes are an int32 value indicating the number of characters to follow. You can read such a String handle in a function without many problems, but you can only create, resize and delete such a handle by using LabVIEW memory manager functions. So this makes only sense if the caller of such a DLL is LabVIEW too as another caller would have to go through several hoops and tricks in order to gain access to the correct LabVIEW kernel that could provide the memory manager functions to deal with such handles.
    Last but not least output strings whose allocated length is not passed to the funciton as additional parameter are a huge secerity risk (talk about buffer overrun errors). LabVIEW DLL Builder does not support the creation of DLLs with output string (or array parameters)  without the explicit passing of an additional parameter telling the DLL function how large the allocated size is (so that the DLL function can make sure to never write over the end of the buffer).
    The additional length parameter only disappears for String Handles because LabVIEW will simply resize them to whatever length is necessary and that is also the reason why those handles need to be allocated by the same memory manager instance that is also going to execute the DLL function.
    Resizing of memory pointers is non-standardized and in normal circumstances not suited for passed function parameters at all.
    Rolf Kalbermatter
    Message Edited by rolfk on 06-13-2008 12:28 PM
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Building multiple EXE's with common code

    I’m trying to determine the best way to use Application Builder to deploy a fairly large LabVIEW project to computers which do not have a LabVIEW development system installed.  This project consists of:
    Multiple top-level VI’s, each of which should be compiled to a separate executables.
    Multiple plug-in classes which are dynamically loaded by the top-level VI’s.
    Common modules (LabVIEW classes, project libraries, and individual VI’s) shared by both the top-level VI’s and the plug-in classes.
    Everything works well under the development system, and also when I use a single build specification to both build the EXE for one top-level VI and to place the plug-in classes in the correct folder relative to the EXE.  However, this seems wasteful, as it makes a full copy of all of the plug-in classes, and their dependencies for each top level EXE.
    If I try to build the EXE with one build specification, and a source distribution for the plug-in classes with another build specification, error 1448 occurs when I load some of the plug-in classes using “Get LV Class Default Value.vi”.  I suspect that this is due to having the same common VI expected at two different paths (i.e. one embedded in the EXE and a second copy in the folder where the plug-in class is located).
    Is there any way to use multiple build specifications to build several EXE’s and a “library” of common code in such a way that everything links properly?
    Mark Moss
    Electrical Validation Engineer
    GHSP

    It is possible, but I will save you the trouble - if it works as a monolithic executable, leave it at that. It may be wasteful, but computers are powerful, memory is cheap and headaches resulting from trying to manage dependencies aren't.
    If you want, you can find some plugin schemes in the large apps group over at the communities area of this site, but you're probably better off not going into it if you don't actually need the functionality.
    Try to take over the world!

  • Report Generation - Build an exe from a PC with different Office Version

    Hi,
     I want to build an exe from a VI that uses Report Generation Toolkit. The application has to be deployed on several PCs that use Office 2000. During development phase I installed on my PC, Office 2000 and everything was ok. After I was done with it, I reinstalled Office 2007. So, the Report Generation Toolkit from my PC is for Office 2000 (it was installed when I had Office 2000 on my PC).
     These days I had to fix some bugs from my application, I made a new exe but the part that generates Word reports (using RGT) is not working anymore - I received that error with -35...9935 (or something like this).
     I tried to search for the problem and I found it: with exactly the same VI's (_Word Dynamic VIs.vi - for Office 2000) the invoke nodes from a PC with Office 2007 and a PC Office 2000 look different. For example in Word_Open_Document.vi, the invoke node Document is different for a PC with Office 2000 + RGT for 2000 and a PC with Office 2007 + RGT for Office 2000 (no mistake).
     So, I've tried to copy the VI's from a PC with Office 2000 + RGT 2000 to my PC but I cannot build it because I get the error: There are some errors in _Word Dynamic VIs.vi (the invoke nodes do not fit).
    Finally my question is: How can I build the exe on my PC: Office 2007 but with RGT for Office 2000??
    Thanks,
    Paul
    Solved!
    Go to Solution.

    Hi,
    Thank you for your advice. Can you please tell me what you want to say with the wrapper vi? I don't really understand what you mean.
    By the way, I solved the problem. I discovered that the Invoke Nodes are updated based on the Object Library for the ActiveX control (in this case the MS Office). The data types are store in the msword9.olb (version 9 - for office 2000 in Office folder) and msword.olb (version 12 - for office 2007 also in Office folder). I tried to register the msword9.olb (using the regsvr32.exe) but it doesn't work for olb files - I need the ocx or dll. But, if I replace the msword.olb from Office 2007 with msword9.olb from Office 2000 everything work.
    Ok, steps that have to be done:
    1. Install the RGT for Office 2000 on the PC
    2. DO NOT Change anything in _Word_Dynamic VIs.vi. When Office 2007 is installed the VI arrow should be broken (error in VI)
    3. Copy the msword9.olb from a system with Office 2000 (or your version) and copy it to your system with Office 2007 with the new name msword.olb. DO NOT FORGET to make a backup of the original MS Office 2007 file and to restore it at the end.
    4. After the new msword.olb is there, the _Word_Dynamic VIs.vi should have no error
    5. Build your exe application
    6. Restore the old msword.olb
    7. ENJOY your life !
    I hope this is useful also for somebody else.
    Paulie

Maybe you are looking for