hilbert00 Posted October 5, 2012 Report Share Posted October 5, 2012 Dear all! It's my first post here, so first of all, thanks everybody for this nice community. I'm trying to do something that is identical to what Ravi did almost one year ago, so I will probably reuse as much as possible from his code. What I don't understand is: why the LV Task Manager doens't list compiled VIs? My final project will be made by a few deamons, all of those possibly compiled and I would like to see a list of all the running ones using the task manager. Is it something doable? thanks for any help! cheers, Link to comment
asbo Posted October 5, 2012 Report Share Posted October 5, 2012 I'm trying to do something that is identical to what Ravi did almost one year ago, so I will probably reuse as much as possible from his code. What I don't understand is: why the LV Task Manager doens't list compiled VIs? Compiled VIs? "Compiled" does not apply to VIs in the conventional sense; everytime you make a change, the IDE is compiling. I think you mean in a built executable - the reason these don't show up is because they're in the Run-Time Engine, and a separate application instance to boot, which is separate from the development IDE. 1 Link to comment
hilbert00 Posted October 6, 2012 Report Share Posted October 6, 2012 Compiled VIs? "Compiled" does not apply to VIs in the conventional sense; everytime you make a change, the IDE is compiling. I think you mean in a built executable - the reason these don't show up is because they're in the Run-Time Engine, and a separate application instance to boot, which is separate from the development IDE. Thanks asbo! Exactly, I meant the result of the executable built. When I launch the Task Manager I can only select the "Default Application Instance". Is there a way to add the Run Time Engine as well? I know I maybe asking stupid question, so is there any tutorial to better understand this topic? Thanks again, Link to comment
Popular Post Ravi Beniwal Posted October 7, 2012 Popular Post Report Share Posted October 7, 2012 I have created a plugin for the Task Manager that can be used from inside an executable, thanks to Michael and his guide to Plug-in Architecture using Packed Project Libraries. If you aren't familiar with PPLs, I'd highly recommend at least a quick glance through this guide. LabVIEW Task Manager Application.zip I took Mike's example and created a plugin that launches the task manager. You can add it to your application as an Easter Egg (set it to load on some secret key combination). You don't have to distribute this plugin with your application, but if you are called to debug something on a deployed system, you can just take this plugin, drop it at the designated place (same as the exe in this example) and enter the key combination to launch it from within the application. To see this in action, launch ..\LabVIEW Task Manager Application\build\testApp.exe. If "LabVIEW Task Manager.lvlibp" exists in the same folder as the exe, your key combination will bring it up. 5 Link to comment
hilbert00 Posted October 12, 2012 Report Share Posted October 12, 2012 I have created a plugin for the Task Manager that can be used from inside an executable, thanks to Michael and his guide to Plug-in Architecture using Packed Project Libraries. If you aren't familiar with PPLs, I'd highly recommend at least a quick glance through this guide. LabVIEW Task Manager Application.zip I took Mike's example and created a plugin that launches the task manager. You can add it to your application as an Easter Egg (set it to load on some secret key combination). You don't have to distribute this plugin with your application, but if you are called to debug something on a deployed system, you can just take this plugin, drop it at the designated place (same as the exe in this example) and enter the key combination to launch it from within the application. To see this in action, launch ..\LabVIEW Task Manager Application\build\testApp.exe. If "LabVIEW Task Manager.lvlibp" exists in the same folder as the exe, your key combination will bring it up. is it possible to have a version saved as LabVIEW 2010? thanks! Link to comment
TimVargo Posted August 16, 2013 Report Share Posted August 16, 2013 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! Link to comment
Aristos Queue Posted August 22, 2013 Report Share Posted August 22, 2013 did any core changes get implemented to help solve this problem? No. I'm not working on LV myself at this point, so my traditional "let me just slip this small tweak in to help LAVA conversation" fixes aren't there this round. Instead I have to convince others to work on it. But there is good news... the plan -- and let me stress plan -- is to work on several debugging-related improvements for 2014, and I'm asking that some work be done to make this task manager work better. No promises, but I am making the request. Thanks asbo! Exactly, I meant the result of the executable built. hilbert00: I missed your question when you first posted it. EXEs are closed boxes with no way to open VI references into an EXE from outside the EXE. So far as I know, there's no way around that. You can compile your EXE with the option to allow remote debugging and then attach the development environment to your running EXE. I haven't tried it... that *might* allow you to open references to the VIs in the EXE. You'd have to test it. When I launch the Task Manager I can only select the "Default Application Instance". If you open projects, each project is a separate application instance. If you're a programmer in other programming environments, the terminology may sound foreign since it is all within a single LabVIEW.exe. It lists all the application instances available within the current LabVIEW. This is why I think the remote debugging idea might work -- a new local application instance is created to debug the remote EXE. Link to comment
lvb Posted August 22, 2013 Author Report Share Posted August 22, 2013 But there is good news... the plan -- and let me stress plan -- is to work on several debugging-related improvements for 2014, and I'm asking that some work be done to make this task manager work better. No promises, but I am making the request. Please, please add a VI server call that properly reports which VI's are running! (See thread here) Link to comment
Aristos Queue Posted August 22, 2013 Report Share Posted August 22, 2013 Please, please add a VI server call that properly reports which VI's are running! (See thread here) Probably won't happen, but I'll mention it. There's a long list already. We did a lot of pruning with customer groups at NIWeek and with some customer education groups over the last year or so. Link to comment
SJ_Buddy Posted September 15, 2013 Report Share Posted September 15, 2013 Hello Ravi Beniwal and Aristos Queue, Have you had a chance to test LabVIEW Task Manager in LV2013. I have been successfully using your VI on LV2012 (Thank you sooooooo much for great work). But I have upgraded to LV2013, and now I cannot see clone VIs any more. It is really killing us if we cannot see the clone. Could you take a look. Best Regards, Link to comment
Ravi Beniwal Posted September 17, 2013 Report Share Posted September 17, 2013 Hi SJ_Buddy, I haven't done anything in 2013 yet. I will try to upgrade it over the next few days. Link to comment
drjdpowell Posted September 17, 2013 Report Share Posted September 17, 2013 Check this conversation for info on the 2013 changes, and a subVI that can be used to fix the problem. Link to comment
TimVargo Posted March 18, 2014 Report Share Posted March 18, 2014 (edited) 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 Edited March 18, 2014 by TimVargo Link to comment
xceric Posted March 28, 2014 Report Share Posted March 28, 2014 Ravi, this is a great tool. It would be great to see all the Open VI Ref nodes have option 0x20 to suppress the loading dialog. I mainly had a problem with the one in Add VIs and their properties to tree.vi and the first one in Fine Clones.vi, although it probably wouldn't hurt to have for all nodes. A broken VI in one of my classes kept bugging me. That VI also happened to be a .vit, which threw an error in the path compare in Add VIs... since the template was opened as a new instance, which did not have a path. It would be useful to also have 0x02 on that open as well as the first one in Find Clones.vi (but not the one in the for loop). I have not had time to investigate why the .vit still shows up in the list even when .vit files are being ignored. I have made the changes in 2012. I can redo in 2010 and post the changes if you would like. Thanks for your work on this Eric Link to comment
TimVargo Posted April 5, 2014 Report Share Posted April 5, 2014 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. Link to comment
Michael Aivaliotis Posted April 7, 2014 Report Share Posted April 7, 2014 Haven't been on LAVA in a while and noticed this thread. Has this been submitted to the code repository? Link to comment
lvb Posted April 7, 2014 Author Report Share Posted April 7, 2014 Any thoughts on creating a Bitbucket repository for this project? http://lavag.org/topic/18049-code-development-collaboration-through-bitbucket-git-and-mercurial/ Link to comment
TimVargo Posted April 8, 2014 Report Share Posted April 8, 2014 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> Link to comment
lvb Posted April 12, 2014 Author Report Share Posted April 12, 2014 After checking with Ravi, I have created a Bitbucket repository: https://bitbucket.org/lavag/labview-task-manager The project contains the following Wiki for details on the task manager Commits for all of the versions with release notes (R1 - R6) Issues known to date Please join the lavag group on Bitbucket to contribute! I welcome your comments and suggestions for the Bitbucket project. 1 Link to comment
Neil Pate Posted May 12, 2014 Report Share Posted May 12, 2014 Hi all, If I get time I would like to refactor "Get All VIs in Memory.." that and its parent VI to remove a lot of the duplicate operations and array manipulations. For now though an easy performance boost is to cache the VI Dependencies. I have used variant attributes as a quick and dirty cache, as shown. I get approx 50% speedup for large projects (> 2500 VIs). With a bit of thought I am sure it can also be applied to the other temporary arrays that are used in this VI. Comments? The VI attached is saved in 2013. Get All VIs in Memory Including statically-referenced Reentrant Clones.vi Link to comment
TimVargo Posted May 19, 2014 Report Share Posted May 19, 2014 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! Link to comment
Neil Pate Posted May 20, 2014 Report Share Posted May 20, 2014 Hi Tim, I have already cloned the repository, I just wanted to be polite before pushing back my changes. There is actually logic checking the dependency cache, its just before the case structure. If the attribute lookup is not found then it is added, this is how items get in the cache. At the moment I am totally snowed in with work, so I do not think I will get time for several weeks (probably longer) to tinker with this anymore. Unfortunately for the project I was going to use it in has several thousand VIs and performance with this is just a bit too slow, so I ended up writing my own for my particular use case. I am most interested in being able to interact with clone VIs, so I used the FGV method and add the VI names to a cache when they are launched. This works really very well for my application, so is probably about as far as I need to take it for now. Link to comment
Neil Pate Posted May 20, 2014 Report Share Posted May 20, 2014 Tim, Sorry I have just looked at the screenshot I posted, there is a bug in that the case structure downstream of my variant cache lookup has a False constant wired to it. This was for testing purposes when I was comparing the speed and correctness of the new algorithm. This constant should actually be replaced with the output from the variant attribute lookup. Neil Link to comment
TimVargo Posted July 2, 2014 Report Share Posted July 2, 2014 (edited) 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>. Edited July 2, 2014 by TimVargo Link to comment
viSci Posted July 3, 2014 Report Share Posted July 3, 2014 The latest task manager vip did not load on vipm 2013. I have LV2013 and 2010 on my machine Link to comment
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now