04-09-2018 11:47 AM
I have a bunch of VI's in a LabVIEW project called, say, OtherProj.lvproj. These get called from a TestStand application. To make sure that the correct FGV instances are used every time all calls are through the lvproj file.
Now I need to call one of these VIs (the particular VI is programmable so I can't use a static instance) from another VI later on in the TestStand sequence. The calling VI is not in the same project file as the callee for various reasons so I want to open the callee in OtherProj.lvproj's application instance. I use the following code to open it (close references etc. are omitted for clarity):
This works fine. Using the returned VI reference I then set up the controls to the values needed for the invocation, which also works fine.
Finally I run it with the same VI reference using the Run VI method. "Wait Until Done" is True and "Auto Dispose Ref" False (because I want to read an indicator later). However the invoke function returns Error 1000, "The VI is not in a state compatible with this operation."
If I open the VI in the current application instance the Run VI works, but of course the VI sees uninitialized FGVs and other globals. Perhaps what I am trying to do is not possible?
04-09-2018 12:48 PM - edited 04-09-2018 01:09 PM
Well.. What is the VI's state?
Also, what call options are you using when you open the VI reference?
04-10-2018 03:13 AM - edited 04-10-2018 03:15 AM
The VI state is "Running", it is also "Running" immediately after the Open. This is the correct state I believe, I suspect I get the error 1000 because the VI is reserved for execution by a different app instance than the one I invoke Run from.
As shown in the snippet, I pass no options to the Open, so it defaults to 0.
04-10-2018 06:14 AM
Use the App reference to get a list of VIs in memory and use that reference if you require. Opening a new reference os not the same thing as getting a reference to an already open VI.
04-10-2018 09:41 AM
Good thought but ... the only list of VI's I can get from the app ref is "All VIs in memory" and I'm not sure how to get a ref from the name. I tried this, which I think achieves what you are suggesting:
The reference input to the Project property is the project I located in the original post, and MyDouble.vi is the test VI I am doing my trials with. Sadly I get exactly the same problem
04-10-2018 10:06 AM
Then try using the "Open VI Reference " with a string inpout for VI name instead of a path.
04-10-2018 10:40 AM
Sorry, the same thing happens, but please keep the ideas coming - you are obviously a good fount of ideas! It's amazing how much time I spend doing "trial and error" changes in LabVIEW to get something to work, mostly because of the sparse help text. Mind you it's similar in the other IDEs I am using, like C# .NET.
As an aside, I don't understand the reason why LabVIEW runs projects in a different application instance, it causes my company a lot of hard-to-diagnose problems and the only benefit seems to be that it allows VIs with the same name to exist in different projects, which is usually easy to fix! But that's a different discussion I think.
04-11-2018 02:10 AM
@JonP wrote:
Sorry, the same thing happens, but please keep the ideas coming - you are obviously a good fount of ideas!
Bad ideas, yeah.
04-11-2018 02:12 AM - edited 04-11-2018 02:12 AM
You are trying to run a VI which is already running? (or reserved for running, same thing essentially).
Can't you make the VI reentrant?
04-11-2018 05:16 AM - edited 04-11-2018 05:21 AM
You are right, that is the problem! Immediately after I open the VI:
I had assumed that "Running" was OK because it actually means reserved for running, but obviously it is not. The VI is not running and there should be no need to make it re-entrant, although making it re-entrant does indeed work even without the 0x8 "Prepare for reentrant run" option to the Open function. However I don't really want to make everything in the lvproj re-entrant especially as customers can put their own VIs into it. I guess I might need to contact NI support (we are on support but I usually see better answers in this forum ).