Poor|Excellent Yes No Document Quality? Share this post Link to post Share on other sites Chris Davis 2 Extremely Active Members 2 423 posts Version:LabVIEW 7.0 Posted January 3, 2007 I'm going down the exe If you are using any Conditional Disable Diagrams in your program, check each subdiagram and ensure that the code in each case is not broken. If found there the actual path of the subVIs is ignored and the internal VI has the precedence to be opened. http://softacoustik.com/labview-error/labview-error-1003-the-vi-is-not-executable.php
This is a tough question to answer without the aid of the Application Builder. Error 1003 can occur if any subVI is not executable. It is important that the whole hierachy of the VI be accessible and that the executable installer has correctly installed the required resources (serial, math lib, etc.) I usually do that 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:
This situation can cause Application Builder to return Error 1003. This isn't bad unless the 2 VIs are different some how, the first one loaded will "win", etc just like in the development environment. How is this handled within executables? Tim 0 Kudos Message 1 of 22 (1,455 Views) Reply 0 Kudos Re: Error 1003 when dynamically calling VI within an executable crossrulz Knight of NI 09-08-2014 04:38 PM Options Mark
Please please please - does anyone know how to force the links between a VI and its' subVI to be relative (am I going to need to hack the VI's binary Edit: unless there is a major change of behavior in LV8... LabVIEW Application Builder 8.6 with LabVIEW 8.6). One way to do that is to actually try to do a source distribution of your plugging including everything (VI.lib etc...).
They are special in the sense that the path of subVIs located there are stored as symbolic path ( e.g.
And as mentioned VI links are stored as relative links (the only time they might be absolute is if the linkage spans between drive letters, I think but I haven't tried This will ensure app builder finds, includes, and loads the appropriate code into the exe. Click Save. VeriStand performs a check to see if any changes have been made to the deployable files on the development computer and only republishes the files when a change has been made.
I guess the question is; could that main application EXE link to the module code in the plug in EXEs? http://digital.ni.com/public.nsf/allkb/0537EAF7F167718386256A96005D1DBC Attached is a screen cap of the code that launches one of the offenders. Please Contact NI for all product and support inquiries. A VI that opens fine in LabVIEW will be broken in your application when subVIs are located in these special folders.
Share this post Link to post Share on other sites crelf 274 I'm a LAVA, not a fighter. http://softacoustik.com/labview-error/labview-error-ni-488.php Primary Software: LabVIEW Development Systems>>LabVIEW Full Development System Primary Software Version: 7.1.1 Primary Software Fixed Version: N/A Secondary Software: N/A Problem: My LabVIEW application uses VI Server to call and run The error message is attached when I click on the broken arror in runtime. And of course your top level vi should point to the right path where these dynamic called vis are.
Again, I thought I saw a way around this a while ago - can anyone please enlighten me? Related Links: KnowledgeBase 4QTE1D0U: Why Do I see VIs Under the Error List When I Have a Real-Time VI Without a Broken Run Arrow?KnowledgeBase 312GMCW0. My thoughts are that your relative paths are being messed up when you build up the executable. check over here Please tell us why.
Mass compile the VI before you build the executable. I specifically don't want to include my plug-in VIs in the distribution with the executable - I want to call them by name and path only. Poor|Excellent Yes No Document Quality?
Solution: When programmatically launching a VI which has NI-CAN functions (for example, using an Open VI Reference function from the Application Control palette and then using an invoke node to launch Build, and download the distribution folder to your target and run your dynamic VI. /J Share this post Link to post Share on other sites AutoMeasure 1 Very Active Members Solution: This error message can be the result of many different scenarios. Tim 0 Kudos Message 5 of 22 (1,380 Views) Reply 0 Kudos Re: Error 1003 when dynamically calling VI within an executable crossrulz Knight of NI 09-09-2014 10:10 AM Options Mark
For LabVIEW 7.1 and earlier:ClickAdd Dynamic VIfrom theSource Filestab in the Application Builder build specification. The RTE can not run a VI compiled in another version (At least that's how it used to be and I doubt it was changed). Primary Software: Primary Software Version: 8.5.1 Primary Software Fixed Version: N/A Secondary Software: N/A Problem: I am trying to use VI Server in my host VI to call a VI on this content I'll have to research to figure out what those were.
Note: You have to go through all the previous steps when the top-level (or any subVI) contains a timed loop. From the host PC, I open an Application Reference to the RT Engine, and I then open a VI Reference to the VI on the hard drive. It is important that the whole hierachy of the VI be accessible and that the executable installer has correctly... However, those dynamically called VIs are specifically called out in the build spec to "Always Include".
I've done some poking around and found that it works fine when the advanced option "Use Labview 8.x file layout" was selected on the advanced page in the build definition.