VI reference (error 1003) in executable

Hello all,
This is a branch-off from this thread.
Thank you for your reply Rob, I also suspect that the problem is related to "second-tier" subVI calls made by the first-tier subVIs. Here are answers to the questions you asked in your post:
-Yes, I am calling the VIs with absolute paths. To be more specific, I use the "VI Path" property of the VI (before exe) or "Directory Path" property of the Application (for exe).
-The three large subVIs that are called dynamically all share several subVIs. I suspect the problem is somehow related to this. To clarify, all three VIs use several specific VIs that I have written to open/read/write/close an industry-formatted file. I verified that the three main subVIs all call the common subVIs from the same locations on disk, i.e. the same subVI should not be included twice under different file locations. For a quick test, I dropped the file-editing subVIs into the 4th subVI (which never fails to open/close) and rebuilt the application. The results are the same: The 2nd, 3rd, and 4th VIs can all be opened and closed multiple times with no error. The first VI can be opened and closed once with no error, but then none of the first three VIs can be opened again (error 1003). Meanwhile, the trusty 4th VI can still open and close after the error begins, now with the several common VIs included in its code.
-I have the debug license, but I'm a little confused by what you suggested. At this point I am not running the subVIs (via invoke node) in order to produce the error, I need only try to open and close a reference to the VIs. I'm not sure if you meant to trace the execution of the subVIs when running them or if you had something else in mind. Can you please elaborate?
I am attaching an image of the block diagram of the top-level VI in case that helps. In the meantime I will continue investigating subVIs and attempt to identify any more useful symptoms. Thanks Rob (and anyone else!), I really appreciate your help.

Hmm... I thought I attached it. I'll try again.
Attachments:
080407_CompileError_BD1.jpg ‏81 KB

Similar Messages

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

Open VI Reference Error in the executable version only

Hello folks! I am having a strange issue since I updated to Labview 2014: I have a vi that uses "Open VI Reference" in order to programmatically open the desired vi. It worked flawless also in the compiled version (.exe) of the program until yesterday, when i compiled it again for the first time since my update to Labview 2014. It compiles with no problem, but when i start the exe and load the first vi it already gives me an error "Built Application or Shared Library (DLL): Missing".
The point is that all the VIs that i want to open are inside an LLB that is supposed to be compiled inside the .exe: infact the path that i use to open is:
D:\LabVIEW Data\builds\Sequenzer\Sequenzer2.0.exe\com_lv_sequenzer\trunk\Sequenzer_Functions.llb\Seq_Connect_to_Database.vi
And i get error number 7:
Open VI Reference in Seq_Function_Interface.vi->Sequenzer_Main_2.0.vi<APPEND>
VI Path: <b>D:\LabVIEW Data\builds\Sequenzer\Sequenzer2.0.exe\com_lv_sequenzer\trunk\Sequenzer_Functions.llb\Seq_Connect_to_Database.vi</b>
Built Application or Shared Library (DLL): Make sure all dynamically loaded VIs were properly included in the build specification for the application or shared library.
LabVIEW Real-Time: VIs built into executables cannot be accessed through VI Server calls. Use Source Distributions to dynamically call VIs on Real-Time targets.
The vi Seq_Connect_to_Database.vi is included in my built (as you can see in the attached screenshot and as it has always been).
Do you have an idea of why it is not working anymore?
Thanks a lot in advance!
Dario Cassaniti
Solved!
Go to Solution.
Attachments:
sequenzer.png ‏86 KB

OK, here is where I am confused. You talk about including the llb in the build, but in the screen shot you show a bunch of individual VIs being included. Next, in source file settings where are you telling the app builder to store all those individual VIs? Because they are VIs LabVIEW will, by default, want to put them in the executable somewhere.
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

Dynamically called VI becomes broken inside an executable. Error 1003 from "Open VI Reference".

