LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Accessing a VI reference from project file versus directly

I am having a problem using the open VI reference function to determine if another VI is currently running.  I have code that passes the specific path to a particular VI into the Open VI reference function, then checks the front panel and execution state of the returned VI reference variable. Normally the front panel state reads "Open" and the Execution state reads "Run Top Level" whenever the desired VI is running. The desired via is called touchSim and if its not running, the user will be prompted.  This code has worked as-is for quite a long time, across several versions of LabVIEW (currently 8.2.1).
 
With the advent of project files, we created a new project file around the touchSim vi which contains related VIs, icons, etc. The actual code has not changed.  Unfortunately, this has created a strange behavior with the VI reference property node values.  If I double-click the touchSim.vi from Windows and run it, the front panel and execution states are as expected, and everything is fine.  But now a problem occurs if instead I open the new project file first, double-click touchSim.vi and then run it. The same code that used to work now returns front panel state as "Closed" and execution state as "Idle" - even though the same VI is actually running, just as before. The only difference is I started it up via the project file.  I checked the LabVIEW constant "Current VI's Path" from within touchSIm.vi and in both scenarios it reads exactly the same.
 
What's the problem?
0 Kudos
Message 1 of 5
(3,653 Views)
just to clear up:
i dont expect touhslm to be a reentrant vi ?
could it be the vi (caller) looks for a different path?



-----------------------------------------------------------------------------------------------------
... And here's where I keep assorted lengths of wires...
0 Kudos
Message 2 of 5
(3,643 Views)
Where is the checking VI called from?
I think they are running in different application instances (a new feature in LV8). That seperates projects. A quick way to check this is looking in the lower left corner where you can see the current project the VIs are running in.

Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 3 of 5
(3,626 Views)
I haven't heard of these application instances before.   I checked the lower left hand corner of my touchsim.vi and it shows <project name>/My Computer.  The lower left hand corner of the calling vi shows <different project name>/My Computer.  The two VIs are maintained by two different project files.  Based on your message, I clicked the lower left hand corner of touchSim.vi and selected "Main Application Instance." Upon running the test again, now it works - the calling VI correctly detects that touchSim.vi is open and running.  I don't understand these application instances. What exactly changed when I selected "Main Application Instance" from the lower left corner? Is there a way to programmatically detect when the VI is running in a different application instance? Or a way to force the VI to be the "Main Application Instance" always?
0 Kudos
Message 4 of 5
(3,611 Views)
The problem you're having is one I ran into a while back. Each Labview project runs in its own application instance (meaning its own memory space, which other applications cannot touch or share). This occurs so that 2 projects with common VI names do not conflict with each other.
 
You can access references from another application instance using the 'Open Application Reference' VI from the Application Control panel.
 
In your case you want to connect to the Main Application Instance, which is made quite easy since it is the default for this VI. Leave 'Machine Name' and 'Port' at their default values and it assumes you wish to connect to the local computer, on the Main Application Instance port.
 
Good luck
0 Kudos
Message 5 of 5
(3,603 Views)