LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Need a way to visualize VI call chain hierarchy

Problem Statement

I often find myself debugging code that seems to have "hangged" and I want to find out which VI is causing the "hang" (maybe it's waiting on some event/queue/message/timeout or maybe it's stuck in an infinite/long loop).  There's no really easy way to figure out which subVI (or perhaps a node) is not returning from its call.

 

My Work-Around

The way that I currently do this is to start opening up VIs and looking at their "Run Arrows" (the run buttons on the VI toolbar) to see which subVIs are currently "running" (being called).

 

Running (Top-Level VI)

 

Running Top Level.png

 

Running (Sub-VI of a Running Top-Level VI)

 

Running Top Level.png  << This is what I look for


Not Running (Sub-VI of a Running Top-Level VI)

 

Not Currently Being Called.png

 

This technique works OK, but it takes a lot of time to track down the running VI (in applications where there are LOTS of VIs), since you have to just start opening up all your VIs a looking at their run arrows.

 

Question: Is there any way to look at the run state of a VI using VI Server or Scripting?  Unfortunately, the VI Execution.State property is "Running" for all three states shown/illustrated above (the "Idle" state is for VIs that are not reserved for execution, meaning they are not in the hierarchy of a running top-level VI).  Maybe I'd also add to my feature request that it would be nice if there were a way to interrogate this state using VI Server or Scripting.

 

Possible Solution(s)

What would be nicer is if I could ask LabVIEW to Find all Running SubVIs/Nodes and visualize them by their VI Hierarchy.  Maybe we could have an option to show the run state in the VI Hierarchy window.  And, maybe there could be a way to only show running VIs (hide all Not Running / Idle VIs).

 

VI Hierarchy.png

 

Now, I realize that the VI hierarchy window doesn't have any way to visualize multiple subVI "instances" of a VI, but maybe that could be an option as well (Show all SubVI instances.  Also, it would be cool if we could show "Clone" instances of reentrant VIs... but, I digress.

 

Also, the VI hierarchy window only shows VIs, it doesn't show nodes/functions that might be running (and what's causing my code to "hang").  It might be nice if we could also include nodes, at least for the purpose of helping me find out which nodes are running.

 

So, I'll end by just stating that I need some easier way to figure out why my application appears to have hung and I hope that this "Idea" leads to more discussion and maybe some more features in LabVIEW to help me debug and visualize my applications.

 

Do you have any ideas for how to better debug applications that appear to have hung?  Do you have ideas for new LabVIEW features that could help?

 

Thanks!

JKI Blog
11 Comments
Active Participant

It'd be awesome to have a button in the heirachy window that highlights the running VI(s) too...





Copyright © 2004-2018 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Trusted Enthusiast

Kudos! Also, incorporate an Abort VI method for each node to kill stubborn (read, buggy) processes. Another wish is to ensure this could be opened on top of a modal.

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Member

Isn't the VI not returning the one(s) with the green arrow?

 

But I like the idea of inspection in the H window. Especially for dynamically launched VI's +1 kudos

Knight of NI Knight of NI
Knight of NI

I would also be fine if we just have an option of finding the actually running VIs and going through them. The display in the hierarchy window is nice, but might be useless (you might have performance issues in updating it and too much noise), so I would say the focus of the idea should be finding the VIs (as well as the higher resolution of states Jim mentioned).


___________________
Try to take over the world!
Active Participant

I like this idea. As Minty suggested, I do this by momentarlly turning on execution highlighting on the top level vi, and usually the stuck vi will show with a green arrow. That doesn't help with dynamically called vi's though.

 

Chris

Active Participant

I like this idea a lot. 

 

I have been using the Execution Trace Toolkit a lot more lately, but that only points you in the general direction.

 

Sometimes, I use the execution highlight to see which subVI is running and not coming back, but then if I forget to turn it off, my application runs really slow and I might think that the problem is still there. Which led  me to the following idea: Visualize which VIs have Execution Highlighting ON.

 

Fab

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Knight of NI

I could have used this idea with a current project.  Kudos for sure!

______________________________________________________________________
Active Participant LVB
Active Participant

It would be great if NI could add a VI server method that returned running VIs.

CLA, CTA
Proven Zealot

Yes please allow for a more detailed state indication than the current VI State property,

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Member mzu
Member