Here's the problem. Dynamically called VI becomes broken inside an executable in debug executable mode Error 1003 is occuring from "Open VI Reference" Block. The computer has all of the necessary drivers, NI-VISA and NI-DAQmx. This executable is a new release of software that currently works on the PC in question. I can using NI-VISA Remote Server control the instruments from my PC using the executable. But when I put the executable on the PC I am getting this error. The only way I have been able to get this to work properly is to build the executable from the console I believe the project was created in, note that the project file has been moved to a network drive and it still works. All of the stations I have opened the project in show the VI that is being called is runnable. I've tried building the executable from the console I am deploying to and the same thing happens.
I am honestly at a loss for ideas why this is occuring. Is this something about the way LabView works internally that may be causing this problem?
I have trolled this forum for idea's and none have made sense to me.
Any input would be greatly appreciated.
-Nate

Two ideas:
Mass compile the project to ensure all linkages are ironed out
Include the dynamically launched VI's into the "Always Included" section of the build spec
Report back on if either of these actions solves your problem.
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

Error 1003 occured at Open VI Reference

This error occured when I want to used the LabView Report Generation Toolkit for Microsoft Office Example.
It's impossible for me to execute the example "Generate Report from Template(Excel)"
I suppose I have a problem with the Open VI Reference.vi function but I don't know where is that VI.
Could you let me know where are the VIs listed in the Application Control Pallette.
Do you know why I have this type of problem.
Thanks
Lucie

The VIs located on the application control palette are primitives and are part of LabVIEW itself. Therefore you can not look at their diagrams because they don't have one.
However the 1003 error means that you are trying to dynamically load a VI that is not executable. I would suggest turning highlight execution on and following the code to see what path is sent into the Open VI reference function.
Once you have the VI that is failing to open go manually open it.
Chances are that it is broken, so see why it is broken. If I remember correctly there is a linking issue in that example, so you can open the VI that is broken and hit ctrl-shift-Run Button, and that should relink it all and fix the issue.
If not take a look at this
Why Do I Get Error 1003 From Application Builder When I Try to Build Excel Macro Example.VI?

Error 1003 At Open VI Reference

I'm calling a VI from a library using the Open VI Reference. The main program in an executable file. If I make a change to the *.llb and try to call it using the main program I get an error 1003 Open VI Reference is not executable. Now I've made changes to the *.llb in the past and never got this error before, but this time I can't run the *.llb anymore. What is my issue?

Are you able to call the VI in the .llb correctly right after you build the executable? In other words, do you get the error only after making changes to the VI?
As long as you don't change the name of the VI in your .llb, you should be able to make changes to it and still run it from your executable.
How are you referencing the VI from the code in the executable? Are you using the absolute or relative path? Is all of this happening on your development machine, or are you moving the executable and .llb to a different machine?
Robert Mortensen
Software Engineer
National Instruments

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->AB_UI_Frmwk_Build.lvclass:Build.vi->AB_UI_FRAMEWORK.vi->AB_Create_Build_Application.vi->EBUIP_Global_OnCommand.vi->EBUIP_Global_OnCommand.vi.ProxyCaller
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.

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

When trying to build an application using labview 7.1 and windows XP, I get the error
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.vi
I've tried the crtl-shift-run as well as a mass compile and I still get the error.
Any ideas?
Thanks,
Mike

Hopefully this thread, or this KB article might help.
It seems like this could come from a lot of things, but there's suggestions in those which might lead you in the right direction
Message Edited by Day on 09-22-2006 02:07 PM

Error 1003 - The vi is not executable. Simulated DAQ-cards.

Hi all,
I am updating an application written in LabVIEW 7.1 for a customer. The code is not made by my company and is pretty horrendous but it works. I can not develop the code on the machine that it is supposed to run on so I have to do it on my own computer which means that I have to simulate two DAQ-cards that the program needs. I have pretty much finished the program and I want to test if I can build an exe-file. This is where I run in to trouble an get the error message:
Error 1003 occurred at \\Server1\Users\martinh\LabVIEW Data\app\internal.llb\_Main.vi
Possible reason(s):
LabVIEW: The VI is not executable.
I know that this has been discussed at length here and that one has to look out for global variables, dynamically loaded VI:s etc. My question is, does anyone think that the simulated DAQ-cards give me trouble? Do they use some VI:s placed somewhere odd which I need to include when I build the application?
Sincerely
Martin

