Determine which vi is executing at runtime and read its block diagram

[jfron]

I have a time-critical loop.  Within this loop, one of a set of known VI's is chosen in a case statement.  Within each of those VI's, data is decoded in a specific way.  I cannot modify these VI's to make the information I need available, because it would increase the amount of execution time of the tight loop.

What I need to do is write a new VI which will "read" the components of the block diagram, so I can determine dynamically what code is being run.  For example, if there are three blocks in the running VI that extract an array element, I need to be able to determine the index of the array elements being extracted.

I could re-encode all of this information in a new VI, but that would generate a maintenance headache, because the decoding algorithms would have to be kept identical for every incremental change.

Is it possible to "read" the contents of a VI from another VI without reverse-engineering the VI file binary format?

[Dennis_Knutson]

You can determine whether a VI is running with the VI property Execution:State and you can read the value of an indicator with the VI method Get Control Value. Afaik, there is no way to get the value of a "wire" from another VI.

[jfron]

Thank you.  I don't need to get the value on a "wire" in another VI.  I'd like to be able to list what "blocks" a VI contains.

The "C" analogy would be this:

    Getting the value on a "wire" at runtime would be akin to running on a debugger,
    stopping execution, and checking the value of a local variable.

I don't need to do this.

What I need to do, in C, would be to:

     "fopen" the source code for reading
    gets() line-by-line, looking for specific function calls -- say calls to ExtractElementFromArray()
    parse out the the parameters of that function call

So that I could, in effect, determine which elements of an array, by location and length, were being accessed.

It doesn't sound like the VI API allows you access to anything other than what is connected to the front panel, so, short of being able to parse the VI binary file format, I don't think what I want to do is possible.

[Dennis_Knutson]

Well, that's what I meant by reading the value of a wire. Like placing a probe somewhere and watching the value as the VI runs. Can you place indicators on the inputs of the Index Array (there is no such function as ExtractElementFromArray()). If there are only a limited number of functions that you would need to monitor, this seems like a reasonable approach. I don't see how parsing the binary file format will help. It sounds like you want to directly access the memory locations as a VI runs.

[Underflow]

Warning:  Using the information in this post can cause your LabVIEW program to behave erratically, and is NOT supported by NI.

I'm definitely not an expert in the area, but there is a way to take a programatic gander at the source code of a VI.  Check out the LabVIEW Scripting forum at the LAVA forums:

http://forums.lavausergroup.org/index.php?showforum=29

(it seems to be down at the moment, hopefully it will be available later).

Scripting lets you do things like get a reference to the block diagram, and perform some programatic manipulations on code.  It isn't easy, but it might just be what you want to do.

Joe Z.

[jfron]

Actually, no.  I'm probably not being very clear.  I'm not interested in looking at the values within the VI, I want to be able to see what the VI is doing.  I don't want to see the result of ExtractDataFromArray() (which I know is not a real function -- it was just an example), that is, I DON'T want to see the values on a "wire" during execution.

Rather, I want to know how many instances of a certain kind of sub-VI are in a VI, I want to know how many instances of constants there are, and which sub-VI's they are wired to.

I want to be able to find this information, essentially:
    In FOO.VI:
       bar.vi is called seven times, each time, the INPUT1 is wired to terminal 1,
        and for the 7 various instances, the values "1," "3," "12," "17," "23," "35," and "71" are wired to terminal 2.

In C-speak, I don't want to know the result of the calls to the imaginary function ExtractDataFromArray(),
rather, I want to know that it was called seven times, with the arguments (&input1, 1), (&input1, 3), (&input1, 12), ...
And I don't care what was in &input1 when it was called, just THAT it was called.

Essentially, I want to be able to have one VI analyze another and determine what it does.

[jfron]

> http://forums.lavausergroup.org/index.php?showforum=29

The database is down, but your description sounds more like what I'm after.  Thanks for the link!

[Dennis_Knutson]

I think I understand now. Some of this information might be available with LabVIEW scripting. There is a whole forum dedicated to this at LAVA (http://forums.lavausergroup.org/). There is also the VI Analyzer toolkit that does some of this so I think that most of what you're asking is possible. And, who knows what the next couple of months or two will bring.

[Underflow]

Dennis said:

"And, who knows what the next couple of months or two will bring."

Hrm, I really need to work harder on contributing.  Maybe I can get in the next beta!

[JeanPierre]

Well I think you can't both have a time critical execution and intrusive debugging tools.

Try Operate > Log at Completion, setting a file name in Operate>Datalogging>Log...
The state of the front panel will be logged on file after each run of the VI. If you read the caller name on the call chain and write it to an indicator, you'll have all the information you  need retrieving the logs. However, don't expect fast operation...