LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Solved!
Go to solution

@aputman wrote:

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.  


attached is the VI that calls it.

This is a very involved set of VIs

 

thanks

0 Kudos
Message 31 of 44
(1,255 Views)

I am late to the game ... excuse if already covered...

 

A property node >>> Execution >>> state will tell what state the target VI is in. Add an indicator and see if there is a difference between the development and run time.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 32 of 44
(1,250 Views)

I'm going to say that this is the offending piece of code.  Creating the static reference to the test vi reserves it for running, causing you to get the error 1000 when you try to open the reference again and run it.  Why it works in 8.6 and not 14, I can't say.  

Capture.PNG

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
Message 33 of 44
(1,245 Views)

@aputman wrote:

I'm going to say that this is the offending piece of code.  Creating the static reference to the test vi reserves it for running, causing you to get the error 1000 when you try to open the reference again and run it.  Why it works in 8.6 and not 14, I can't say.  

Capture.PNG


I am not sure.

 

I have often used static reference to ensure that dynamically loaded VIs are included in a build without the manual work of including them explicitly in the build. They also let me reference the target VIs by just using the name and not having to figure out what the correct file spec inside the exe should be.

 

It really seems that the target VI in this discussion is either broken, already running, or reserve to run being part of another already running VI.

 

Just my 2 cents,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 34 of 44
(1,235 Views)

@Ben wrote:

I am late to the game ... excuse if already covered...

 

A property node >>> Execution >>> state will tell what state the target VI is in. Add an indicator and see if there is a difference between the development and run time.

 

Ben


Thanks for the idea Ben.

 

Not sure how to incorporate that though...

0 Kudos
Message 35 of 44
(1,228 Views)

@robojeff wrote:

@Ben wrote:

I am late to the game ... excuse if already covered...

 

A property node >>> Execution >>> state will tell what state the target VI is in. Add an indicator and see if there is a difference between the development and run time.

 

Ben


Thanks for the idea Ben.

 

Not sure how to incorporate that though...


?

 

Mark the VI that does the launching as "show FP when called" and make sure the indicator of the state is visible.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 36 of 44
(1,225 Views)

@Ben wrote:

@aputman wrote:

I'm going to say that this is the offending piece of code.  Creating the static reference to the test vi reserves it for running, causing you to get the error 1000 when you try to open the reference again and run it.  Why it works in 8.6 and not 14, I can't say.  

Capture.PNG


I am not sure.

 

I have often used static reference to ensure that dynamically loaded VIs are included in a build without the manual work of including them explicitly in the build. They also let me reference the target VIs by just using the name and not having to figure out what the correct file spec inside the exe should be.

 

It really seems that the target VI in this discussion is either broken, already running, or reserve to run being part of another already running VI.

 

Just my 2 cents,

 

Ben


Right.  My comment is only true for strictly typed references, which these are not.

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 37 of 44
(1,220 Views)
Solution
Accepted by topic author robojeff

The false case of that same bit of code has the VI being called like a normal subVI.  It looks like that was an attempt to load the test into memory as well but is not being used.  Doesn't this reserve the VI for execution?  I would assume in an EXE that this code would be removed completely since it can never be called anyways but in the IDE environment, that wouldn't be the case, correct?  

 

If you just delete these VI's from this case, see if that fixes the issue.

Capture.PNG

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
Message 38 of 44
(1,216 Views)

@aputman wrote:

The false case of that same bit of code has the VI being called like a normal subVI.  It looks like that was an attempt to load the test into memory as well but is not being used.  Doesn't this reserve the VI for execution?  I would assume in an EXE that this code would be removed completely since it can never be called anyways but in the IDE environment, that wouldn't be the case, correct?  

 

If you just delete these VI's from this case, see if that fixes the issue.

Capture.PNG


That was it.

I removed those and now it runs.

I added them back and I get the error 1000

 

Thank you everyone for helping to solve the problem...

 

0 Kudos
Message 39 of 44
(1,210 Views)

After some thought, this might not be a LabVIEW 2014/ 2015 issue at all...

 

It might be a Windows 10 issue and how and what it allows LabVIEW to execute out of memory...

 

0 Kudos
Message 40 of 44
(1,199 Views)