Jump to content
lvb

How To Get Actual VI Execution State?

Recommended Posts

Is it possible to get the actual execution state (running/waiting to run) of a VI?

 

The Exec.State property node returns "Running" if a SubVI is waiting to run or if it is actually running.

 

post-4274-0-53136000-1363275248.png

post-4274-0-60200000-1363275258.png

Share this post


Link to post
Share on other sites

As far as I know, the answer is no.

 

Things you can do -

  1. Add special code to the VI so that it logs when it starts running.
  2. Use the Desktop Execution Trace Toolkit, which should give you the VIs which are actually running. I think that it might also be possible to tap into that data yourself somehow, but that's not public knowledge. Maybe if you know the right people at NI you could get that info.

Share this post


Link to post
Share on other sites

Things you can do -

  1. Add special code to the VI so that it logs when it starts running.
  2. Use the Desktop Execution Trace Toolkit, which should give you the VIs which are actually running. I think that it might also be possible to tap into that data yourself somehow, but that's not public knowledge. Maybe if you know the right people at NI you could get that info.

 

 

Those workarounds don't really satisfy my use case: I need to find out what VI (front panel hidden) is still running in a large application.  Often this code is written by multiple developers.

 

1. If I knew what VI was the culprit, I wouldn't need to add code because I could fix the bug.   ;)

2. Tracing often changes the run-time behavior

 

 

Things I currently do - Open the front panel of EVERY VI and look at the run button state.

 

I was hoping that I could hack some scripting to grab the front panel window, but it does not return the toolbar.  Is it possible to get an image of the entire front panel window including toolbar?

Share this post


Link to post
Share on other sites

I would suggest that you open the BD of every VI whose state is Run Top Level and then manually inspect their BDs for subVIs with the green arrow. This would at least minimize the amount of VIs you have to check (unless you open many dynamic VIs).

 

The other alternative is that if you have actual stuff going on that you do use tracing but you only enable it when you get stuck. Presumably, at this point in time it won't matter even if it does alter run-time behavior. Of course, this won't help if there's nothing actually happening for you to trace.

Share this post


Link to post
Share on other sites
I would suggest that you open the BD of every VI whose state is Run Top Level and then manually inspect their BDs for subVIs with the green arrow. This would at least minimize the amount of VIs you have to check (unless you open many dynamic VIs).

 

That seems feasible.  Time to start hacking!

 

I should probably add this to the idea exchange.  I am really surprised this is not in VI server or scripting.  Seems like a really basic and common piece of information.

Share this post


Link to post
Share on other sites
Is it possible to get the actual execution state (running/waiting to run) of a VI?

 

The Exec.State property node returns "Running" if a SubVI is waiting to run or if it is actually running.

 

attachicon.gifrunning.png

attachicon.gifwaiting to run.png

 

 

Interesting!  I just ran into this.  I was calling a vi Dynamically  and I wanted to check to see if it was running before I called it.

 

I thought I could just use Exec.State property, but that returns running, even if the SubVI is just loaded in memory and waiting to run.

 

I'm searching for an easy way to tell if a VI is actually Running.  If I cant find something soon, I'll probably just have to write code to track when the dynamically called VI starts or exits.

Share this post


Link to post
Share on other sites
I'm searching for an easy way to tell if a VI is actually Running.  If I cant find something soon, I'll probably just have to write code to track when the dynamically called VI starts or exits.

Let me save you the time.  At the moment there is no easy way to do what you want.  Well there is and it is keeping track of it the way you suggested.  I've seen some test VI somewhere, where it took a print screen of the block diagram, then did vision checking to determine if the run button was running, or reserved to be running.  That is the methods people have tried, in an attempt to do what you want programatically.  Sorry.

Share this post


Link to post
Share on other sites

GERMAN:

 

Hallo Zusammen,

 

hier einen sehr hässlichen "Würgaround" um alle "running" VIs (nicht "waiting to run") aufzuzählen, siehe Anlage (HauptVI ist das "Running_VIs_finden.vi") .

 

Grüße

Tanja

 

 

 

 

ENGLISH:

 

Hi,

 

here is a very, very ugly workaround to create a list of all "running" VIs (not "waiting to run"), see attechment (main VI is "Running_VIs_finden.vi").

 

Kind regards

Tanja

 

Running_VIs_finden.vi

Running_VIs_finden_is_running.vi

  • Like 2

Share this post


Link to post
Share on other sites

ENGLISH:

 

here is a very, very ugly workaround to create a list of all "running" VIs (not "waiting to run"), see attechment (main VI is "Running_VIs_finden.vi").

Your English isn't great, but that solution does work.  This solution looks at all VIs in memory, and then attempts to save the Run-Time Menu of the VI to a temporary file.  According to the help on this method:

 

This method works only when the VI is running.

 

So this only works on VIs running, and not reserved to be ran.  I tested it out by having a subVI in a case that is never called, and it found it wasn't running, then when I choose to go to that case it found that it was running. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.