Hi Martin,
I suggest you try what is suggested in this link, some of the information is already covered in the posts above but some might be new.
http://digital.ni.com/public.nsf/allkb/705C2ECA081F3C7986256C0F00559B02?OpenDocument
If you are using the office toolkit, it might be an idea to masscompile the _office folder and you might also need to uncheck the "Disconnect type definitions and remove unused polymorphic VI instances".
Good Luck
Andreas E
Applications Engineer
National Instruments

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

Mysterious Error 1003 in COMPILED rtexe

My code WORKS PERFECTLY under LabVIEW 8.6 (and LVRT 8.6).
It fails under LabVIEW 2010 (with LVRT 2010).
Here's what I'm trying to do:
My program uses "plug-ins" - stand-alone VIs to do some calculation during data acquisition.
For example, there is a measured SPEED channel and a measured TORQUE channel.
A plug-in VI called POWER calculates speed * torque / 5252.1 and produces POWER.
This is then treated just like it was another measured channel, they can record it, plot it, set alarms on it, anything they can do with a real measured channel, they can do with this artificial channel.
I'm sampling at 10 Hz, each sample causes a run of the plug-in and produces a new POWER sample.
The plugins use a TYPEDEF (called "Units") that has various units defined ("Hp", "kW", "Lb/hr", "ppm", etc).
They might use a subVI or two. I've made sure those are in the compiled executable.
The Real-Time program (called RTEC) does all the sampling, from various PXI boards and UDP sources. The HOST program calls for a channel called POWER, and provides a "signature" (hash value) for the VI that is on the host machine. RTEC compares the signature sent with it's own signature on file and decides if the version is the same. If not, it asks the host to send the whole VI (which is does, as a text block), and stores the VI file locally, along with the signature.
RTEC does the sampling and sends the data to the host. The host records it into a disk file. Along with the data itself, a header (containing setup information) is part of the data file, and also a copy of the plug-in VIs themselves. I do this to guarantee that the calculation used to produce the data is preserved as it is.
When reviewing the file, the user can edit some things (scale factors for instance) and re-process the data, that means re-running the plugins on the host.
The critical point here is that these are plug-ins - I do not want the user to have to open the main project and insert some vI into the project and build a source distribution.
The way it works now is that the user can create his subVI from a template. The template has the workings except for the calculation itself. ALl he has to do is specify that he wants "Engine Speed" in RPM and "Engine Torque" in Ft-lb, and it produces results in "Hp". He then does the multiplication, saves the VI, drops it into a specific folder on the host, and all else is automatic.
ALL THIS WORKS PERFECTLY in LV 8.6.
However, in LV2010, I get an error -1003 in a compiled RTEXE. If I run the RTEC program from the host environment (just clicking on the RUN arrow on the host), all is well. But we need to run compiled, as every host will not have a DevSys.
I have boiled it down to a simple test case - see attached pic.
If I OPEN the VI REF without a TYPE specifier, it works in either case (compiled or RTEXE), but I cannot later run the reference since it's not STRICT.
I tried both a GENERIC and a TEMPLATE reference, since I was first thinking that one was working and not the other, but they seem identical now.
The program works fine in the DevSys, but compile it to an RTEXE and I get error 1003 for the latter two cases.
I have read <a href="http://digital.ni.com/public.nsf/allkb/10F1D411ACBAD3D9862572FF0064C801">this</a>, <href="http://digital.ni.com/public.nsf/allkb/410F2EC66F60F9B0862569EE006F4FA0">this</a> , and <a href="http://digital.ni.com/public.nsf/allkb/0537EAF7F167718386256A96005D1DBC">this</a>.
What I get out of those is that maybe this is a "security" enhancement: it's no longer legal for a plug-in to call code or use typedefs from a compiled master app, whereas it was before.
QUESTION 1: Is that a fair interpretation?
I am guessing that the DevSys is handling this for me, but the RTEXE is unable to (since there is no compiler).
So, if I define ahead of time which TYPEDEFs and subVIs are permitted to be called from my plug-ins, and store a separate copy of those, I have to duplicate that relative path on the RTEXE. If I don't, the signature process will fail (if the path is changed, the signature of the VI will change).
QUESTION 2: Is that a reasonable statement?
And I have to duplicate the same folder of dependent stuff at REVIEWING time, since the exact same VI, extracted from the data file, must be executed by the reviewer on the host.
QUESTION 3: Is that a true statement?
QUESTION 4: Is there a better way? Right now (8.6) the fact that the VI wants to load a TYPEDEF from C:\Users\Steve|Projects\HDT\Libraries\HDT Units.llb\HDT Units.ctl and instead finds it in C:HDT\RTEC.rtexe\HDT Units.ctl (on the PXI box) , or in C:\Whatever\HDT Reviewer.exe (at REVIEWING time) is all automatic, invisible, and not a problem.
Apparently that's not so easy anymore.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

