LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I find which VIs are actively running?

These won't give you your answer, but they might provide some more understanding of what's going on (and a chance to change it in the future):

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/More-Specific-Execution-State-of-VI-Reserved-for-Execu...

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Need-a-way-to-visualize-VI-call-chain-hierarchy/idi-p/...


___________________
Try to take over the world!
Message 11 of 36
(1,188 Views)

This is very kludgey, and it almost works (also not practical for a large # of VIs due to large delay).  Maybe someone looking at it can figure out how to make it work.

"If you weren't supposed to push it, it wouldn't be a button."
Message 12 of 36
(1,160 Views)

@paul_cardinale wrote:

This is very kludgey, and it almost works (also not practical for a large # of VIs due to large delay).  Maybe someone looking at it can figure out how to make it work.


Wow that is clunky.  And it has several issues where it may not work at all.  Say I have a sub VI call that waits 10 seconds.  Your VI won't work because 3 seconds won't be enough time to highlighted an object.

 

That being said, this is the only example I've seen that does actually work in some instances.  Congradulations on that.

0 Kudos
Message 13 of 36
(1,135 Views)

So close, yet so far.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 14 of 36
(1,100 Views)

Hah!  I think I figured out a work around.

I went through the list of VI attributes we could read and noted the following (for Metric.DataSize😞

 

New Bitmap Image.png

 

So it would seem the obvious solution would be iterate over all open VIs and, if there is an error, assume it is running !

 

New Bitmap Image.png

Message 15 of 36
(1,082 Views)

Ooh, that sounded promising, but when I did a little test, a reserved subVI also returns the error for reading this property while "running." I like the creative thinking, though. C'mon, NI, we can do this somehow!

0 Kudos
Message 16 of 36
(1,058 Views)

Hmm... perhaps I misunderstood the thread.

Do you have a VI I could use for testing?  I tried making one myself by placing a sub VI in a case which would not run (I am assuming this counts as reserved?) but in that case my code seems to work as I expected...

 

2013-07-17 16_11_12-Untitled 2 Block Diagram _.png

0 Kudos
Message 17 of 36
(1,046 Views)

Don, actually that subVI is not reserved, because you have a constant wired to the case so LV knows at compile time that the code will never run. If you wired a boolean control instead, or did not have the Case struct, your subVI would also be "running" (ie reserved) and get the property node error. If you open all the front panels, you can also see this behavior by looking at the state of the run arrows.

Message 18 of 36
(1,045 Views)

Hello, Meg!


The "actively running" state to which you are referring is an ephemeral state which, in general, changes more quickly than we can report it or you can respond to it.


In the current implementation of the LV execution system, there is a variable in the dataspace of a VI that records when the VI is actually executing on that dataspace. However, this variable is set and cleared in the thread that is executing the VI. (And its very existence is subject to optimzations we may implement.) Reading this from another thread is a snapshot of what an executing thread was doing at the moment it was read, but that snapshot can become out-of-date and incorrect at the next CPU clock cycle. So this information is, in general, highly unreliable.


The "execution state" property of a VI only identifies "running" and "running top level" because we do not want to encourage folks to assume they can determine these states reliably with any more accuracy. In fact, all of LabVIEW has to live with this inaccuracy when determining the thread safety of many of its operations. The "Metric.DataSize" property, for instance, returns errors with the exact same cautious inaccuracy.


So: in general, LabVIEW cannot provide the information you desire with the accuracy we desire. If you have a use case where the VI whose state you are curious about has a less ephemeral execution state, it is possible to devise your own state variables with your own synchronization mechanism that ensures reliability to your own satisfaction.


Rob

Message 19 of 36
(1,006 Views)

Hi Rob! Thanks for that explanation, that makes a lot of sense.

The use case is a special one : which of all my VIs is STUCK in a running state? (through my own fault)

0 Kudos
Message 20 of 36
(1,000 Views)