Error 1003 when building executable

Hi, I'm using Labview 2010 on Windows 7 and I'm getting an error when I try to build an executable:
Error 1003 occurred at Open VI Reference in AB_Engine_EXE_Call_Write_Icons.vi->AB_EXE.lvclass:​Build.vi->AB_Build.lvclass:Build_from_Wizard.vi->A​B_UI_Frmwk_Build.lvclass:Build.vi->AB_UI_FRAMEWORK​.vi->AB_Create_Build_Application.vi->EBUIP_Global_​OnCommand.vi->EBUIP_Global_OnCommand.vi.ProxyCalle​r
Possible reason(s):
LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.
VI Path: C:\Program Files\National Instruments\LabVIEW 2010\vi.lib\Platform\icon.llb\Read Icons from ICO File.vi
This happens even when I try to build a simple vi, like a random number generator.

Same problem here. Error 1003 and error 8 I encoutered often.
For error 8 during build process, I needed to save the executable on a higher level in the file hierarchy.
For error 1003, I did not find a solution. Restarting LabView does not help. Sometimes (but not always) restarting the computer helps. Sometimes I need to reinstall the labview system.
More details: I have a first vi, starting the actual vi with a hidden front panel (second vi). This vi can also be started directly. Sometimes, the build process runs smoothly then  when I include the second vi as main vi to start the program.
The program runs fine when the build process succeeds, and it runs fine in LabView.

