TimVargo

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"?

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.

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... 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.

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

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!

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.

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.

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.

This is a very old thread, but I am going to make this one last post here to direct anyone still monitoring this ancient discussion, to the actual support page for LabVIEW Task Manager. It is relevant to do so now, because I don't want anyone to miss out on today's announcement that this tool will be featured in a NIWeek 2017 Technical Session! Here is the announcement on the support page: https://lavag.org/topic/18322-cr-labview-task-manager/?do=findComment&comment=121847

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 ManagerType: Technical SessionWednesday, May 24Time: 4:45 PM - 5:45 PMLocation: 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!

I have my conference pass, my air travel booked, and my hotel booked. Only thing left now to complete the whole package is a LAVA BBQ ticket! I'll keep checking back here.

I too thought this new track was a success! I attended quite a few sessions in Room 15, and I thought they were great. For several previous years I was one of many to give feedback that I wanted more advanced, more technical content; and I'm glad to see that NI was listening. I encourage NI to do this again in future years. Speaking of future years, remember that starting with NIWeek 2017 the conference will be held in late May.

Just bought my ticket. I'm in, and SOOOO looking forward to it!

I am ready and eager to send money (to pay for BBQ)!

I realize that this thread is nearly two years old, but there is a new development about this. This guy (GregPayne) recently took the above mentioned .Net library and from it created a limited functionality LabVIEW library that wraps the .net assemblies. <SSH with LabVIEW>

Bought my ticket this morning (under the wire for early-bird pricing). I also invited 5 co-workers who will also be attending this year (three of them for the first time, I think) who knew nothing of this. See you there!

It's always a great time, this will be my fourth!

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.

As promised, here is an Excel spreadsheet which maps out (some of) the meanings of the different bits returned by the three VI Server properties: VI Modifications Bitset Front Panel Mods Bitset Block Diagram Mods Bitset I credit Jim Kring and Rolf Kalbermatter with doing the heavy work of discovering most of these way back in 2003 (I figured out only one all by myself ), I merely organized their findings into this spreadsheet. As pointed to by dannyt, the original information source is here. Still, only 19 out of somewhere between 81 and 128 bits have been identified, so anyone who has ever figured out more of these is encouraged to update this spreadsheet and re-post it. Besides the Code Repository for source-code, does LAVAg have a better file sharing mechanism for sharing non-code files, other than just attaching them to discussion threads? If not, do we have a preferred cloud service? I would be willing to host this spreadsheet on my personal Google Drive, if that would be helpful and appropriate. LabVIEW Mods-Bitset Mappings.xlsx

dannyt, With your help, I now have a good handle on this. >> I cannot get to grips with your idea of putting the property within the VI's you are interested in << Oh that was just a diagnostic, to see if I was calling the functions properly (since the calls from my tool were not returning expected values) -- Indeed I would not want to do it this way for real. The diagnostic was useful however, because it pointed out the flaw, and I have since resolved that problem. Yea, I too will build the bitset mapping only to the point of the elements that I need. Manually mapping out all 128 possible bits would be a monumental task. And thanks for that link; I will add to my spreadsheet the ones that Rolf figured out. If you wish to contribute, just send me the ones that you figured out and I will add those as well; and then I will attach the aggregated info (although still very incomplete) to this discussion, to possibly help others.

Thanks for the insight dannyt! I did know about the properties that you mention, but the limited help text on them led me to (falsely) believe that they provided only a binary answer. I see now that they provide much more than that, but it is totally undocumented. I have two questions to see how good your own memory is. If I place one of these properties nodes onto the block diagram of the VI to be inspected, and wire a "This VI" Generic VI Reference to that, it works fine. I of course don't want to open every VI that I wish to inspect, so I instead use the Open VI Reference function then feed that reference into the same property node; but then the output of these properties are always zeros. Do you recall how you got it to work? I will reverse-engineer the bitset mappings if I have to (it appears that there are AT LEAST 81 of them); but if you already did that, and still have even a partial list, then it would save me a lot of time if I could get a copy from you.

Does anyone know if there exists a property or method that would give me access to the same information that is within the Explain Changes dialog? I am referring to the dialog that displays when you press the "List Unsaved Changes" button, on the VI Properties dialog. The information I desire is the "VI List" of items that are marked as changed (docmod) in an entire project, along with the list of "Changes" for each of those items. The "Change details" is not important to me. I know that there are already the Modifications:*** Mods Bitset properties; but these appear to provide only a yes/no as to whether a VI is dirty or not, without the additional explanation as to WHY, which the Explain Changes dialog provides. It is that list of changes that I truly need. Ultimately, I wish to obtain a list of all VIs that are marked with "Type Definition modified", and then attempt to analyze that list for what TypeDefs they all have in common.

The source code should be in LV2010. There are no install logs generated.

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>