Share this post Link to post Share on other sites CharlesB 2 Very Active Members 2 59 posts Version:LabVIEW 2014 Since:2003 Posted June 7, 2011 Got it here too. I.e. Share this post Link to post Share on other sites rolfk 369 LabVIEW Aficionado Members 369 2,613 posts Location:Netherlands Version:LabVIEW 2011 Since:1992 Posted March 10, 2010 Well... "Development Environment is If you can give more details on how you proceed maybe we might find the source of the problem... this content
Why would it work there and not in an executable? My VIs do have subVIs, and I thought that the implicit internal location that is saved within the VIs that I call would be enough to load in the subVIs too... You can select this option in the build specification's properties in the Advanced menu. What OS?
Not sure where else I could have missed something. Join in the conversation: 2016 Advanced Users TrackNI-Week attendees, click here to take the survey for the sessions you have attended! 0 Kudos Message 6 of 22 (1,479 Views) Reply 0 Mass compile the VI before you build the executable. Answered Your Question? 1 2 3 4 5 Document needs work?
They said the issue was that during the build process it looks at all the VIs that are dependencies and determines if the code is broken. That's why saving for application distribution solves the path problems, saving the whole hierarchy at the same place and relinking VIs to the new location. Sign In Now Sign in to follow this Followers 0 Go To Topic Listing LabVIEW General All Activity Home Software & Hardware Discussions LabVIEW General vi path for asynchronuos call in Share this post Link to post Share on other sites DRivel 0 LAVA groupie Members 0 3 posts Posted May 5, 2006 Hi Folks, First time posting here - hope
Our applications (this and this) have been distributed in different countries with different local languages without problem. [Advertisement Off] Make the EXE only for the top level vi, you don't need Please tell us why. Sure enough, I get a "Error 1003 occurred at Open VI Reference - The VI is not executable." - only VIs that I include in the build (even if they aren't http://digital.ni.com/public.nsf/allkb/BF00F6AA70B88C8D86256F27005257F5 The solution for me was simply to close LabVIEW, relaunch and my build process would work again.
You made no other changes to the code? This screws everything up if you create an installer and bundle your plugins and their subVIs with it (thus moving the VIs from their original locations) - even if you preserve It saves a lot a VIs that may already be in the app.exe but it is harmless. Let's see, nothing too fancy in the top-level VI, no classes or Mathscript.
I remember going down this path as well. All rights reserved. | Cart|Help KnowledgeBase Request Supportfrom an engineer NIHome > Support > KnowledgeBase English 2 ratings: 2.5 out of 5   Error -1003 Labview Error 1003 Open Vi Reference I do use some DAQmx VIs. This really need to get fixed.
Share this post Link to post Share on other sites Chris Davis 2 Extremely Active Members 2 423 posts Version:LabVIEW 7.0 Posted May 3, 2006 I thought this had been news He spent several days trying to fix this, without success. Where is my mistake? Thanks for any help, Ralf Share this post Link to post Share on other sites smithd 64 Very Active Members 64 237 posts Version:LabVIEW Solution: You can receive error 1003or error 7when you try to call a VI by reference or try to run a VI dynamically using VI Server and the called VI cannot
Rolf Kalbermatter Share this post Link to post Share on other sites Mellroth 64 The 500 club Members 64 600 posts Version:LabVIEW 2013 Since:1995 Posted February 8, 2007 As others too bad that CLA courses do not teach how to solve problem. Join in the conversation: 2016 Advanced Users TrackNI-Week attendees, click here to take the survey for the sessions you have attended! 0 Kudos Message 2 of 22 (1,553 Views) Reply 0 have a peek at these guys I can open the plugin vi without any errors in development but get a broken arrow in runtime.
And I found that besides updating the type-specifier after a typedef changes, you also must prevent yourself from checking on 'disconnect typedefs' in the executable build options. I have many dynamic dispatch VIs. Share this post Link to post Share on other sites crelf 274 I'm a LAVA, not a fighter.
Sign In Sign In Remember me Not recommended on shared computers Sign in anonymously Sign In Forgot your password? Hi PJM, what is pb? "pb" is a usual abbreviation for "problem", so I think that means "to isolate the lvclass that causes the issue" being french helps understanding other french What is the make up of your top-level VI? One way to do that is to actually try to do a source distribution of your plugging including everything (VI.lib etc...).
Poor|Excellent Yes No Document Quality? See LabVIEW 2013 Help: Relative Paths for more information on using relative paths. If found there the actual path of the subVIs is ignored and the internal VI has the precedence to be opened. check my blog We were initially successful with this approach (after we pealed off all we could except the dependencies and ancestor from the project) but as soon as my customer started to add
In order to track down the root issue, I would say try to get a set of code that reproduces the problem and submit that to NI support for evaluation. Please Contact NI for all product and support inquiries. Cannot complete build because following VI loaded broken: X:\Eric_NI\power_vis\tempandpowerTEST_15.vi Open the VI in LabVIEW and fix the listed errors. Related Links: KnowledgeBase 2O79IHUV: Error 1003 Occurs When Trying to Create an Executable KnowledgeBase 5SIEL81O: Error 1003 Occurs When Trying to Compile LabVIEW 2011 Project Attachments: Report Date: 10/08/2004 Last Updated:
I can't see anything odd in the project. If a subdiagram that only executes under the Run Time Engine setting contains broken code, the run arrow for the top level VI willnot appear broken in development mode, butError 1003can I receive the following error message. I spent alot of time working on how to properly call these VIs dynamically and if I remember correctly, putting the open ref in the for loop caused issues.
How is this handled within executables?