Similar Messages

  • Error 1003 when building exe

    Hi all,
    I saw a couple of thread of other people here having the same "1003 error" when trying to build an exe with LV 7.1.1
    The exact text error is :
    Error
    1003 occurred at Open VI Reference in Dist Copy Non-VI
    Files.vi->Dist Build LLB Image.vi->Dist Build App
    Image.vi->Build Application.viPossible reason(s):LabVIEW: The VI is not executable.
    This is all the more surprising because this error will only happen on my computer !!!
    I borrowed a collegue's computer and the build went OK...
    After further investigations I noticed only one difference between my collegue's computer and mine : mine has VIPM installed.
    Could VIPM possibly be the source of this issue ??
    PS : recompling the code (ctrl+shift+run) on my CPU didn't make any change.
    When my feet touch the ground each morning the devil thinks "bloody hell... He's up again!"

    Hi TiTou,
          You've probably solved this by now, but if not...
    A few months ago I was trying to distribute two EXEs - both of which made dynamic calls - and this error (among others) was giving me "fits".  I think it can happen if the caller has loaded a VI (.ctl or .vi) that also appears in the callee hierarchy - and the version loaded by the caller is incompatable with the callee's diagram(s.)  When the callee runs, it has to use same-named VIs already in memory.  If you see different behaviour on two different machines, are there two different versions of the caller?
    No matter what the problem really is (was,)  the attached VI will try to open all the broken VIs in a hierarchy - which can be a huge help in narrowing the problem.  Oh yeah, with the (broken) FP open, click on the broken-arrow to see an error-list that can (but-usually-doesn't) display helpful diagnostic info!  Compile this into your EXE (caller) so it runs if there's a problem running the callee.
    Cheers.
    Message Edited by tbd on 01-15-2007 10:58 PM
    Message Edited by tbd on 01-15-2007 11:00 PM
    "Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
    Attachments:
    Util.VI.OpenBroken.vi ‏62 KB

  • Name collision error occurs when building executable

    hi
    I was attempting to build an executable of my project including .m file with mathscript of course  , but a warning showed up while building and here is what it was showing:
    A name collision occurred during the build.  VIs were renamed to protect the build.  If any dynamic calls were made to the following VI(s), unexpected behavior may occur:
    C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Analysis\Matrix\Support\ComplexMatrix\ComplexMatrix.ctl
    A name collision occurred during the build.  VIs were renamed to protect the build.  If any dynamic calls were made to the following VI(s), unexpected behavior may occur:
    C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Analysis\Matrix\Support\RealMatrix\RealMatrix.ctl
    A name collision occurred during the build.  VIs were renamed to protect the build.  If any dynamic calls were made to the following VI(s), unexpected behavior may occur:
    C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Analysis\Matrix\Support\RealMatrix\Methods\Numeric.llb\Multiply - RM,RM.vi
    A name collision occurred during the build.  VIs were renamed to protect the build.  If any dynamic calls were made to the following VI(s), unexpected behavior may occur:
    C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Analysis\Matrix\Support\RealMatrix\Methods\Numeric.llb\Multiply - RM,R.vi
    A name collision occurred during the build.  VIs were renamed to protect the build.  If any dynamic calls were made to the following VI(s), unexpected behavior may occur:
    C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Analysis\Matrix\Support\ComplexMatrix\Methods\Numeric.llb\Multiply - CM,CM.vi
    A name collision occurred during the build.  VIs were renamed to protect the build.  If any dynamic calls were made to the following VI(s), unexpected behavior may occur:
    C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Analysis\Matrix\Support\ComplexMatrix\Methods\Numeric.llb\Multiply - CM,C.vi
    A name collision occurred during the build.  VIs were renamed to protect the build.  If any dynamic calls were made to the following VI(s), unexpected behavior may occur:
    C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Analysis\Matrix\Support\RealMatrix\Methods\Numeric.llb\Add - RM,RM.vi
    A name collision occurred during the build.  VIs were renamed to protect the build.  If any dynamic calls were made to the following VI(s), unexpected behavior may occur:
    C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Analysis\Matrix\Support\RealMatrix\Methods\Numeric.llb\Subtract - RM,RM.vi
    A name collision occurred during the build.  VIs were renamed to protect the build.  If any dynamic calls were made to the following VI(s), unexpected behavior may occur:
    C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Analysis\Matrix\Support\RealMatrix\Methods\Comparison.llb\Equal - RM,RM.vi
    A name collision occurred during the build.  VIs were renamed to protect the build.  If any dynamic calls were made to the following VI(s), unexpected behavior may occur:
    C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Analysis\Matrix\Support\ComplexMatrix\Methods\Numeric.llb\Add - CM,CM.vi
    A name collision occurred during the build.  VIs were renamed to protect the build.  If any dynamic calls were made to the following VI(s), unexpected behavior may occur:
    C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Analysis\Matrix\Support\ComplexMatrix\Methods\Numeric.llb\Subtract - CM,CM.vi
    what is this all about and how can i avoid this , i tried to pass it away but the .exe seems to be not running like it should be ( i have to get a treated wavfile as an output)
    Please help me to resolve this .
    thanks.
    Attachments:
    Documents.zip ‏196 KB

    Duplicate
    You might want to check this link and check if you have conflicts and solve them
    Hope it helps.
    Regards.
    Mathieu Steiner, Test System Engineer, Safran Engineering
    CLD, ISTQB

  • LC  2 Error 1003 when executing external command brconnect on (xpgid=0,con

    Dear all,
    I am getting error in sm21.Please suggest .
    Details Page 2 Line 23 System Log: Local Analysis of clusa                    1
    Time     Type Nr  Clt User TCode Grp N Text
    10:00:32 DIA  000 600 DDIC       LC  2 Error 1003 when executing external command brconnect on (xpgid=0,convid=.)
    Error 1003 when executing external command brconnect on (xpgid=0,convid=.)
    Details
    Recording at local and central time........................ 10.05.2010 10:00:32
    Task...... Process                     User...... Terminal Session TCode Program  Cl Problem cl      Package
    06952      Dialog work process No. 000 DDIC                      1       SAPMSSY1 S  Operation Trace SBTC
    No documentation for syslog message LC 2 exists
    Parameter
      1 .... xpgid=0,convid=.
    Technical details
    File Offset RecFm System log Grp N variable message data
      224 260640                  LC  2 brconnect & &Error 1003 & & &
    Regards,
    Kumar

    Dear Juan,
    Please find the logs.Please suggest.
    dev_cp log
    Trace file of control program (trace level 3)
    < Function: BtcTrcInit> Function: main  SAPXPG 720
    2010-05-10--09-33-29 : Before BtcXpgDetach
      > Function: BtcXpgDetach  < Function: BtcXpgDetach  Accept RFC connection from R/3 system
    2010-05-10--09-33-29 : Before RfcAccept
    2010-05-10--09-33-29 : RfcAccept returned OK
    Begin of check_if_security_list
    security check switched OFF
    End of check_if_security_list
    Begin of check_trace_option
    End of check_trace_option
      Install RFC call SAPXPG_START_XPG
      Install RFC call SAPXPG_START_XPG_LONG
      Install RFC call SAPXPG_END_XPG
      Wait for RFC call SAPXPG_START_XPG or SAPXPG_START_XPG_LONG
    2010-05-10--09-33-29 : Before first call of RFCDispatch
    Security: rfcexec_logon_check
      rfcexec_logon_check: logon_user =
      sapxpg_logon_check: rfc_attr.user = BASIS      
      rfcexec_logon_check: client =   
      > Function: BtcXpgStartXpgLong   
    2010-05-10--09-33-29 : Beginning of BtcXpgStartXpgLong
        > Function: BtcXpgStartXpgImportLong      > Function: BtcXpgParam      < Function: BtcXpgParam      > Function: BtcXpgParam      < Function: BtcXpgParam      > Function: BtcXpgParam      < Function: BtcXpgParam      > Function: BtcXpgParam      < Function: BtcXpgParam      > Function: BtcXpgParam      < Function: BtcXpgParam      > Function: BtcXpgParam      < Function: BtcXpgParam      > Function: BtcXpgParam      < Function: BtcXpgParam      > Function: BtcXpgParam      < Function: BtcXpgParam      > Function: BtcXpgTable      < Function: BtcXpgTable    < Function: BtcXpgStartXpgImportLong   
    BtcXpgStartXpgLong: special_trace_flag = <6>
        > Function: BtcXpgStartXpgInt      > Function: BtcXpgItTransfer        Content of source log table:
              Line  Text
              <No StdOut/StdErr output reported>
            Target log table is not identical to source
            ItGetLine terminated with NULL
          < Function: BtcXpgItTransfer      > Function: BtcTrcReset      < Function: BtcTrcReset      Call mode: VIA RFC
          Input arguments of BtcXpgStartXpg:
            External program: brtools
          tracecntl = : 6
          Display of Parameter string switched off !!
            Contents of control flags:
              StdIn control flag: redirect StdIn
              StdOut control flag: store StdOut output in memory
              StdErr control flag: store StdErr output in memory
              Trace control flag: unknown contents
              Termination control flag: control program will wait for termination
          > Function: BtcXpgCheck        > Function: BtcXpgArgv
              parameter number 1:
              parameter number 2:
              parameter number 3:
              parameter number 4:
              parameter number 5:
              parameter number 6:
              parameter number 7:
              Total number of arguments scanned: 7
              Argument argv[0]: brtools
            < Function: BtcXpgArgv      < Function: BtcXpgCheck      > Function: BtcXpgSigInst      < Function: BtcXpgSigInst      > Function: BtcXpgStart        Rearrange stderr to be collected in memory
            Rearrange stdout to be collected in memory
            Redirect stdin, read from NUL:
            > Function: BtcTrcInit< Function: BtcXpgStartStart status of external program: external program successfully started
    Id of external process: 0000005296
    StdOut/StdErr collected in memory
      Line  Text
      <No StdOut/StdErr output reported>
    < Function: BtcXpgStartXpgInt> Function: BtcXpgStartXpgExport  > Function: BtcXpgParam  < Function: BtcXpgParam  > Function: BtcXpgParam  < Function: BtcXpgParam  > Function: BtcXpgParam  < Function: BtcXpgParam< Function: BtcXpgStartXpgExport
    2010-05-10--09-33-29 : End of BtcXpgStartXpgLong
    < Function: BtcXpgStartXpgLong
    2010-05-10--09-33-29 : After first call of RFCDispatch
    Wait for RFC call SAPXPG_END_XPG
    2010-05-10--09-33-29 : Before second call of RFCDispatch
    Security: rfcexec_logon_check
    rfcexec_logon_check: logon_user =
    sapxpg_logon_check: rfc_attr.user = BASIS      
    rfcexec_logon_check: client =
    > Function: BtcXpgEndXpg 
    2010-05-10--09-33-29 : Beginning of BtcXpgEndXpg
      > Function: BtcXpgStartXpgExport    > Function: BtcXpgTable    < Function: BtcXpgTable  < Function: BtcXpgEndXpgImport  > Function: BtcXpgEndXpgInt    > Function: BtcXpgItTransfer      Content of source log table:
            Line  Text
            <No StdOut/StdErr output reported>
          Target log table is not identical to source
          ItGetLine terminated with NULL
        < Function: BtcXpgItTransfer    > Function: BtcXpgReadChild      Output of external command not written to log !!
          Process executing external program has terminated
        < Function: BtcXpgReadChild    > Function: BtcXpgEnd    < Function: BtcXpgEnd    Termination status of external program: no errors reported
        StdOut/StdErr collected in memory
      < Function: BtcXpgEndXpgInt  > Function: BtcXpgEndXpgExport    > Function: BtcXpgParam    < Function: BtcXpgParam    > Function: BtcXpgParam    < Function: BtcXpgParam  < Function: BtcXpgEndXpgExport 
    2010-05-10--09-33-30 : End of BtcXpgEndXpg
    < Function: BtcXpgEndXpg
    2010-05-10--09-33-30 : After second call of RFCDispatch
    2010-05-10--09-33-30 : After call of RfcClose (wait)
    < Function: main
    2010-05-10--09-33-30 : End of SAPXPG: main
    dev_xpg
    Trace file of External Program (trace level 3)
    < Function: BtcTrcInit> Function: BtcXpgStart  External program: brtools -sid prd -F printout alert_log 20100401000000 0128
    Regards,
    Kumar

  • Error 1003 when running .exe

    I am having a problem with error 1003 when I run a built application.  I have searched the forums and found many others with this problem, but they encounter the problem while building the application, not while running the built .exe.
    I have a top level VI (AutoRun.vi) that calls 3 VIs in sequence.  All three are called in the same manner.  The first two work fine, but I get this error with the third sub vi.  This is how I call the subvi:
    Use App.kind, check for "Run Time System" (strip app path twice), or "Development System" (strip app path once)
    Build path to combine stripped path and file name of subvi to open
    open vi reference
    Invokee Node - Open FP
             Activated - T
             State - Standard
    Invoke Node - Run VI
              Wait until done - T
              Dispose ReF - F
    Invoke Node - Close FP
    Close VI Reference
    The error I get is:
    Error 1003 occurred at Invoke Node in AutoRun.vi
    Possible reasons:
    LabView: the VI is not executable
    I do not get this error while running in the development environment.  Only when I run it as a .exe.  Also I have had no problems with this code in the past.  I just made a small change and now I have this problem.  I have gone back to the old code and have the problem with it too. 
    I build the app by starting the app builder, selecting the top level VI, adding dynamic VIs and select all 3 subvis.  The front panel of the second VI is not visible while running.  I have to go in and manualy change the "Remove Panel" in the build settings for this VI from the default yes to no.  If I do not do this I get an error while trying to run the built application.  I have no idea why this happens either, but making this change fixes the problem.  After this I select build.
    BTW, I have LabView 7.0

    Hello,
    Not sure what happened on your end, but if the problem comes back repost and we'll explore it!
    Best Regards,
    JLS
    Best,
    JLS
    Sixclear

  • Error 1003 when loading a VI dynamically on LabView Run-time ini file configuration

    hi all,
    I have a problem with my runtime excutable.
    On 4 systems, all running XP it runs fine.
    On 2 systems ( one a new install of just LVRT 2011 SP1 ) I have:
    Error 1003 when loading a VI dynamically on LabView Real-time
    Or more spoecifically the error code is 1003 and the error source is Open VI Reference.
    When the RT app runs correctly I get these paths:
    Path Sent to Open Vi Reference:              Yeast_Grower.exe\Tecan_talk_Control.vi, 
    Path Returned from Open Vi Refence:       C:\Program Files\Yeast_Grower\Yeast_Grower.exe\Tecan_talk_Control.vi, 
    On a system that does gets the 1003 Open Vi Refence error I have the same Path Sent but of course no path returned as it does not open.
    To be sure that the vi Dyanmically called vi is compiled and valid at runtime I also include a copy of in the main.vi.
    To be extra sure I have also installed the runtime versions of VISA and DAQmx.
    I have compiled it with and without the "Use LV 8 calling hiaracy"
    My conclusion as this stage is that either the installation of LVRT 2011SP1 misses something the earlier LVRT installtions make.
    or is there a MyApp.ini or LVRT .ini  that controls how the RT dyanim calls are handled.
    Help very welcome how to solve this puzzle.
    thanks
    michael

    I understand that all the PCs (6 of them) have LV 2011 SP1, runtime or the development system installed. Right?
    How many of these PCs have the source code available on them?
    -> Only one of them has the source code.
    I am not sure I understood 'I also include a copy of in the main.vi'. Does it mean you placed the subvi in the main.vi?
    -> I meant I have included in main.vi the actual vi that is called dynamically - but only where it is not called.
    Did you try including the sub vi which is called dynamically, as 'Always included' in the EXE build?
    -> No, I did not know of this option - but the above I did this by default.
    Edit: Did you verify the software versions of LV RT, VISA etc on all the PCs? Are they same?
    -> I did verify even added DAQmx just in case
    There is lots of material available on this forum for error 1003 and dynamic vi calling. Did you find anything useful to try among the forums threads?
    -> I did view many of them.
    I did finally find the answer.  
    I have a subvi (callNet.vi ) in the dynamically called vi (dynamic ) that calls .Net libraries.
    Now the thing is that this subvi callNet.vi is coded out by enclosing it in a Disable structure.
    In fact this subvi ( callNet.vi) does not even compile - ie it has a broken arrow
    however if enclosed in a Disabled structure and disabled, the enclosing vi compiles OK.
    However I have discovered that even with the .Net calling subvi (callNet.vi) in the Disabled state of the Disabled structure
    the enclosing vi (dynamic.vi ) does NOT run - although it compiles just fine.
    Once I installed the .Net libraries (I actually did include them with my app installer ) with the vender's supplied installer
    then my app now successfully calls the dynamic vi.
    So the Summary and warning is:  Even if the dynamic called vi is included in Main.vi and Main.exe runs ( but does not call the dynamic vi - except when called dynamically at later some point ) and even if, in this case, the .Net calling subvi is disabled out ie no .Net calls are made the dynamically called vi will not run when called dynamically.
    I hope that is not too confusing.  In summary it seems the Disable structure does not entirely disable.
    Michael

  • Language Problem when building executable

    I'm having a weird issue when building executables.  Labview seems to forget the english language.  I have tried selecting English exclusively as the run time language but when i do that i get a "No supported languages installed!" error. Everthing works fine in the development environment.  It only seems to apply to application menus and not custom user menus.  Thanks for any insight.  
    Solved!
    Go to Solution.
    Attachments:
    Language.png ‏3 KB

    Hello Jed394,
    I took a look into the issue, just to be sure the error thrown was “No support Language Installed,” correct?  Check to see if the language of your operating system and the language LabVIEW is using is English.  If these are both English, then it looks like this is an error due to installation issues in the run-time engine.  Try to perform a repair by going through the install menu of LabVIEW.  The following link will help you with the repair: http://digital.ni.com/public.nsf/allkb/FE6B641E86E55AF2862576DE00038001?OpenDocument
    If you have any further issues, please let me know. Thanks!
    Matt S.
    Industrial Communications Product Support Engineer
    National Instruments

  • Runtime error ddic_typeleng_inconsistent when i execute st03n?

    Hi Experts,
    I am getting runtime error DDIC_TYPELENG_INCOINSISTENT when i execute ST03N.
    My server ECC6.0 ---Windows---Oracle 11.2.0.3.0
    Kernel 7.21, Patch 201
    Below i attached screenshot also.
    Please Suggest.
    Thanks & Regards
    Pravin

    Hi pravin,
    After 720 kernel upgrade you will get this DUMP.
    The 7.20 kernel checks complex DDIC structures in more detail than the previous kernels. Short
    dumps of the type DDIC_TYPELENG_INCONSISTENT may occur, for example, when calling transaction SM66.
    For more detailed information about correcting these inconsistencies, see Note 1610716.
    The actions described in this note can be performed anytime, but we recommend to implement it
    before the kernel switch.

  • Error 1003 when loading subpanel VI in build application (VI not executable)

    Error 1003 loading subpanel VI in build application (VI not executable). I referenced all supanel VI callers in my build app. What am I missing?

    Thanks for your reply!! I tried a few things I found online including the article you posted...this unfortunately did not solve my problem. Through some trial and error process I found the issue was with my build properties in the advanced section shown below.
    I had to check LabVIEW8.x file layout to allow the subpanel VI to load into my main app. I didn't think to check this cuz my code was developed in version 2010. I'm guesssing some of the callers where originally created in older versions and needed the the LabVIEW8 file layout, even though all my source code is compiled in version 10. If you think I might be wrong on this assumption let me know.
    P

  • Error 1003 when using excel reprt, but not Word

    I am trying to use the MS Office Report vi to send my data to an Excel. I am using Labview 7.1. 
    When I place the VI on the block diagram I get the following message: (Also attached)
    Error 1003 occurred at Open VI Reference in ex_RGT_Get
    Bookmarks and named cells.vi->Configure MS Office
    Report.vi->Confugure MS Office Report.vi.ProxyCaller
    Possible Reason(s):
    The VI is not executable. (OK Dialog box)
    If I click OK, the " Configure MS Office Report pop up window is mostly grayed out . If I select "Basic report for Word" I have no error message.
    I am using Excell 2003.  The problem is with a laptop computer I am using. I do not see this problem with a desktop computer. 
    Thanks,
    Bill
    Attachments:
    MS Report 8-24.doc ‏80 KB

    Hello Bill,
    You are not trying to build an executable, just use the Express VI in a regular development VI, right?  If so, this link describes the troubleshooting steps to get rid of this error.
    Regards,
    Clint M
    National Instruments

  • Error 1003 while building application - Vision 8 may be involved...

    Greetings Forum Readers,
    After upgrading from Vision 7.1 to 8.0, I'm now having problems building an executable for my application.
    Before the upgrade to Vision 8.0, I was able to build and deploy my application with no difficulties using the application build tools in the LV 8.0 Project view.  Since this Vision upgrade, all attempts to build the application terminate unsuccessfully with the following error message:
    Error 1003 occurred at ABAPI Dist Chg and Save VIs.vi -> ABAPI Dist Build LLB Image.vi -> ABAPI Copy Files and Apply Settings.vi -> EBEP_Invoke_Build_Engine.vi -> EBUIP_Build_Invoke.vi -> EBUIP_Build_Invoke.vi.ProxyCaller
    Possible reason(s):
    LabVIEW: The VI is not executable.
    Since the upgrade, it appears that some element of the application builder itself is broken. Thinking it may have something to do with the new license activation scheme,  I installed and activated a run-time engine on the development PC. This had no effect.
    Has anyone experienced this problem? More to the point, any suggestions on a work-around?
    Thanks in advance.
    -- D.
    www.movimed.com - Custom Imaging Solutions

    Nothing that should matter. I updated some logic in the VIs and added some OS dependent conditional disable structures. The project file has remained the same. 
    I think it might be a permissions error. Before this particular error, it randomly started giving me some errors when I tried to save things saying I didn't have permission to save certain things. So I attempted to fix all the permission mismatches with some good old chmod. And then it started giving this error. 
    It also does not appear to help to revert the code to the state it was in when it was first built. This leads me to beleive it is not something to do with the source code.

  • Error 1003 when compiling...

    Using LabVIEW 7.1 with the Application Builder...
    When building a particular VI, I get Error 1003 ("The VI is not executable"). The VI will execute when opened normally. The option that seems to cause the error is having the box checked that says, "Disconnect type definitions and remove unused polymorphic VI instance". When the box is not checked, the VI will compile.
    The VI in question uses both ActiveX methods for Microsoft Excel, and GOOP (I would imagine one of those is to blame).
    The problem is that I have isolated this small VI, but it is really part of a huge application which--I haven't tested this to find out but... I would imagine will be even more bloated if extra uneccessary code is added. If I can't compile this one little VI with that option checked, then everything else won't compile either, so it will have to remain unchecked when compiling the very large application (hence the issue).
    I can upload the VI in question if anyone wants to look at it.

    Joe Guo wrote:
    what are the excel versions on your development and target machines? Sometimes you can build an application with a lower Excel version and it still work with the newer version of Excel.
    -Joe
    I am developing on a PC with Excel '97 and targeting a PC with Excel '03. When I first ported my code to the Office '03 machine, the ActiveX methods/properties broke that were different so I modified them to make them work on the '03 machine. Since it was just the code in one .llb file, I maintained independent versions of that .llb--one on my machine, one on the Office '03 machine.
    The complications are that:
    - The Office '03 machine is not local to me
    - The Office '03 machine has all the hardware on it and obviously a much newer version of Office
    - The Office '03 machine is not typically used for development
    - My development PC can't have Excel '97 and '03 installed at the same time
    - A third '97 PC is also involved in building the application since our Software Configuration Management department has to independently verify the build.
    Ideally, I'd like to be able to drop in the Excel '03 .llb file I use and force it to build the application installation package regardless of whether or not the ActiveX component for Excel '03 is registered on my system--it will be registered on the target system, which is what's important. I talked with NI about this to submit a notice to R&D.
    The other thing I am currently looking at is figuring out if I can temporarily unregister the '97 ActiveX components and register the '03 components on a PC so that LabVIEW won't break when it loads the '03 version of the .llb file. I don't have much experience in that department, which would apparently involve the RegSvr32 app.

  • Error message when building an application for Labview PDA

    When using LabView PDA module to build an application for a PDA target, I receive the following message: "Error building executable. Unable to create file". Why is this happening?
    When looking at the error log, it reads "The system cannot find the file specified."
    This happens even when looking at one of the Labview PDA example VI's, so it is not a result of the VI containing functions of features not supported by Labview PDA.
    When installing Labview PDA, I installed files as follows, and in this order:
    (i) Labview 7.1 (installed previously)
    (ii) Microsoft eMbedded Visual C++ 4.0
    (iii) Microsoft eMbedded Visual C++ 4.0 SP 3.0
    (iv) Microsoft SDK for Windows Mobile 2003-based Pocket PCs
    (v) Microsoft ActiveSync 3.8
    (vi) NI Labview 7.1 PDA module for PocketPC
    (vii) DAQmx Base 1.0 for PDA or later
    Any ideas?

    Did you attempt to add the _wordsub.llb and _excelsub.llb files to the application as support files?  I believe in LabVIEW 8.0 instead of adding the entire LLBs you should just add the _Word Dynamic VIs.vi and _Excel Dynamic VIs.vi as dynamic VIs.  I think I've seen a similar post on the discussion forums in the past that recommended this.
    If this suggestion doesn't help, please reply, and attach a simple VI and .lvproj file demonstrating the problem so I can investigate further.
    Good luck,
    -D
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

  • Error 1003 when creating an exe

    I keep getting the 1003 error it reads
    Error 1003 occurred at ABAPI Dist Chg and Save VIs.vi -> ABAPI Dist Build LLB Image.vi -> ABAPI Copy Files and Apply Settings.vi -> EBEP_Invoke_Build_Engine.vi -> EBUIP_Build_Invoke.vi -> EBUIP_Build_Invoke.vi.ProxyCaller
    I know the error code is just a not executable VI, but my VI works fine. I have mass compiled it and it complies fine. I don't have any global or shared variables in this VI.
    Any ideas?

    had you try to delete your build spec and create a new one?
    In wich way had you created the build spec? convert from LV7.1 scpript or from the wizard in the LV8 project manager?

  • Error 1073 (on Clear Errors.vi) When Building Applicatio​n in LV 8.2

    I have seen numerous posts about this problem when building an application without a block diagram in LV 7.x, however, I am recieving this error on LV 8.2.  Whats most disturbing about it, is that it always hangs when processing Clear Errors.vi.  I have tried my source on two different machines, to no avail.  Also I tried to do a mass recompile of the entire vi.lib again no help.  It is very important that this program compiles, however I cannot get past this error.  Any suggestions?
    My specific error message is here:
    Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
    Error 1073 occurred at ABAPI Dist disconnect td-poly.vi -> ABAPI Dist Chg and Save VIs.vi -> ABAPI Dist Build LLB Image.vi -> ABAPI Copy Files and Apply Settings.vi -> EBEP_Invoke_Build_Engine.vi -> EBUIP_Build_Invoke.vi -> EBUIP_Build_Invoke.vi.ProxyCaller
    Possible reason(s):
    LabVIEW:  This property is writable only when the VI is in edit mode, or this method is available only when the VI is in edit mode.
    -Paul

    Hello Paul,
    I am sorry for not elaborating previously.  This issue has been documented previously for further investigation to our R&D group (# 3ZK9LGP2).  In the report I found that this error, though vague in the description, is fixed by enabling MathScript Support. 
    To enable MathScript support, check the checkbox in the application properties for the 'Enable MathScript support' option.
    -Bob
    -Bob

Maybe you are looking for

  • Error while loading table from flat file (.csv)

    I have a flat file which i am loading into a Target Table in Oracle Warehouse Builder. It uses SQL Loader Internally to load the data from flat file, I am facing an issue. Please find the following error ( This is an extract from the error log genera

  • Error while transporting ADDRESS to production system

    Hi all, We are in the process of a new rollout and we have created new plants and company codes. the same have been transported to quality and pre-production systems without any issues. however when we transport the same to Production, we face an err

  • Exception in Java Server proxy

    Hi, I created a synchronous Java Server Proxy , and when i tested it i got this error *Could not parse XMBMessage due to No SOAP Envelope but 1 MT_ProxyInput* What could i be doing wrong? <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> - <!-

  • Can I read the SYS_CONTEXT in REPORTS from Forms ?

    Hi, in a Forms module I set with a stored procedure a SYS_CONTEXT. This module calls a Report included a 'get' SYS_CONTEXT function but without getting this context. I hoped to transfer a where clause from Forms to Reports in the SYS_CONTEXT and cann

  • Can I view a live Numbers doc using an iFrame on my squarespace site?

    can I view a live Numbers doc using an IFrame on my squarespace site? This is the link: <iframe src="https://www.icloud.com/iw/#numbers/BALkvd4A5ZeoZ6EgvGeBpvA9G_uY0kx0k0-F/Aaron_Gh irardelli_copy" width="100%" height="1000px" frameborder="no" scroll