Open VI Reference Function and a RUN VI RUN VI Method Causes Error 1000 with version 2014

[robojeff]

---

@aputman wrote:

Actually, the problem is most likely that it can't find the VI.  I believe Labview 8.6 is one of the versions that lumps all of the VI's into a single directory under the EXE so that you only have to call the VI by name.  In newer versions, however, the EXE directory structure mimics the project directory unless you have the build flag "Use LabVIEW 8.x file layout" set to TRUE.  You'll need to specify a path relative to the application directory or the calling VI path.  

---

I am attempting to run this application in an evaluation copy of LabView 2015, so correct me if I am worng,

but does the build flag apply at this point?

I will most likely need to look into this when I am ready to rebuild the application but for now I am not sure what I can do to allow this application (lvpproj) to run in the evaluation mode of Labview 2015

thanks 

[aputman]

I am not sure of the limitations of an evaluation copy. If you are able to build an EXE, then yes, the build flag is applicable. But I would not recommend using that particular build flag. The better solution is to build the proper path to the VI. You should have logic built into it so that whether you run in the IDE or as an EXE, the VI can be found. One way this can be accomplished is using a properly node with the Application class selected (default) and the property App.Kind. Or you can use the Application Directory constant which, according to the help file:

[robojeff]

At this point, I am not interested in building an EXE.

I just want to look at this application in the debugger mode to isolate some problems that I am seeing with the current EXE which was created with v8.6

I loaded an eval copy on this PC because it has the hardware that I need for this application and my development system with the licensed copy is not capable of supporting the same hardware.

The reason why I am attempting to do this with v2014 & v2015 is because I am attempting to port this application from a Windows XP system to a Windows 10 system. The current application that I have was created in v8.6 and will run on a Windows 10 system but it has a 

few bugs that I need to fix. (and hence the problem)

Maybe I should load v8.6 on this system as the newer versions are a real problem with this set up and this code...

[aputman]

Is the called VI exiting properly when you quit the main VI?  Exiting the main VI doesn't kill the execution of the subpanel VI.  That error usually indicates that the VI is still running in the background and when you call the Run VI again, it's already running.  Does everything work fine during the first call after restarting Labview but fails every other time after that?  If so, that is likely your issue.  

[robojeff]

---

@aputman wrote:

Is the called VI exiting properly when you quit the main VI?  Exiting the main VI doesn't kill the execution of the subpanel VI.  That error usually indicates that the VI is still running in the background and when you call the Run VI again, it's already running.  Does everything work fine during the first call after restarting Labview but fails every other time after that?  If so, that is likely your issue.  

---

When either starting (or restarting) LabVIEW,  the error occurs the very first time (and anytime after that).

As I had shown in my initial post, there is a Open VI Reference Function that is used and later a RUN VI RUN VI Method is used.

[aputman]

From the little bit of the picture (NOT CODE) that I can see, that is the proper way of starting a VI for running in a subpanel.  However I can't see the rest of the code.  Is this VI used in another part of the application, meaning that it is already running when this RUN VI is called (not sure why you are calling it a RUN VI RUN VI)?

[robojeff]

---

@aputman wrote:

From the little bit of the picture (NOT CODE) that I can see, that is the proper way of starting a VI for running in a subpanel.  However I can't see the rest of the code.  Is this VI used in another part of the application, meaning that it is already running when this RUN VI is called (not sure why you are calling it a RUN VI RUN VI)?

---

RUN VI RUN VI was a typo and should have been RUN VI

I have attached that part of the code which is a small section of the project and the way that the person who wrote this project

chose to call all of the tests that can be called...

It looks to be correct per help examples for some of the components and worked with v8.6 but for some reason don't work with 2014 & 2015

The VI does not appear to be already running when called and the VI Reference Function that is opened to this RunTestInSubpanel.vi is closed before exiting this VI. 

In the Labview Help regarding this error, it states:

The same error will occur if the targeted VI is not running, but is reserved for running. A VI is reserved for running when a reference to it is opened using the Open VI Reference function with a strictly typed VI Refnum wired to the type specifier VI Refnum input. Using the type specifier allows you to call the VI using a Call By Reference Node. Any time you are using a Call by Reference Node, your VI is reserved for running. The strictly typed VI reference must be closed before editing methods may be invoked or editing properties may be set.

Opening a VI reference without the type specifier does not reserve the VI for running. Editing properties and methods may be used in this case, as long as the VI is not actually running.

But I am not opening the VI reference without the type specifier

[aputman]

---

robojeff wrote: 

But I am not opening the VI reference without the type specifier

---

This is a double negative which would translate into you are using a type specifier, which of course you aren't.  Just being nitpicky.  My wife hates that.  

I don't see anything wrong in this VI.  Are you able to post one of the test VI's and the VI that contains the subpanel?  

[robojeff]

---

@aputman wrote:

---

robojeff wrote: 

But I am not opening the VI reference without the type specifier

---

This is a double negative which would translate into you are using a type specifier, which of course you aren't.  Just being nitpicky.  My wife hates that.  

I don't see anything wrong in this VI.  Are you able to post one of the test VI's and the VI that contains the subpanel?  

---

Thanks

Attached are two files. AnalogDataAcquisitionTest.VI is one of the tests (all of the tests are called the same way and the error 1000 shows up when any of them are called.

The second file is what I believe is the subpanel.

I don'r know much about this code and the guy that wrote it is no longer around but I recall someone telling me that he is using 

a panell and a subpanel at the same time to show different parts of the test while it is being run.

[aputman]

No, that is not the subpanel.  If you look at the first VI you posted (RunTestinSubpanel), that VI is called from somewhere and a reference to the subpanel is passed to it.  That is most likely where the subpanel can be found.