TimVargo

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.

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. This package uses NEITHER pre nor post-install Custom Action VIs, which should make manual installation easier when necessary. 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.

AQ: I've now read the release notes for LV2014 in full, but I see no mention of debugging-related improvements -- but then these are the extremely low-level type of changes that don't usually get a lot of publicity. Can you please share any insights into if any improvements in the debugging domain actually took place? I would love to leverage any, if they exist, into this tool.

Hey Mark! I know this is a somewhat old thread, but it still contains valuable information. In fact, your utility that you describe to pass messages out of reentrant VIs for display in a message monitor daemon, sounds very useful even now. Do you still do it this way? Recently I've been working on adding enhancements to the LabVIEW Task Manager project, and I have been considering including this very functionality within that tool. It doesn't sound too hard to write from scratch; but if by chance you've been improving and tweaking it over the years, then why reinvent the wheel? Would you be willing to donate your code to our project?

When Rolf released 2.0.0beta-7 on 8-May-2014, this was the single line comprising the release notes: "extended the time the library will be allowed to run as beta to end of August 2014" Offline, Rolf told me that much internal testing was scheduled. I hope we will see a FINAL release before end of August; or at lease a beta-8, because it is a MAJOR headache for me if this breaks.

hooovahh is correct, this package was built using VIPM 2014, and thus requires VIPM 2014 to install it. viSci: That VIPM error message is VERY POORLY worded and misleading! Also, when I upgraded to VIPM 2014 I did not have to manually uninstall 2013 first, it all went smoothly.

I have made some additional modifications and then built this excellent tool (thank you very much to all code contributors) into a VIPM package. This tool is now at version 1.7.0.28, which is the immediate successor to R6. The VIPM package is available now in the LAVAcr at <http://lavag.org/files/file/245-labview-task-manager>. It should run on LV2010 and up. ENJOY! Here is the change list for v1.7.0: Inserted "Generate Clone Name", as supplied by Aristos Queue, to fix incompatibility w/ LV2013 clone enumeration. See <https://decibel.ni.com/content/message/58984#58984> Added VI descriptions to all UI front panels, and tip-strips to UI front panel elements. Fixed bug where custom probes would cause errors in "Compare Two Paths" VI. Refreshing now includes a re-check for new app instances Optimized "Get Properties" to optionally retrieve only the properties that might have changed; yields better performance. Added some linefeed chars to the error dialog messages In project, converted self-populating folders to virtual folders, and shortened their names. In folder hierarchy, shortened some folder names, and moved some files back out to project root, instead of in "Main Task_Manager" and "Project_Task Manager"; due to some problems encountered with LV Save for Previous Version, and the VSI TSVN toolkit. Added a test case to "Parallel VIs Launcher" Added several comments to several VIs Built a VIP package for tool installation -- to be accomplished using VIPM This tool can now be invoked from LV's main "Tools" menu Eric & Neil, I did NOT include your proposed changes. If you do not merge in your own proposed changes yourselves (see below), I will do so myself at some point during my next planned code iteration; but that is likely to be a while, so I encourage you both to give it a shot. Ravi, a special invitation to you to help with a code review on Bitbucket! Please see <https://bitbucket.org/lavag/labview-task-manager/pull-request/1/labview-task-manager-v170/diff>. For anyone desiring to contribute to this project, Brian Fischer was kind enough to create a real source code repository for us on Bitbucket, enabling true source-code-control via Mercurial. I invite you to check it out at <https://bitbucket.org/lavag/labview-task-manager>.

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 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 Submitter TimVargo Submitted 07/01/2014 Category LabVIEW IDE LabVIEW Version

Neil, I agree that several optimizations probably can and should be achieved here. I've looked at your code and I will just trust that you have already verified the logic and determined that the case conversions are unneeded. Even without running any iteration testing, I concur that removing the case conversions should be just fine. I've not used Variant Attributes in this way before, so I'm not really qualified to comment on your caching algorithm; but I do notice that you have not included the logic on how to determine if the dependency's name was found in the cache or not. I invite you to clone the repository at <https://bitbucket.org/lavag/labview-task-manager>, apply your changes, then push them back up to Bitbucket (or rather make a Pull Request). Just a heads up that I too have already made modifications to this "Get All VIs in Memory ..." VI, and its parent; so if you do choose to do this, there is potential that you and I will get conflicts (and I'm not big on merging graphical code ). Just this morning I FINALLY got past a confounding problem with back-porting my changes to LV2010, so I now hope to be able to push my changes up to the Bitbucket repo by next weekend!

OK, so that clarifies the proper usage in my mind; but the wording quoted above makes it SOUND backward. I recommend clarifying that wording.

