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

Similar Messages

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

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

Calling subvis dynamically from within an exe (avoiding error 1003)

Hi,
I'm using an architecture where the main program (compiled to an exe) can be supplied with user-"plugins" that are collections of vis of specific types inside a specially named folder relative to the exe. They can be called from within the exe via "open vi reference" supplied by the corresponding strict vi types and the corresponding relative paths.
I want to avoid having to include any of the plugins in any way in the application builder, since users should be able to create own plugins that the application is totally unaware of during build.
In principle this approach works quite well, since these plugins are not extremely complex, but occasionally I get an error 1003 when loading a plugin.
I've read many old posts about this error in this particular situation, mostly using LV versions 7 or 8 (I'm using 2012). One suggestion was to build a source distribution for every plugin, including everything that is used from vi.lib, instr.lib, and user.lib. This indeed helped in my particular case - however, it bloats the plugin "distribution" (which consists originally only of a couple of user vis) extremely and makes user-side developement more complicated.
Now some plugins run nicely from within the exe without having to build a source distribution for them (they still use many vi.lib vis) while others don't and I have no clue why...
These plugins are wrappers for hardware drivers which allow controlling any hardware instrument from within the main application through a certain API. So, in a particular case, a plugin which produced error 1003 is using VISA serial functions (all inside ...\vi.lib\Instr\_visa.llb) and one without error doesn't (yet it uses many functions from ...\vi.lib\Utility\...).
I can fix the VISA-problem in a simple way by including (only) the used VISA-vis (and typedefs) inside the plugin's folder and explicitely link to them (i.e. replace the VISA-vis from vi.lib with the copied ones in the plugin's folder - I guess this is also what the source distribution does).
However, I'm confused why some plugins with linked vi.lib vis work while others produce an error 1003 unless those particular vis are explicitely distributed and linked with them...
Oh and just for completeness: All plugins work fine if called from within the developement system, the problem occurs only if called from within an exe.
Solved!
Go to Solution.

There are some VIs in vi.lib that call other VIs dynamically. Sometimes you have to explicitly add these to the EXE or distribution.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

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?

App. builder Error 1003 occurred at ..... internal.llb

Hi,
I have an RT application that uses three FPGA PXI-7831R. The application was created with LabVIEW 7.0. We upgraded to 7.1, then to 7.1.1. We followed the instructions for 7.1.1, mass compile LabVIEW and mass compile our own code.
For the FPGA I had to create projects. I built the loads for each of them, updated the Open FPGA References in the RT code and then I was easily able to build an EXE with application builder. However, that load contained errors, so I had to debug it. I changes aliases in the FPGA projects, recompiled the 3 FPGA loads and refreshed their references in the RT code. I was able to debug the code and solve all my problems. That load would run with LabVIEW environment, downloaded to the RT target.
However, with application builder, when I compile that new load, I get: Error 1003 occurred at … internal.llb… The VI is not executable. I verified the VIs and their arrows are not broken. I already had "BldApp.RemovePolyVIsandTypedefs=False" in LabVIEW.ini. I opened my RT top level VI and performed ctrl-shift-run and LabVIEW becomes not-responding, taking 99% of the CPU, in that state for 90 minutes. I repeated that with a lower level VI containing FPGA Read/Write Control and got the same behavior, ctrl-shift-run makes LabVIEW to process I don't know what until I kill it. I could repeat that on 2 more PCs. However, it is ok if I do that with a VI not containing FPGA references.
The VI stated to be non-executable contains call to FPGA Read/Write Control. I removed these calls to debug and I got the same Error 1003 on the next VI containing an FPGA Read/Write Control. Are there some known issue with application builder and accessing FPGA with LabVIEW RT 7.1.1?
Thanks!

Hi, AvernaFrca
You shouldn't have any problems when creating an EXE in LabVIEW that calls the Open FPGA VI Reference or the Read/Write Control VI. There are a few KBs online that relate to that error number, but it seems that you have read them already, because the suggested fixes are to mass compile (or do Ctrl + Shift + R) and that doesn't seem to fix it for you.
In your case, I would recommend you to make sure that your VIs are not corrupted. The easiest way will be to create another FPGA VI that you could call from a brand-new host VI. It can be something as simple as just do A + B. If that does work, then it might be a problem with your current VIs and it might be a good idea to recompile them, just to make sure. Hopefully that will take care of it. If the error is still present, then the problem might be the actual Read/Write Control VI, and we will have to fix or replace it with a new one.
I hope this helps! Let me know if you have any additional information.
GValdes

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 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 occurred at ABAPI Dist Chg and Save VIs.vi

I used to be able to build executable file for my application. However when I upgrade to LV8 and try to build executable file, I got the following 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.
The vi is perfectly executable in LV enviroment.
Anyone know what's going on?
Thanks in advance!

DGU,
Unfortunately this is a known bug in LabVIEW 8.0.1. Our R&D department is well aware of the issue and is currently working on the problem. In the mean time there are some possible work arounds
Check the "Enable debugging"option in the "Advanced Category" of the application executable properties.
Disable the "Remove Panel" option for all SubVIs containing Shared Variables in the build
Try Unchecking the "Disconnect type definitions and remove unused polymorphic VI instances" options also in the Advanced category of the executable properties as shown in the attached figure.
Move shared variables to the top level VIs and pass the data through the SubVI connector
Downgrade to LabVIEW 8.0.
I apologize for the problem. Please let us know if these suggestions help out. Thanks!
Best Regards,
Chris C
Applications Engineering
National Instruments
Chris Cilino
National Instruments
LabVIEW Product Marketing Manager
Certified LabVIEW Architect
Attachments:
1.gif ‏1 KB

Error 1003 occurred at Invoke Node

Good morning.
I work with LW8.5 and created with the following architecture:
There is main.vi on the links at the user's calls and runs the other VI.
That is, not directly, these are not included in the VI block diagram main.vi.
In the development of a happening in normal mode, all dynamically called VI,
But once I make EXE, when you try to call the dynamic VI error 1003.
Error 1003 occurred at Invoke Node in Main.vi
Possible reason (s):
LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Open the VI in LabVIEW using File>> Open and verify that it is runnable.
VI Path: C: \ Shaikov \ Labwiev \ builds \ NSIAES \ Initialsettings \ Initialsettings.vi
Show you how to act?
Thank you.

Hello margasan.
In my Projects I use to pass more dynamic and VI classes.
In the attached file - an example of my project:
In the main folder is a folder UpperClass, it is the parent class and child classes and HeirClass.lvclass Heir2Class.lvclass are organized into folders respectively Plugin1 and Plugin2, and these Classes inherit from the parent one and the same WI - UpperClassTest.vi. Plus, this Plugin1 has two, independent from the others, but related classes. A block diagram for an object placed Core.vi UpperClass.
So, here, if you take EXE, making llb files and run them from start VI for each of the Plugin, then everything works OK.
But as soon as I on the block diagram of a Plugin will put any object UpperClass, or one of its nasalednikov, there arises a familiar ERROR 1003. Prompt, plc, margasan I get rid of it in this case?
Attachments:
Example.zip ‏1481 KB

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

Mysterious Error 1003 in COMPILED rtexe

Similar Messages

Maybe you are looking for