lvb Posted March 14, 2013 Report Share Posted March 14, 2013 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. Quote Link to comment
Yair Posted March 14, 2013 Report Share Posted March 14, 2013 As far as I know, the answer is no. Things you can do - Add special code to the VI so that it logs when it starts running. 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. Quote Link to comment
lvb Posted March 14, 2013 Author Report Share Posted March 14, 2013 Things you can do - Add special code to the VI so that it logs when it starts running. 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? Quote Link to comment
Yair Posted March 14, 2013 Report Share Posted March 14, 2013 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. Quote Link to comment
lvb Posted March 14, 2013 Author Report Share Posted March 14, 2013 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. Quote Link to comment
lvb Posted March 15, 2013 Author Report Share Posted March 15, 2013 I found a related topic on the idea exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Need-a-way-to-visualize-VI-call-chain-hierarchy/idc-p/2351162 Quote Link to comment
monzue Posted January 16, 2014 Report Share Posted January 16, 2014 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. running.png waiting 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. Quote Link to comment
hooovahh Posted January 16, 2014 Report Share Posted January 16, 2014 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. Quote Link to comment
Tanja Troescher Posted June 17, 2014 Report Share Posted June 17, 2014 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 2 Quote Link to comment
hooovahh Posted June 17, 2014 Report Share Posted June 17, 2014 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.