Michael, >> Has this been submitted to the code repository? << The LAVAcr seems great for publishing complete solutions, but not so much for projects that are a work-in-progress; especially if several members are all making contributions in a short period of time (see early in this thread when Ravi had to ask others to allow him to "get a lock" on his very own project, so that he could merge in some new functionality. Brian, >> Any thoughts on creating a Bitbucket repository for this project? << Yes, my thoughts are that this would be a fantastic approach. I didn't know until now that "LAVAg group on Bitbucket" existed. This sounds like a great way to provide SCC for multiple developers (contributors) to community LabVIEW projects. However, I'm confused about where the source code and build results should live. See this thread: <http://lavag.org/topic/18049-code-development-collaboration-through-bitbucket-git-and-mercurial/#entry108813>

GREAT IDEA! However, I'm confused. The rules listed at <https://bitbucket.org/lavag/about/wiki/Home> include these two: Preferably the code should be downloadable via the LAVA Code Repository Upload the build result (.VIP, .LLB or a zip) to the Files section of the repository on Bitbucket This sounds backwards to me. Shouldn't the source code reside on Bitbucket, so that Git and/or Mercurial SCC can be leveraged; and the build result placed on the LAVAcr?

Eric, I have been (very slowly) working on adding some additional functionality to LVTM, and building it into a VIPM package. If you post your changes here, I will consider merging them into the package. No need for you to backport to LV2010 first, because I will be backporting the entire project from LV2013 to 2010 anyway before I build the package.

I have edited the R6 version of LabVIEW Task Manager to fix the missing clones problem with LV2013, by calling the "Generate Clone Names.vi" provided by AQ (linked in the previous post). Before I publish the fixed project, please take a look at these screenshots, and tell me if this looks like the correct place to insert the new subVI. It does seem to work properly under LV2013, but I have not yet tested it extensively, nor yet tested with LV versions less than 2013. I at first expected the new subVI to be a drop-in replacement for an existing subVI, but no. Tim

Ten MORE months later... A question for AQ: In this very thread, at this post here, you mentioned getting some specific support added into LV 2012 (unlikely) or later, that would greatly enhance the capabilities of this LabVIEW Task Manager tool, regarding aborting of subVIs (the second of your two "sucky news" issues). Well, now that LV 2013 released last week -- did any core changes get implemented to help solve this problem? I'm liking this tool very much! There are many ways to write good code that make it easier to keep track of many tasks, but where this tool really shines is when trying to make sense of a deluge of tasks (especially asynchronous ones) spawned by inherited code!

I'll be there -- I just purchased my ticket!

Thanks Rolf, I think that I can roll this in to my next iteration. Tim

The document LuaVIEW Pre-processor keywords list several keywords which intrigue me, especially the ones such as --#version and --#description, which may be very useful for documenting scripts. However, I can find no mention of how to ACCESS these once they are assigned, or if that is even possible. I do understand that these are evaluated by the pre-processor with a main purpose of configuring LuaVIEW tasks, but --#version and --#description would certainly not be very useful for task configuration; so I am hoping that there is a way that I can grab their values and send them to a log file. If this is possible, where is the documentation on how to do it? Thanks for any help.

I spent several hours last Friday on this, and was unable to get either of loadlib or require to find the DLL in the runtime (deployed) environment. However, while re-reading the LuaVIEW manual, I (re)discovered the statically linked "lv" library, which includes bitwise functions! This solved my original problem. Although it still bugs me that I should have been able to get a dynamically linked library to work, I will hopefully not need to do so again until I am up and running with LuaVIEW v2.0, which will probably make it much easier (due to the Lua 5.1 module system). Thanks for the help though.

>> ... it didn't work properly without the compat-5.1 fix ... Ah HA! Those few words are probably the answer. I have never applied this fix. I will try this next week and let you know the outcome. THANKS! TimV

Using LuaVIEW v1.2, I require the use of an external function library (BitOp <http://bitop.luajit.org/api.html>). I have already compiled it from C into a DLL, and my intent is to call a couple of its bit-wise functions from a Lua script, which is invoked from LuaVIEW, which is of course invoked from LabVIEW. The function call is working just fine on my development machine, which has a full LabVIEW development environment (v8.5.1), the full LuaVIEW package (v1.2), and a complete installation of the Lua interpreter (v5.0). The problem is that in the deployed environment (Win XP), the very same DLL is not found by the function call. I have poured over the Lua documentation concerning the package.path, package.cpath, package.loaders, package.loadlib, etc.; and nothing I have tried has resulted in the function call being able to find this library and run. Are there elements missing from the deployed environment that prevents what I am trying to do? Has anyone else tried to use a third-party DLL function library in a deployed LuaVIEW environment, and succeeded? Any pointers would be very appreciated. TimV

Any news on how the LuaVIEW refresh is going? Still very quite at its own website.

My second time to NIWeek, my second time to LAVA BBQ! Gonna be blast!