LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Opening vi with strictly typed static reference puts referenced vi in run-mode

I have a top-level vi that has strictrly typed static reference to another vi having x-control inside. This x-control runs special thread when it switches to run-mode and stops this thread after switching back to idle. Opening the top-level vi switches x-control to run-mode thus causing it to run this special thread so when I try to close the  project, Labview asks to stop the currently running vis. This doesn't seem to be a real problem but just leave me feeling the stuff is not very clean.

 

The strictly typed static reference is used only as a mean for future open vi reference and async call. I can replace the static reference along with "Path" property by the Path constant solving the problem. The only reason I don't do this is that I'm going to build this program as an executable so I don't know how to build a path for future vi open properly.

Static reference.png

 

Is there any way to make things clean? I don't want to have my x-control to be in run-mode just when I open top-level vi and want to be able to build an executable. If it's possible to do without static reference - it's perfect.

0 Kudos
Message 1 of 8
(3,754 Views)

This is a "feature" (that I confess I do not understand) of the Strictly Typed Reference.  Wiring a non-Strict Static Reference to a VI that has not been started gives an execution state of "Idle", but just change the Static Reference to Strictly Typed and you get Running (even if you never "run" the sub-VI).

 

I may have found a work-around.  I'm hoping the attached Snippet illustrates the point.  The Dummy Sub-VI is nothing more than a While Loop with a 5 second wait inside it, that is, "Run for 5 seconds and stop".  Key points:

  • Fake a "Strictly typed Reference" by creating a constant to hold the particular Reference Type.
  • If you want to register the Exec State when the sub-VI quits, you need to get rid of its reference.  I do this by adding a Wait on Async Call and then closing the (strict) Reference.  Now the second Exec State also returns Idle.

Bob Schor

0 Kudos
Message 2 of 8
(3,715 Views)

Oops, forgot to include the Snippet ...

Exec State Workaround.png

BS

0 Kudos
Message 3 of 8
(3,710 Views)

I also found some way to get rid of these strictly typed static references: actually their main purpose was to get path name, so now I just use path relative to current vi (not too elegant solution but works in particular cases).

Static reference.png

0 Kudos
Message 4 of 8
(3,701 Views)

Your method works in Development Mode, but will fail if you use the same code in an Executable, whereas the Static VI Reference method will work under both conditions.

 

Bob Schor

0 Kudos
Message 5 of 8
(3,662 Views)

I also read somewhere that you should use the VI Name rather than path unless you're dynamically loading a VI because VI Path always looks on disk and uses the root loop.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 6 of 8
(3,654 Views)

I tested it in both modes, it works: the reason is because vi path can be relative to .exe file (like "c:\temp\something.exe\something.vi"). So vi path gives you "c:\temp\something.exe\parent.vi", then path strip leads to "c:\temp\something.exe" and build path finally gets "c:\temp\something.exe\child.vi".

0 Kudos
Message 7 of 8
(3,649 Views)

In my previous projects I used "Name" property but I don't remember why. For this project I just got rid of these static references: I don't like my x-controls running when I don't want it (and this would result in performance issue).

0 Kudos
Message 8 of 8
(3,646 Views)