Jump to content
TimVargo

[CR] LabVIEW Task Manager (LVTM)

Recommended Posts

Greetings! I saw you guys at NIWeek, so I rushed to work and tried grabbing this!

Curious thing, though:

When I opened the above package with VIPM, it said it couldn't find the following package:

On 7/1/2014 at 7:31 PM, TimVargo said:

lava_lib_tree_control_api >= 1.0.1-1

So I looked and looked again, then I went to Google, and it pointed me to

which gives me a .zip file.

Where do I put that to make this work?

Share this post


Link to post
Share on other sites

Thanks for pointing this out postalbyke.  I may have neglected to include that unpublished package into the LVTM package.  I will look into this later today.

Share this post


Link to post
Share on other sites

A new installer package, which now properly ensures that all dependent 3rd-party libraries get installed, has been uploaded.  Neither the version number nor build number has changed, still at v1.10.0.71.

Many thanks to postalbyke for discovering and reporting this issue, and for testing the fix.

Edited by TimVargo
  • Like 1

Share this post


Link to post
Share on other sites

"LVTM Control App.exe" isn't in Documentation. It wants the 2013 RTE. Is it an application build of the tool that can be used on a target device (that does not have LabVIEW.exe installed) to debug a LabVIEW-built application executable? If so, how can I recompile it with 2015 so I don't need to put the 2013 RTE on the device? The only .lvproj I see where the application build specification might have been is for the regression test.

Share this post


Link to post
Share on other sites

Hi dwb,

