Jump to content

[CR] LabVIEW Task Manager (LVTM)


Recommended Posts

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

LAVA Names: Ravi Beniwal, TimVargo
Contact Info: Contact via PM at the LAVA site (http://lavag.org)

LabVIEW Versions Supported:

LV2013 and up

LabVIEW Versions Tested on:

LV2017
LV2016
LV2013

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

 

Edited by TimVargo
Add instructions, how to invoke tool
Link to post
Share on other sites
  • 3 weeks later...
  • 4 weeks later...

This package won't install using VIPM 2013 Pro and LV 2013.

 

vutV7ea.png

 

"Compatible LabVIEW Versions" is 0.0.

 

The "spec" file in the VIP says Exclusive_LabVIEW_Version="LabVIEW>=10.0" though, so I'm not sure what's wrong.

Link to post
Share on other sites

This package won't install using VIPM 2013 Pro and LV 2013.

 

"Compatible LabVIEW Versions" is 0.0.

 

The "spec" file in the VIP says Exclusive_LabVIEW_Version="LabVIEW>=10.0" though, so I'm not sure what's wrong.

 

This is probably because it was built with the 2014 VI package manager.

 

You have to install the VI Package Manager 2014 to install packages built with 2014.

Edited by ShaunR
Link to post
Share on other sites

I can't upgrade to VIPM 2014 because JKI broke the VIPM API with that version and hasn't fixed it yet. I use the API in my build tools, so it's a critical feature.

 

Is there any reason the package couldn't be built using VIPM 2013 to ensure compatibility with more versions of VIPM?

Link to post
Share on other sites

Not sure if there was a reason, or it just happened to be the version of VIPM installed.  In either case a package file is a glorified zip, so you can extract it and get at the files if you can't install it.  Sure a packages does more things like it can run a Pre/Post VI, and copy files to specific locations, but if you can't open a 2014 package in VIPM you can at least look at the files by extracting it with 7-zip, or many other zip programs.

Link to post
Share on other sites

Yes, I can (and already did) manually install it. But if there's no reason to upgrade the package spec version, and upgrading leaves some users behind, then why not downgrade to accommodate me everyone? :D

Link to post
Share on other sites

Yes, I can (and already did) manually install it. But if there's no reason to upgrade the package spec version, and upgrading leaves some users behind, then why not downgrade to accommodate me everyone? :D

I agree that as long as none of the new features are being used why upgrade to 2014 for package building?  But one could argue that VIPM is free for the community and why would you not want to use the latest?  And that's where edge cases like you (and me) come in.

Link to post
Share on other sites

VIPM is free for the community and why would you not want to use the latest?

 

Yeah, too many people assume that's a rhetorical question, but it has an answer: The latest version breaks otherwise stable features.

 

And that's where edge cases like you (and me) come in.

 

If using the VIPM API in automated build tools makes me an edge case, the LV community is in a bad way. :o

Link to post
Share on other sites

But one could argue that VIPM is free for the community and why would you not want to use the latest?

 

For the same reason any sane person will only update LabVIEW when SP1 is released - project risk.

  • Like 1
Link to post
Share on other sites

...

Is there any reason the package couldn't be built using VIPM 2013 to ensure compatibility with more versions of VIPM?

 

I can no longer recall WHY I ended up building this package using the 2014 release -- I do remember making the decision to stick with VIPM v2013 unless I really had to upgrade for some reason, and yet it ended up in v2014 anyway.  I think perhaps I installed v2014 because it fixed a particular IDNet bug that had been biting me, totally unrelated to this project.  Perhaps during my next build of LVTM I will use virtualization to maintain a separate installation of VIPM 2013, just for this purpose.

 

...

Sure a packages does more things like it can run a Pre/Post VI, ...

 

This package uses NEITHER pre nor post-install Custom Action VIs, which should make manual installation easier when necessary.

 

I can't upgrade to VIPM 2014 because JKI broke the VIPM API with that version and hasn't fixed it yet.

 

Stobber, have you been watching the beta releases of VIPM 2014, to see if perhaps they might have already fixed your problem?

<http://support.jki.net/entries/24071293-VIPM-Labs>

I myself reported a bug in v2014 (which I discovered during the building of LVTM) which they did fix and publish a few weeks later.

Link to post
Share on other sites
  • 5 months later...

This package isn't working for me.  It doesn't show up int he Tools menu after installation and even opening the lvproj in the vi.lib folder doesn't find components it needs because it's expecting items to be in a subdirectory when they have actually been renamed.

 

I'm using LV 2012 SP1 (32-bit) on Win7 Pro 64-bit.

 

As an example, it's looking for a Class

C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\LAVA\LabVIEW Task Manager\Test VIs_LVTM\Test Class\Test Class.lvclass

 

but I can only find

 

C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\LAVA\LabVIEW Task Manager\Test Class__LAVA_lib_LVTM.lvclass


I have VIPM 2014 installed.....

Link to post
Share on other sites

Shoneill,

I have been looking at it, just no answers yet.  I can see why the project file might be expecting different filenames -- I have the Package Builder automatically renaming all files to append "__LAVA_lib_LVTM" for namespacing purposes.  I thought that this would have "updated" the lvproj file with the new filenames as well, but I guess not.  But even still, I have yet to figure out why this should cause problems with simply running the tool (which has no need for the lvproj file).  Any chance that this problem is local to just your own installation?  Because no one else has reported having this problem.

Link to post
Share on other sites

shoneill,

When VIPM completed your package installation, did it report success or failure?

When I created this package, I had not yet read that tools from LAVAg should should properly be invoked using a menu path such as Tools>>LAVA>>LabVIEWTaskManager; so I used the improper menu path Tools>>LabVIEWTaskManager. If you are looking for it in the proper place where it SHOULD be, please look for it one menu level higher.

I realize now that the package to INSTALL this tool should not have even included the lvproj file and a few other files relevant only for development. I will remove those from any future package builds. If you wish to download the development project, which will include a file structure at the paths where the lvproj file expects the VIs to be at, you can find that on Bitbucket at this link:

<https://bitbucket.org/lavag/labview-task-manager>

Link to post
Share on other sites

Hrm.  Code is saved in a newer version than I currently have access to.  I'm assuming it's LV 2014, but I only have 2012 installed....  Looks like I need to power up a VM.

 

That won't be happening today, but I WILL look at it when I have time.  Thanks.

Link to post
Share on other sites
  • 3 weeks later...

I have only just now had some time to look into this.  Apparently, I owe an apology.  I advertised this tool to work with LV2010 and up, because I thought I had back-saved the source code to LV2010, AND had then built the VI package (.vip) from that LV2010 source.  Evidently both the source code on Bitbucket and the .vip tool installer are in LV2013 (which is where I did the majority of development).

 

So by mistake, LVTM v1.7.0 is supported only on LabVIEW versions 2013 and up.  I do have plans to add many more features to LVTM, and I will pay closer attention to the back-save next time around; but I've not found the time to work on this much lately.  If anyone is DESPERATE that the tool supports LV versions between 2010 and 2012, just holler and I will see what I can do to possibly accelerate the next build.

Link to post
Share on other sites
  • 2 years later...

It has been over two and a half years since version 1.7.0 of this tool was released, and today Ravi and I have an exciting announcement to make.  The two of us will be presenting a technical session, Advanced Debugging With LabVIEW Task Manager, at NIWeek 2017!  For those of you planning to attend NIWeek 2017, 22-25/May (yes, NI has moved it up 10 weeks earlier), please be sure to add our presentation to your session schedule -- we'd love to see you in our audience!  Here are the details:  

Session Title: 0195 - Advanced Debugging With LabVIEW Task Manager
Type: Technical Session
Wednesday, May 24
Time: 4:45 PM - 5:45 PM
Location: 19B
Abstract: 
Discover both the merits and limitations of LabVIEW debugging tools, explore which situations impede troubleshooting, and view a live demonstration of the free, open-source, and community-developed LabVIEW Task Manager, which delivers new comprehensions into your running code, plus ways to dynamically interact with individual or groups of VIs.

To commemorate this speaking opportunity, Ravi and I are working hard to release an updated version of the tool, including several modest improvements, to the LabVIEW Tools Network.  It is our goal to complete this release prior to NIWeek 2017.  Here is a sneak peak into the future:  What's New in LVTM v1.10.txt

Hope to see you in Austin in May!

  • Like 1
Link to post
Share on other sites
  • 1 month later...

LabVIEW Task Manager (LVTM) v2013.1.10.0 has finally arrived!!!

You can download this new version using the "View File" button at the top of this page.  Of all the new features added to this version, my favorite isn't a feature at all; it's how much FASTER it now is than before, and with much smoother scrolling through the tree too!  In a post above I said that the new version would contain "several modest improvements"; but I said that after I had added those improvements myself, before Ravi had added his own.  Wow, his additions boosted the improvements from modest to nothing short of amazing!  But don't take my word for it, see it for yourself!

Hope you find it as useful as Ravi and I do.

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
      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 Tripmeister
      Hi everyone,
      I would like to program some little extra functionality to the Blockdiagram Editor. In detail I want to write a tool, that allows me to drag a node over a wire and then automatically inserts it to the wire if it fits (e.g. drag a subVI into an error-wire). I guess I know/can figure out how to write that functionality using VI scripting, but I'm not sure how to implement it to run whenever I edit a VI.
      My first approach is to write a simple scripting-VI, that I will run whenever I need the functionality (or just place the exe in autostart). This VI will obtain the reference to the currently active blockdiagram and then uses scripting to move the node into the wire, whenever I drag a node.
      But this seems very inefficient, though I know that controlling a drag-operation via VI-Server is inefficient anyway.
       
      My basic question is:
      Is there a way in LabVIEW to implement LabVIEW-Written functionality to the whole editor?
       
      So I don't want to activate anything via Right-Click- or Quickdrop-Plugins. It should be a background VI running constantly, or maybe a solution using internal LabVIEW-Events such as starting a drag-operation on the blockdiagram.
      It would be great, if anyone can give me hints or maybe even examples for how to solve this. I would be happy about any different ways on implementing the functionality from my first sentence, but basically its not about the functionality itself and more about curiosity on if there is a way to solve it all using LabVIEW. Maybe I want to write different tools as well then.
       
      Thanks for any replies in advance!!
      Best,
      Jan
    • By dterry
      Hello All, 
       
      Long time reader, first time poster.  I have learned a lot from lavag, and really appreciate what you all do here.  
       
      I am building an LVOOP architecture that sort of straddles the line between AMC and AF.  One of the most frustrating things I have run across (as with most AF type architectures) is debugging shared clones.  I've run into some behavior that I did not expect and wanted to see if anyone knew what was going on.  First some definitions:
      Behavior A: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the original, "uncloned" VI, reserved for execution. Behavior B: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the active, running clone VI, which is capable of being debugged. I once thought that behavior A was how LabVIEW worked, however in developing this framework, I have found that some subVIs show behavior B.  Behavior A and B seem to correlate to dynamic and static dispatch methods respectively, but I can't make sense of why.  If I create a simple example without OOP (see attached), I get behavior A.
       
      Has anyone ever seen this behavior, and if so, am I missing something really obvious?
       
      Secondly, does anyone have any tricks or best practices for getting into active clones to debug?  My only idea at this point is to include some sort of notifier/queue/etc to active a Front Panel Open Method.
       
      Thanks in advance!
       
      Drew T.
      CLA, CTA
    • By FJ_Sanchez
      Hello,
       
      I'm developing an application that uses some PCIe hardware. My daily developing computer is a laptop docked to a dock station. Now, I would like to develop testing my subVIs in the remote desktop that has installed the PCIe hardware. I know I can enable remote debugging, compile and transfer the executable, then execute and connect from my laptop, but this is very inefficient and slow process to test subVIs.
       
      I could install the full development environment in the remote desktop, develop in this machine with remote connection (or even directly on this computer, as it's next to my laptop), but this is not the way I would like to work with every similar project.
       
      Do you have any better approach to debug remote desktop applications? I have heard something about using VI server and executing remote panels or similar, but I have never done such a thing.
       
      Any comment is welcomed.
      Thank you.
×
×
  • Create New...

Important Information

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