LabVIEW Task Manager

[lvb]

Are there any existing task managers specific to LabVIEW? I am looking for a task manager that is capable of:

• Listing running VIs along with memory usage and refnum
• Aborting a running VI
• Showing or hiding a block diagram or front panel

I have searched on google and the NI forums with no luck.

 

Update:

Bitbucket Repository - https://bitbucket.org/lavag/labview-task-manager

Code Repository Page - http://lavag.org/files/file/245-labview-task-manager/

[asbo]

I haven't seen any completed solutions, but I know that I posted a small utility that handles opening the block diagram of VIs.

[John Lokanis]

You can always write your own. Most of what you want is available via VI Server.

[jcarmody]

My Abort.vi does some of what you mention:

Are there any existing task managers specific to LabVIEW? I am looking for a task manager that is capable of:

• Listing running VIs along with memory usage and refnum not sure how difficult this would be to add
  
• Aborting a running VI
  
• Showing or hiding a block diagram or front panel this feels like it might be easy
  

I have searched on google and the NI forums with no luck.

[asbo]

My Abort.vi does some of what you mention:

Between your VI and my BDWin.Open.vi he's got a good bit of legwork done for him.

[lvb]

Thanks for the replies, I am aware of how to obtain this information using VI server. I just find it odd this tool does not exist.

Sounds like something I will have to develop and submit to the LAVA code repository. So this thread has now become suggestions on developing a VI Task Manager tool....

Please reply with your ideas!

Edited September 14, 2011 by brianafischer

[asbo]

Your list so far is a solid start. The only additional function think of offhand is to work across projects/application instances, but I haven't messed with VI server enough to know if that's even feasible. I'll think about it some more and see if I can come up with some other good features.

[Ton Plomp]

One feature request is a drop-down VI, that sends a message to the taskmessenger, with info about the owning VI and perhaps a custom string, so we can track start-stop and runtime

Ton

[jgcode]

I would like to see a tool/exe like this developed.

[lvb]

One feature request is a drop-down VI, that sends a message to the taskmessenger, with info about the owning VI and perhaps a custom string, so we can track start-stop and runtime

Ton

Ton, are you asking for the LabVIEW Task Manager to provide a "pipe" for User Defined Trace events? This is already a feature of the LabVIEW Desktop Execution Trace Toolkit that is now included with LabVIEW 2011 Professional:

[Ton Plomp]

That is exactly what I'm asking. If you have a task manager, it would be nice to have a 'last event' status of the VI.

Ton

[asbo]

Ton, are you asking for the LabVIEW Task Manager to provide a "pipe" for User Defined Trace events? This is already a feature of the LabVIEW Desktop Execution Trace Toolkit that is now included with LabVIEW 2011 Professional:

Does that mean in order to use the (proposed) task manager, you'd have to install the DETT?

[lvb]

Does that mean in order to use the (proposed) task manager, you'd have to install the DETT?

No, I was suggesting that functionality already exists in another product. I don't think the DETT has an API, so I am not sure how it could be a dependency.

[jgcode]

No, I was suggesting that functionality already exists in another product. I don't think the DETT has an API, so I am not sure how it could be a dependency.

Yes, it has prims you can drop onto your VIs from the palette (once you install the toolkit of course).

[lvb]

Yes, it has prims you can drop onto your VIs from the palette (once you install the toolkit of course).

I have the DETT installed on my system and only see the "Generate User-Defined Trace Event" under the palette "Desktop Execution Trace Toolkit" menu. I don't see any other VIs or an API that will allow for interaction with the DETT. Where are these other prims you are referring to located?

Edited September 17, 2011 by brianafischer

[jgcode]

I have the DETT installed on my system and only see the "Generate User-Defined Trace Event" under the palette "Desktop Execution Trace Toolkit" menu. I don't see any other VIs or an API that will allow for interaction with the DETT. Where are these other prims you are referring to located?

No, that is what I was referring to. Apologies.

[SteveChandler]

Ton, are you asking for the LabVIEW Task Manager to provide a "pipe" for User Defined Trace events? This is already a feature of the LabVIEW Desktop Execution Trace Toolkit that is now included with LabVIEW 2011 Professional:

