Jump to content
mzu

Get calling node on the BD of the superVI

Recommended Posts

I am working on a tiny debugging tool. Say, we have a 2 vis, A.vi and B.vi. A.vi calls B.vi in multiple places on the BD. B.vi is being executed now. I would like to get the reference to the node on the block diagram of A.vi of a particular B.vi being executed right now (It may be paused, or just running). Same way as we  get clickable "stack trace" drop-down list on a breakpoint. How can I accomplish it?

 

A.vi BD:

post-2886-0-87864300-1369783596.png

 

1. If B.vi is reentrant, I could have used clone #. But if B.vi is not reentrant?

2. I can easily get an array of nodes of type "subVI" on A.vi BD. But the node does not have any property to show it's state (reserved, running, idle, bad etc).

3. Each VIRef of each subVI node has different numerical value. However, I was not able to find a VI property that would give me the distinction between a running VI and a reserved one.

4. I enabled supersecretprivate key in the ini file, but still no methods/properties I can use.

Share this post


Link to post
Share on other sites

Thanks, Todd, no solution there.  :( Voted up Jim's suggestion, though.

May be I can do without determining the state of the node, if I can somehow get a reference to the exact node, that called my subVI.

Edited by mzu

Share this post


Link to post
Share on other sites

mzu: There's a behind-the-scenes feature that I added a long while back for vugie that might help you here, if you don't mind turning on execution highlighting on the caller.

http://lavag.org/topic/9281-new-config-tokens-in-8-6-to-help-you-tap-into-exec-hilighting/

You could use the info about where exec highlighting has gotten to identify which nodes have already executed. Not what you're looking for, but perhaps useful?

 

You could also add a custom probe on caller diagrams for any diagram that has multiple calls to the same subVI. The custom probe could announce that it has executed. For non-reentrant subVIs, this would let you distinguish which one was executing unless they both tried to run at the exact same time (both probes would trip but you wouldn't know which one won the race for the mutex). For reentrant VIs, that wouldn't help because they could both go ahead and execute. [unless I'm wrong about the reference from a subVI node for reentrant VIs in previous paragraph, in which case the probes would solve the non-reentrant case and the reference comparison would solve the reentrant case.]

 

 

3. Each VIRef of each subVI node has different numerical value. However, I was not able to find a VI property that would give me the distinction between a running VI and a reserved one.

 

Just because you have different numbers, they all refer to the same VI. The different numbers are just independent references to the same object, no different than opening multiple references to the same named queue. I think you'll even get the same VI from a node for reentrant subVIs -- they'll all refer to the real VI from which the clones are made -- but you'll have to check my memory on that.

 

4. I enabled supersecretprivate key in the ini file, but still no methods/properties I can use.

 

I can't think of anything that will give you that information.

Share this post


Link to post
Share on other sites

AQ, Thank you for the reply,

enabling the highlighting tool is not a problem, and if nothing else works I will resort to that. If we talk probe scripting then I can script some code inside (and outside) of each of B.vi which will pass the unique ID to each of the B.vis. But those solutions look like hacks and workarounds to me.

 

What I am actually looking at is the kind of functionality that the breakpoint provides. I mean, let us modify the code for B.vi as follows:

post-2886-0-74045100-1369988130_thumb.pn

Now it will stop when B.vi is called the second time. I go to the "stack trace" menu on the top:

post-2886-0-59743600-1369988453_thumb.pn

 

and the LabVIEW highlights the exact node out of 3 B.vi nodes where the breakpoint occured: the second one:

post-2886-0-91423600-1369988626.png

 

How is it done inside of the LabVIEW, and is there any easy scripting way to get an access to this functionality?

Share this post


Link to post
Share on other sites

Mzu, this thread has not been active since a while but did you find a solution to your problem?

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.


  • Similar Content

    • By TimVargo
      View File LabVIEW Task Manager (LVTM)
      LabVIEW Task Manager v1.10.0 (for LV2013+)
      This code is Open-Source, and free of charge
      Authors: Ravi Beniwal, Tim Vargo
      LabVIEW Versions Supported:
      LabVIEW Versions Tested on:
      Dependencies:
      GPower Error & Warning = 1.2.0.14 lava_lib_tree_control_api >= 1.0.1-1 NI SmartBalloon = 2.0.0.2 OpenG Application Control Library >= 4.1.0.7 OpenG Comparison Library >= 4.0.0.3 OpenG Array Library >= 4.1.1.14 OpenG Error Library >= 4.2.0.23 OpenG File Library >= 4.0.1.22 OpenG LabVIEW Data Library >= 4.2.0.21 OpenG String Library >= 4.1.0.12 LAVA Palette >= 1.0.0.1 Description:
      LabVIEW Task Manager is a debugging tool for use during LabVIEW code development. An expandable/collapsible tree diagram displays detailed information (both static and dynamic) on all VIs in memory, belonging to a selected project/target. It allows for interacting with single or multiple selected VIs at a time, and includes the following major features:
      Selection of project/target Lists all VIs in memory, grouped by class/library or disk folder, or a flat list Searches for and enumerates clones in memory DropIn VI for including dynamically referenced clones (Clone Beacon) 'Refresh Now' (F5) re-reads all VIs in memory and adds new ones to the tree Displays VI name, owning class/library, state, path, data size & code size Displays VI FP Behavior, Reentrant?, Reentrancy Type, Paused? & Highlight? Group by Class/Library or Folder, or display a Flat List Sort by any column, ascending or descending Filter out item types vi, ctl, and vit/ctt Filter out vi.lib and global VIs Filter out items from being displayed, per folder paths. Tracking of, and ability to toggle, execution highlighting on multiple selected VIs Tracking of paused VIs with ability to Pause/Resume/TogglePause multiple selected VIs DropIn VI for pausing only while debugging If a clone initiates a pause, a different pause symbol is used for all clones of that same reentrant original VI Select multiple VIs and open or close their FPs or BDs Double Click a VI from the tree to bring the BD (first choice) or FP to front, if already open Select multiple top-level VIs and Abort them Remotely close any VI's Front Panel Installation and Instructions: 
      Install this tool by using the VI Package Manager to install its associated package file (.vip). Installation requires VIPM 2014 or higher, which is available for free from jki.net (http://jki.net/vipm). Invoke the LVTM tool from your dev environment menu: Tools > LAVA > LabVIEW Task Manager Known Issues:
      Cannot abort SubVIs launched from remote VI Server or local Asynch Call By Ref Submitter TimVargo Submitted 07/01/2014 Category LabVIEW IDE LabVIEW Version    
    • By TimVargo
      LabVIEW Task Manager v1.10.0 (for LV2013+)
      This code is Open-Source, and free of charge
      Authors: Ravi Beniwal, Tim Vargo
      LabVIEW Versions Supported:
      LabVIEW Versions Tested on:
      Dependencies:
      GPower Error & Warning = 1.2.0.14 lava_lib_tree_control_api >= 1.0.1-1 NI SmartBalloon = 2.0.0.2 OpenG Application Control Library >= 4.1.0.7 OpenG Comparison Library >= 4.0.0.3 OpenG Array Library >= 4.1.1.14 OpenG Error Library >= 4.2.0.23 OpenG File Library >= 4.0.1.22 OpenG LabVIEW Data Library >= 4.2.0.21 OpenG String Library >= 4.1.0.12 LAVA Palette >= 1.0.0.1 Description:
      LabVIEW Task Manager is a debugging tool for use during LabVIEW code development. An expandable/collapsible tree diagram displays detailed information (both static and dynamic) on all VIs in memory, belonging to a selected project/target. It allows for interacting with single or multiple selected VIs at a time, and includes the following major features:
      Selection of project/target Lists all VIs in memory, grouped by class/library or disk folder, or a flat list Searches for and enumerates clones in memory DropIn VI for including dynamically referenced clones (Clone Beacon) 'Refresh Now' (F5) re-reads all VIs in memory and adds new ones to the tree Displays VI name, owning class/library, state, path, data size & code size Displays VI FP Behavior, Reentrant?, Reentrancy Type, Paused? & Highlight? Group by Class/Library or Folder, or display a Flat List Sort by any column, ascending or descending Filter out item types vi, ctl, and vit/ctt Filter out vi.lib and global VIs Filter out items from being displayed, per folder paths. Tracking of, and ability to toggle, execution highlighting on multiple selected VIs Tracking of paused VIs with ability to Pause/Resume/TogglePause multiple selected VIs DropIn VI for pausing only while debugging If a clone initiates a pause, a different pause symbol is used for all clones of that same reentrant original VI Select multiple VIs and open or close their FPs or BDs Double Click a VI from the tree to bring the BD (first choice) or FP to front, if already open Select multiple top-level VIs and Abort them Remotely close any VI's Front Panel Installation and instructions:
      Known Issues:
      Cannot abort SubVIs launched from remote VI Server or local Asynch Call By Ref
    • By ASalcedo
      Hello to all.
      I am deploying an executable (not installer) in a target PC with the same programs (labview and toolkits) installed than the development machine.
      When I create executable I uncheck the option "enable debugging" (see image below):

      ** In the image "enable debugging" is checked but I uncheck in my application.
      Then I am trying to debug in run time and of course I can not.
      I do this to make me sure that the user can not get my block diagram.
      But now I realized that in .ini file that Labview creates with executable there are these options:
      DebugServerEnabled=False
      DebugServerWaitOnLaunch=False
       
      So if user writes "true" in these options, can they debug in real time and because of that get my block diagram?
       
      Thanks a lot!
       
       
    • By bbean
      I put together a simple xnode to relabel event registration reference wires that feed into dynamic events of event structures.  With the increasing use of event based messaging systems, I found myself manually changing the name of event registration references to clarify the event name when multiple event registration references were used in an object. I did this by manually creating a cluster constant on the build cluster before the dynamic registration terminal on the event structure and renaming each registration reference.  Being a lazy programmer, this seemed tedious after a few times so I decided to attempt to create an Xnode to accomplish the same thing faster.   This video shows the "problem" and the potential solution using the xnode: 
      Re-Label Xnode - Event Registration
      Here's another example showing another use case with ShaunR's VIM HAL Demo code:
      Re-Label Use Case ShaunR HAL Demo
      This may have been done before or there may be an easier way to do this, but I wanted to throw it out here to see if there's any interest and to see if people will try it out and give feedback.  I've found it works best using quick drop for initial use (highlight wire, CTRL-Space,type re-label, CTRL-I, type new name in dialog) and for replacing or renaming an existing instance on the diagram (highlight existing xnode, CTRL-Space, type re-label, CTRL-P, type revised name in dialog).  You can also use directly from the palette, but I found much faster from quick drop and also seen a couple crashes replacing through the pallete.  
      The Double Click ability is also a work in progress.  Its purpose is to allow you to quickly rename the relabel with the same dialog box, but when it executes it breaks the wire on the output connection.  You can still re-wire it to the event structure, but you will have to open the Event Structure Edit Events menu to get the event to "Re-link".  Something I'm trying to avoid.
      The Xnode generated code is simply a pass through wire with the output terminal renamed to the label of your choice.  This seems to update attached event structures.

      - B
      sobosoft_llc_lib_diagram_tools-1.0.4.1.vip
    • By bI0ndin
      Hi everybody,
      While I was having some time to develop new scripting stuff i wondered "would it be possible to add somme scripting stuff in the VI toolbar ? " (the one with run, run-continuously, abort, police stuff and so on). My point is to add kind of a combobox that populate with every events in the current vi for a control when clicking on it. And of course show the effective event and make it blink when selecting it in the combobox.
      The scripting part is almost done but i now come to the real problem : 
      "How can I add this piece of code in the VI toolbar ?"
      I know i can create either a Quidrop Plugin or a shortcut menu plugin but they don't fit the way i wan't to use this plugin.
      I asked some NI guy that told me the only options where the one above but I can't imagine that LabVIEW is not in some way developed around a "plugin architecture" so if any of you as plunge deep into LabVIEW's files and know where and how to achieve this goal it would be really nice
      Thank's everybody and I hope my question was clear.
×
×
  • Create New...

Important Information

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