07-12-2013 01:35 AM
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):
07-12-2013 03:00 PM
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.
07-15-2013 08:10 AM
@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.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
07-17-2013 11:37 AM
So close, yet so far.
07-17-2013 01:17 PM
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😞
So it would seem the obvious solution would be iterate over all open VIs and, if there is an error, assume it is running !
07-17-2013 03:40 PM
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!
07-17-2013 04:14 PM
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...
07-17-2013 04:21 PM
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.
07-18-2013 11:42 AM
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
07-18-2013 11:55 AM
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)