Wait. Are you saying the DETT software that I just bought for LV2010 is now included with LV2011?

[asbo]

No, I was suggesting that functionality already exists in another product. I don't think the DETT has an API, so I am not sure how it could be a dependency.

Ah, okay, I like the idea, but there should obviously be an OpenG implementation of that trace event so that everyone can use it.

[Ravi Beniwal]

I had created a task manager a while ago to address precisely these issues. I'm attaching the LabVIEW 2009 code for it. Please feel free to take this as the starting point and expand it further. I'd also love to work on this one more.

Currently it:

• Lists all VIs in memory
  
• Displays basic information like VI state, path, data size, code size, FP Behavior, Reentrant? Reentrance Type, etc.
  
• Let's you select multiple VIs and open FP or BD
  
• Let's you select multiple VIs and Abort
  
• let's you select a refresh rate and updates the lsit
  
• sort by any column
  
• let's you filter file types like vi, vit, and ctl
  

What other functionality would you like to see in it?

• select application instance?
  

Should this be submitted to the repository or should we keep attaching versions to this discussion?

Cheers!

LabVIEW Task Manager.zip

[Jordan Kuehn]

I had created a task manager a while ago to address precisely these issues. I'm attaching the LabVIEW 2009 code for it. Please feel free to take this as the starting point and expand it further. I'd also love to work on this one more. Currently it:

• Lists all VIs in memory
• Displays basic information like VI state, path, data size, code size, FP Behavior, Reentrant? Reentrance Type, etc.
• Let's you select multiple VIs and open FP or BD
• Let's you select multiple VIs and Abort
• let's you select a refresh rate and updates the lsit
• sort by any column
• let's you filter file types like vi, vit, and ctl

What other functionality would you like to see in it?

• select application instance?

Should this be submitted to the repository or should we keep attaching versions to this discussion? Cheers! LabVIEW Task Manager.zip

memory usage, and maybe cpu usage?

[Aristos Queue]

This topic is incredibly timely for me, as I've been building my own tool to do this recently. On this topic, I have some bad news. But before that... Ravi, I liked your UI, so I integrated a few features I had in my app into yours. I hope you don't mind.

Added:

• Tracking of execution highlight and ability toggle it on all selected VIs
  
• Tracking of paused VIs and ability to toggle pause on all selected VIs
  
• Selection of project/target
  
• Filtering of vi.lib
  
• Filtering of global VIs
  
• Filtering of control templates (.ctt)
  
• Sorting by library name
  
• Compressed the column text for some entries so more columns fit on the screen
  

Here's the modified VI:

LabVIEW Task Manager AQ Revision.zip

Just a bit of tweaking and it can be added directly to the Project directory and launched from the Tools menu. Sorry... it's 2am and I'm not doing that extra bit of tweaking right now.

Now, on to the bad news...

I've spent the last week working on exactly this sort of tool, and I've had a series of problems that I could not solve. I looked at the Task Manager uploaded by Ravi Beniwal, thinking he might have overcome the issues somehow. His tool has the same bugs, though he may not realize it. After consultation with other LV R&D folks today, I can now say that these bugs cannot be fixed in LV 2011 or earlier. And I'm doubtful we can do anything about them in the time remaining for LV 2012 features.

Two insurmountable problems I found...

-----------------------------

First: Affects reentrant VIs. There is no effective way to get a list of the clone VIs... you know, the ones that are named "XYZ.vi:1" or higher numbers.

These are the VIs that you often most need to abort, since one of the more common patterns in LV is to kick off reentrant clones running independently and then, when something goes wrong, you need to kill them. But you cannot get a list of all the reentrant clones that a VI has. You can open a VI ref to the clones by using Open VI Reference and passing a name in like "XYZ.vi:1". I tried checking each value sequentially until I got an error, only to discover that the numbers are not sequential. They can be any number up to MAX_Int32 (roughly 2 billion), so the "guess and check" method is out.

-----------------------------

