05-24-2017 11:08 AM
@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
05-24-2017 11:23 AM
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
05-24-2017 12:41 PM - edited 05-24-2017 12:52 PM
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.
05-24-2017 12:56 PM
@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.
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
05-24-2017 01:24 PM
@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...
05-24-2017 01:26 PM
@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
05-24-2017 01:46 PM
@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.
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.
05-24-2017 01:53 PM
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.
05-24-2017 03:45 PM
@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.
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...
05-25-2017 06:19 AM
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...