LabVIEW
How to check run-state of the VI?
Shortly the task: check if there are running clones of a particular VI.
There is a function that I run under some conditions via a link. And it should close itself under other conditions.
I want to check if it works correctly. And to do this, among other things, I need to check for the presence of running clones.
I have made a function:
By design, it takes all vi in memory and checks if the VI I'm interested in is not among them.
The strange thing is that when I run the test, the function under test is already in the running state:
There's a class (Actor) on top, whose method starts this function by ref.
And this is how it works (no clones in run-state):
It turns out that if there is a reference to a class in the code, its members are already in run-state
Question: how to check that clones are not running?
In general (not considering AF that might have options for this) checking if\which clones exist (or running) is not easy.
The reason is that officially, VI Server references to clones are not supported by LabVIEW.
Official support is 20 years overdue, but it is what it is...
What exactly do you need to know? If there are clones, how many clones, the names of the clones, references to the clones..? Do you need to know this from your code or would a function in the IDE do?
There are (tricky) things you can add to your code to get this information, but I suppose you want to avoid this?
There are hacks to get clone names and\or references too, but nothing from NI that I know of.
Search LabVIEW like a graph! Hi wiebe, thanks for the answer.
The test function is run dynamically to monitor events. When one of them occurs, the function should terminate.
I want to automate the test and planned to do the following sequence
- check if there are no working instances
- call the function
- check that there is a working clone.
- simulate the event
- check that the clone has terminated (again no working instances)
In general, it's enough for me to know that the number varies like this: 0-1-0.
But I'll be satisfied with any other approach that allows me to automatically perform the testing.
If you refer to the VI by it's path, name or static VI reference, it's quite easy.
If you use a static strict VI reference this won't work.
The normal VI will be un-editable if clones are running. So starting an transaction will succeed if the VI is editable, it will fail if not:
So in this (butt ugly) example:
...the error is False, becomes True after 5 sec. and False again 5 sec. later.
It tests 0 or N running open clone references... But it's tricky, because open clone front panels don't block the editing, a VI reference explicitly opened does.
Of course, the TL;DR solution is this hack 😁:
Getting references from these numbers requires another hack, but you don't seem to need that atm...
wiebe@CARYA wrote:Of course, the TL;DR solution is this hack 😁:
Getting references from these numbers requires another hack, but you don't seem to need that atm...
I'd appreciate it if you could drop a snippet for that another hack here as well (for my hacks collection), please. I might need it for my plugin architecture, maybe...
@Andrey_Dmitriev wrote:
I'd appreciate it if you could drop a snippet for that another hack here as well (for my hacks collection), please. I might need it for my plugin architecture, maybe...
Sure.
Note that the hash is based on (just) the VI name, so you don't need to recalculate the hash for each clone number.
Here I calculate the hash only ones iff there is more then 1 reference. The first number seems to be always 0, which isn't a clone but the original. Didn't study that much, YMMV (as always with scripting\hacking 😉).
Hi wiebe@CARYA and thank you for your code.
Last days I made some experiments and here is strange result. I'll attach the project also.
I have a method which runs vi by reference.
And here is simple test. If vi is "disabled" test is pass
But as soon as I set it "enable", the test is fail
Furthermore, I've refined the code so that the VI doesn't actually run, but the system is still convinced that the function is running.
@Artem.SPb wrote:
And here is simple test. If vi is "disabled" test is pass
But as soon as I set it "enable", the test is fail
This is probably caused by an optimization LV has called dead code elimination, where LV ignores code that it can see will not be executed. Note that this only seems to happen with dynamic dispatch VIs, where the actual VI which will be called is not decided until run-time. With a standard VI, it will still be reserved for running (although I believe it will not be included when building an EXE if this is the only call to the VI).
@Artem.SPb wrote:
Furthermore, I've refined the code so that the VI doesn't actually run, but the system is still convinced that the function is running.
Note that LV treats VIs which are waiting to run and VIs which are actually running the same in this context. In the Exec.State property this looks like this:
| Running—VI is reserved for execution by one or more active top-level VIs. |
Here it only says reserved, but it will also be the case if it's actually running. In this case, I believe the strict reference to the VI is what causes it to be statically loaded and reserved, but I haven't looked at it recently. You can check by creating a constant from the reference and then making the reference not strict.