Second: Affects both remote VI Server calls and local Asynch Call By Ref calls. You can't abort subVIs. The Abort VI method will return error 1000 unless the VI is the top-level VI. So what's the problem? When you launch a VI using the Asynch Call By Reference using "Fire & Forget" mode, it launches as a subVI, even though it will keep running if its caller quits. That means that even if the VI is not reentrant, so you can get a reference to it, you still can't tell it to abort. And there is no way to get the caller VI because the caller VI is a fake proxy (you can see it in the VI Hierarchy window). When you launch a VI remotely using the Run VI method or ACBR, you also have a proxy caller that isn't abortable.

-----------------------------

I've talked to multiple R&D staff with really deep knowledge of this issue, and there is no solution, and when I raised the topic was basically the first time that those involved collectively realized just how problematic this is to solve. I'd like to say something will be better in 2012, but that seems unlikely at this late date (yes, a month after 2011 released is late in our dev cycle; we do have to finish development pretty far in advance to get the testing solid).

The best workaround solution is to build a mechanism into your reentrant and dynamically launched VIs that allows them to be messaged by some tool to stop them -- like if they use a queue, register that queue with a central data store somewhere that you could run to kill all those queues, which would make those VIs exit on their own. Unfortunately, that lead me to discover the third issue. There's no solution in LV to have code that is conditionally compiled in only when debugging is enabled on the VI. Code that registers the VI with the central system is useful while debugging, but probably shouldn't be there when you release -- it's only going to create performance overhead and take up memory. But you'll have to remove it manually before you build your application OR create a custom conditional disable symbol in every project you write. I find this solution distasteful at best.

Anyway, that's my sucky news on the LV Task Manager front. I hope the edits I did add are useful.

[drjdpowell]

You can open a VI ref to the clones by using Open VI Reference and passing a name in like "XYZ.vi:1". I tried checking each value sequentially until I got an error, only to discover that the numbers are not sequential. They can be any number up to MAX_Int32 (roughly 2 billion), so the "guess and check" method is out.

How fast can they be checked? Because in my experience, they start at 1 and count up, so in the majority of cases trying every number up to, say, 100 will find them all (I think I got the count up to 50-odd a couple of times).

The best workaround solution is to build a mechanism into your reentrant and dynamically launched VIs that allows them to be messaged by some tool to stop them -- like if they use a queue, register that queue with a central data store somewhere that you could run to kill all those queues, which would make those VIs exit on their own.

If you create your message queue in the calling VI and pass it to the dynamic callee, then when the caller goes idle it invalidates the queue, which can be used to trigger shutdown of the callee. No good if you need the callee to be fully independent of the caller, but most of my dynamic VI's are "owned" by the process that starts them.

-- James

Edited September 21, 2011 by drjdpowell

[drjdpowell]

Here's a quick hack where I test for clones, looking at AQ's Active Object Demo:

Searching for clones up to xxxxx:100 doesn't take much time (up to xxxxx:10000 had a delay of about 5 seconds for this project). One could decrease the likelihood of missing clones while still being fast(ish) by a search procedure such as: search up to 100, if find clones also search 100-1000, if find more clones search 1001 to 10,000.

-- James

Edited September 21, 2011 by drjdpowell

[drjdpowell]

Second: Affects both remote VI Server calls and local Asynch Call By Ref calls. You can't abort subVIs. The Abort VI method will return error 1000 unless the VI is the top-level VI. So what's the problem? When you launch a VI using the Asynch Call By Reference using "Fire & Forget" mode, it launches as a subVI, even though it will keep running if its caller quits. That means that even if the VI is not reentrant, so you can get a reference to it, you still can't tell it to abort. And there is no way to get the caller VI because the caller VI is a fake proxy (you can see it in the VI Hierarchy window). When you launch a VI remotely using the Run VI method or ACBR, you also have a proxy caller that isn't abortable.

I don't know your Actor Framework very well, but when playing around with it using the Task Manager I found that the dynamically launched "Actor.vi" clones showed up as "RunTop" and I was able to Abort them from the task manager.

Running "Pretty UI" with 2 sensors added.

Edited September 21, 2011 by drjdpowell

[Ravi Beniwal]

Friends, let me please get a lock on these VIs for a couple of hours. I am working on merging AQ's work and all that I did yesterday.

Earlier I was working on the Task Manager and the Simultaneous Breakpoint Manager separately, but it is probably better done as a single tool. So let me merge all our work so far and see where we get.

Since we don't have any SCC, let's just do it the old fashion way