OK, NI Tech Support has been completely useless on this one, and nobody in the forum had ideas, so I had to work all week on it, but I have figured out the root problem. Here it is for anyone who's interested.
It definitely IS still legal to call INTO an executable, my conjecture that it was no longer legal was wrong.
I stumbled across the solution when I discovered that the setting DISCONNECT TYPEDEFS in the BUILD SPEC made a difference. If I tuned OFF the DISCONNECT switch, everything started working. The RTEXE size went from 2.2 Meg to 3.4 Meg, but at least it worked.
Not willing to live with that bloat, I kept chasing the real problem, now knowing that it was NOT a un-findable subVI, but a TYPEDEF that was the problem.
I turned the DISCONNECT TYPEDEF switch back ON, and stripped ALL the code from my plugin. Problem remains.
That suggests that it was with a TYPEDEF, not a subVI.
Two of the terminals of my plugins are TYPEDEFs.
I disconnected one (UNITS.ctl ) on a plugin, and got no change.
I disconnected the other (Channel Preqrequisite.ctl), and got no change.
But the Channel Prerequisite is a cluster, which contains a UNITS.ctl.
When I disconnected THAT, then it started working.
That confirms that it's a TYPEDEF problem (as suggested by the DISCONNECT TYPEDEFS fixing it).
What I had thought (and maybe it was true in LV 8.6) was that having an INSTANCE of a typedef'ed control in the MAIN was sufficient to make the plugins happy.
That is NOT the case. I suspect that this is a change in LV2009/2010 behavior, as I didn't have this problem in 8.6.
I knew that there were instances of the TYPEDEF'ed controls elsewhere in the MAIN, but, since we're DISCONNECTING TYPEDEFS, then the actual definition is not there.
To fix the problem, while still keeping DISCONNECT TYPEDEFS set to ON, I placed a STATIC VI REFERENCE in the main program, pointing to each DEFINITION (one to UNITS.ctl, one to CHANNEL PREREQUISITE.ctl), and it all works.
It works whether 8.X Layout is ON or OFF.
It works whether I run from an RTEXE or from the DevSys.
It works with the DISCONNECT TYPEDEFS setting ON (or off).
Whew!
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

"Add a dynamically VI" in Application Builder to prevent Error 1003 is no solution for a steadily rising amount of SubVIs.

My VI calls SubVIs (all with the same connections) in a loop with one 'call by reference'. It works great in the VI but when I build an Application I receive Error 1003. After that I read in the KnowledgeBase when I build the Application I must add dynamically all the SubVIs I call by reference. Works fine at the moment but the amount of the SubVIs is rising steadily (approximately 10 per week) and there are many users all over the world of this application. So it is practically impossible and very uncomfortable to build a new application everytime the amount of SubVIs rises. There must be another solution maybe some kind of initialization, adding
the paths of the dynamic called SubVIs programmatically???

You do not have to include all the dynamically called subVIs in your build. If you look at the shipping example called Plug In Example, the dynamically called VsubIs are in a subfolder called plugins. In this example, the paths to the subVIs are created based on what files are present and which have the correct type specifier. The high level VI can be built into an executable. The plugins folder could also be included with one or two subVIs but once installed, new subVIs can be distributed separately and just put into the folder. The only trick is to make sure that the path to the plugins folder is correctly obtained whether the VI is run in development mode or as an exe.

VI reference (error 1003) in executable

Similar Messages

Maybe you are looking for