No, the LVTM Control App is not about debugging a LabVIEW-built application executable -- rather it is intended to run on your development machine, alongside of the LVTM tool.  If the LabVIEW code you are developing ever hangs up the UI of your LV development environment, the Control App will allow you to escape from that situation (which otherwise requires killing LabVIEW and loosing any unsaved changes).  The most common cause for getting into that situation is if your code calls a modal VI that was already open (you were editing it and forgot to close it before running it's caller).  Normally you could use the LVTM tool to close the front panel of any open VI; but when this frustrating circumstance occurs, the entire LabVIEW development environment UI becomes unreachable, including the LVTM tool itself -- so the Control App was created to overcome that problem.  Here is the text from the Control App's VI documentation:

This application helps close any open modal VIs that are not closeable otherwise.
Click Refresh to get all modal VIs in memory, in all application instances.
Select the VI that you want to close and click Close FP

Because the LVTM Control App is itself a built executable, you can still run that, and it will call into the LVTM tool and allow you to close any open front panel, effectively releasing the deadlock.  Because the Control App is a LV built executable, the LV Run-Time Engine (RTE) is required.  Install the 2013 RTE onto your development machine, and create yourself a shortcut to "LVTM Control App.exe".  Use your shortcut to recover from a hung LabVIEW UI the next time that happens to you!

Share this post


Link to post
Share on other sites

Thank you for explaining the purpose of the LVTM Control App. Can LVTM be used with LabVIEW built applications? Can it be compiled into an EXE for use on the target device?

Share this post


Link to post
Share on other sites

Which document describes how to get started, i.e. how to open the utility?

Share this post


Link to post
Share on other sites
19 hours ago, dwb said:

Which document describes how to get started, i.e. how to open the utility?

I just now edited the topic description to clarify this.  I will also add it to the readme file for the next release.

  • Invoke the LVTM tool from your dev environment menu: Tools > LAVA > LabVIEW Task Manager

Share this post


Link to post
Share on other sites
On 7/19/2017 at 7:02 AM, dwb said:

Can it be compiled into an EXE for use on the target device?

No.  The tool relies on much functionality that is not available in a RunTime environment, including many VI Scripting properties.  However, there is a possible solution...
 

On 7/19/2017 at 7:02 AM, dwb said:

Can LVTM be used with LabVIEW built applications?

Probably, but it would require you to first enable this from within your own built application -- a small and simple piece of code (example provided) to invoke the LVTM on a key combination of your choice.  See this post from the early days of LVTM development.  There, Ravi describes a technique of invoking LVTM from LV built executables, by using a plugin.  The download linked in that post was written for a much older version of LVTM, but you should be able to adapt it to the current version.  All of the plugin architecture is already provided, so I would think you would only need to replace a few older LVTM folders with newer versions of the same, then rebuild it.  If you do this, we would appreciate any feedback on your experience in modifying it; or maybe even post your modified plugin solution here.

Edited by TimVargo

Share this post


Link to post
Share on other sites

I'm finally getting around to installing this after seeing your NI Week presentation (which was really good BTW).

The dependencies for GPower Error and NI SmartBalloon are

  • GPower Error & Warning = 1.2.0.14
  • NI SmartBalloon = 2.0.0.2

There are more current versions of both libraries out and VIPM wants me to downgrade.  Is there are reason these dependencies are fixed or could this be modified to allow the current versions?

  

Share this post


Link to post
Share on other sites
On 7/26/2017 at 10:01 AM, EricLarsen said:

Is there are reason these dependencies are fixed or could this be modified to allow the current versions?

Eric, 

LVTM was built to support LV2013 and up (when developing toolkits, always best to provide backward compatibility as far back as possible).  Those two libraries do indeed have more current versions available, but those more recent library versions THEMSELVES do not provide backward compatibility back to LV2013.

So the answer to your question is that it depends on what version of the LV development environment you will be running LVTM under.  If you are developing in LV2013 or LV2014, then you will need to stick with GPower Error & Warning = 1.2.0.14, and NI SmartBalloon = 2.0.0.2.  If you are developing in LV2015 or higher, then you should be able to safely use the very latest versions of those two libraries without any compatibility problems.

Share this post


Link to post
Share on other sites
On 7/28/2017 at 11:43 AM, TimVargo said:

So the answer to your question is that it depends on what version of the LV development environment you will be running LVTM under.  If you are developing in LV2013 or LV2014, then you will need to stick with GPower Error & Warning = 1.2.0.14, and NI SmartBalloon = 2.0.0.2.  If you are developing in LV2015 or higher, then you should be able to safely use the very latest versions of those two libraries without any compatibility problems.

Hi Tim,

I installed your task manager on 2 of my Windows 7 Pro 32-bit systems running LabVIEW 2016.  It installed GPower at version 1.2.0.14 and NI smartBalloon at 2.0.0.2.  If I update either of the packages, your task manager package icon changes to "missing dependencies".  So I've downgrade the two support packages so your Task Manager will run.

I also tried to install task manager on a Windows 7 Pro 64-bit system running the 32-bit version of LabVIEW 2016, but I get an error that the package is not compatible with the operating system.

Aside for those areas, your Task Manager has been very, very helpful

Thank you for creating it,

Ron

Share this post


Link to post
Share on other sites
3 hours ago, sprezzaturon said:

I installed your task manager on 2 of my Windows 7 Pro 32-bit systems running LabVIEW 2016.  It installed GPower at version 1.2.0.14 and NI smartBalloon at 2.0.0.2.  If I update either of the packages, your task manager package icon changes to "missing dependencies".  So I've downgrade the two support packages so your Task Manager will run.

Hi Ron,

I haven't actually tried this, but I can see no reason why you shouldn't be able to update both packages without breaking LVTM.  Sure, the package will complain about "missing dependencies", but that shouldn't matter because by then you've already done installed it and no longer need the package.  The order in which this is done IS important however.  First install LVTM along with the older dependent packages, THEN (optionally) upgrade the GPower and SmartBalloon packages.

>> So I've downgrade the two support packages so your Task Manager will run.<<
Are you saying that after the two package upgrades LVTM wouldn't run?  In what way did it complain?

 

3 hours ago, sprezzaturon said:

I also tried to install task manager on a Windows 7 Pro 64-bit system running the 32-bit version of LabVIEW 2016, but I get an error that the package is not compatible with the operating system.

I have rechecked the package build specs, and both bitness of the OS and bitness of LabVIEW are set to allow both 32 and 64-bit -- so everything SHOULD be compatible, unless it is one of the dependent packages that is the problem (I've not tried this myself on 64-bit LabVIEW).  When you got that error, did the error message explicitly state which "package is not compatible"?

Share this post


Link to post
Share on other sites
On 10/3/2017 at 2:10 PM, TimVargo said:

Hi Ron,

I haven't actually tried this, but I can see no reason why you shouldn't be able to update both packages without breaking LVTM.  Sure, the package will complain about "missing dependencies", but that shouldn't matter because by then you've already done installed it and no longer need the package.  The order in which this is done IS important however.  First install LVTM along with the older dependent packages, THEN (optionally) upgrade the GPower and SmartBalloon packages.

>> So I've downgrade the two support packages so your Task Manager will run.<<
Are you saying that after the two package upgrades LVTM wouldn't run?  In what way did it complain?

 

I have rechecked the package build specs, and both bitness of the OS and bitness of LabVIEW are set to allow both 32 and 64-bit -- so everything SHOULD be compatible, unless it is one of the dependent packages that is the problem (I've not tried this myself on 64-bit LabVIEW).  When you got that error, did the error message explicitly state which "package is not compatible"?

I'm having the same issue on both 2016/2017. 

Labview 2017 - 32 bit

Labview 2016 - 32 bit

Win 7 - 64bit

 

I uninstalled the entire GPower toolset, uninstalled LVTM.  Rebooted.  Installed LVTM 1.10.0.71 from VIPM. 

Tested that it worked (it does).   Upgraded "GPower - Error & Warning" to 2012.0.0.31 (the next step up from 1.2.0.14 in VIPM).   LVTM is now broken.  

The GPower dependencies I see it look for are 

<vilib>:\GPower\Error\Error_ClearError.vi
<vilib>:\GPower\Error\SubVIs\Filter\Error_FilterMulti.vi
<vilib>:\GPower\Error\Error_FilterCodes.vi

 

I have software that relies on GPower Error to be up to date, so I can't avoid upgrading GPower. 

 

gpower.PNG

Share this post


Link to post
Share on other sites

I'm trying to use LVTM to debug an issue I have with, probably, stale references to asynchronous dynamically launched VIs. To stress test the problem, I open LVTM, open my project, launch what I have to launch, and then I uncleanly choose File/Close all (this project) while the whole contraption is running.

LVTM shows me then this attached unreactive almost empty tree, with an entry surviving from the aborted project. If I double-click it, I get the error dialog.

TaskManager.PNG

How can I help to debug LTVM (and my issue too?)

Share this post


Link to post
Share on other sites

An UI glitch, I realize. On the toolbar, the light bulbs icons are inverted. The left one turns highlighting on, the right one off. The tooltips are correct.

2018-08-30_12-07-31.png

Share this post


Link to post
Share on other sites

Am I missing something? Where did the drop down go for the grouping options? Why are there menu entries left in that just give an "unimplimented" popup message?

Is there an older version I can find someplace to revert to? Is the version on the CR on this site out of date?

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
      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
×
×
  • Create New...

Important Information

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