Jump to content

LabVIEW Task Manager


lvb

Recommended Posts

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

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.

  • Like 1
Link to comment

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

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
  • 10 months later...

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
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
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
  • 4 weeks later...

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,

post-9898-0-93081000-1379275220_thumb.pn

Link to comment
  • 6 months later...

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

 

post-17971-0-64649300-1395181002.png

post-17971-0-25399300-1395181016_thumb.p

post-17971-0-38144100-1395181035.png
post-17971-0-17538200-1395181295_thumb.p

 

Edited by TimVargo
Link to comment
  • 2 weeks later...

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
  • 2 weeks later...

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,

>> 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.  :wacko:  See this thread: <http://lavag.org/topic/18049-code-development-collaboration-through-bitbucket-git-and-mercurial/#entry108813>

Link to comment

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.

  • Like 1
Link to comment
  • 1 month later...

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.

post-7375-0-57752600-1399926924_thumb.pn

Get All VIs in Memory Including statically-referenced Reentrant Clones.vi

Link to comment

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  :unsure:).  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!  :thumbup1:

Link to comment

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

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
  • 1 month later...

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 by TimVargo
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.

×
×
  • Create New...

Important Information

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