LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to call a VI by reference that is already loaded in a different application instance?

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):

 OpenVI.png

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?

 

0 Kudos
Message 1 of 15
(4,132 Views)

Well.. What is the VI's state?

 

Also, what call options are you using when you open the VI reference?

0 Kudos
Message 2 of 15
(4,105 Views)

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.

0 Kudos
Message 3 of 15
(4,067 Views)

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.

0 Kudos
Message 4 of 15
(4,053 Views)

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:

GetVI.png

 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 Smiley Frustrated

0 Kudos
Message 5 of 15
(4,036 Views)

Then try using the "Open VI Reference " with a string inpout for VI name instead of a path.

0 Kudos
Message 6 of 15
(4,030 Views)

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.

0 Kudos
Message 7 of 15
(4,017 Views)

@JonP wrote:

Sorry, the same thing happens, but please keep the ideas coming - you are obviously a good fount of ideas!


Bad ideas, yeah. Smiley Very Happy

0 Kudos
Message 8 of 15
(4,000 Views)

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?

Message 9 of 15
(3,998 Views)

You are right, that is the problem! Immediately after I open the VI:

  • from the project's application instance the VI state is "Running".
  • in the current application instance the VI state is "Idle" and everything works.

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 Smiley Happy).

0 Kudos
Message 10 of 15
(3,989 Views)