LabVIEW Task Manager

[Aristos Queue]

drjdpowell: Your post unwittingly highlights something VERY interesting. You're working with the older version of the AF, where we used the "Run VI" method. In the 2011 NI Week release, we're using the Asynch Call By Reference because it makes it much simpler and faster to launch copies. But the speed improvement is marginal, and ACBR makes us lose the ability to abort the subVIs. Going back to the Run VI method would make them open as top-level. That's something worth considering!

Everyone: The checking for clones problem gets worse the more times you run your application. Statically allocated clones will generally keep their number. Dynamically allocated clones will move further down the number line. That poses a problem for the "test a few" idea.

[drjdpowell]

Everyone: The checking for clones problem gets worse the more times you run your application. Statically allocated clones will generally keep their number. Dynamically allocated clones will move further down the number line. That poses a problem for the "test a few" idea.

Not necessarily. If the original clones have left memory when the new ones are created, the numbering seems to start at the lowest available number. It's only when clones stay in memory for some reason (Front Panel still open, for example) that the numbers start marching forward. I was having the issue of Actor.vi clones staying in memory until I saved everything in LV2011 (your right, it is an older version of your framework that I am running) after which all the clone number start from 1 regardless of how many times I restart the application.

I don't fully understand the issue, and unfortunately I don't fully understand why LabVIEW sometimes keeps clones in memory.

Edited September 21, 2011 by drjdpowell

[lvb]

It seems this thread is picking up momentum. It is great to see LAVA members working together.

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

Ravi, thank you for sharing your work.

drjdpowell: Your post unwittingly highlights something VERY interesting. You're working with the older version of the AF, where we used the "Run VI" method. In the 2011 NI Week release, we're using the Asynch Call By Reference because it makes it much simpler and faster to launch copies. But the speed improvement is marginal, and ACBR makes us lose the ability to abort the subVIs. Going back to the Run VI method would make them open as top-level. That's something worth considering!

Everyone: The checking for clones problem gets worse the more times you run your application. Statically allocated clones will generally keep their number. Dynamically allocated clones will move further down the number line. That poses a problem for the "test a few" idea.

Thanks for sharing your work also. I was just confirming the re-entrant numbering with a few test VIs. It appears the Async call does not use sequential numbering:

Background_Task.vi

Launch Background Tasks.vi

[drjdpowell]

It appears the Async call does not use sequential numbering:

I downloaded the 2011 Actor Framework example (that uses Async Call by Ref) and it keeps increasing the numbers (even though the clones leave memory between runs) but sequentially. Rather strangely though, the numbers 1 and 2 get reused. Curiouser and curiouser...

For the older software, with the "Run VI" method, the numbers don't increase.

Edited September 21, 2011 by drjdpowell

[Samapico]

I read through all this quickly, maybe it's been said/proposed already... but is there any way to have it tell you which sub-VI is currently running?

i.e. if you have one top VI, that spawns multiple threads (not even dynamically, in our case), and when a "stop" is issued, all these threads must quit, and we often find ourselves unable to know which one is stuck, and where it's stuck.

So basically, listing the 'bottom' VI's, as well as the 'top' VI(s), without necessarily listing the entire call chain.

[Ravi Beniwal]

Friends, here is Version 3 of the LabVIEW Task Manager.

LabVIEW Task Manager R3.zip

Here are a few key changes:

• Clone VIs FG.vi added. Just drop this VI in any reentrant VI. When the clone is created and run, it will add its name to this FG. The Task Manager will now display "All VIs in Memory" AND the ones in this FG. This solves the "how to find all clones" issue. Slightly inconvenient, as you have to drop this VI in the reentrant VI, but will certainly work in all situations. Also, leaving it in even when deploying the application will not effect the performance as it is just an array of a few strings.
  
• Pause.vi added. This addresses AQ's original need of initiating a pause from within any VI on some condition. Just drop this VI in a case structure after your custom probe condition evaluation. It will only work if the task manager is open. If the pause request is generated from a clone of a reentrant VI, it will pause all clones of that VI.
  
• Pause and Resume buttons instead of just one (Un)Pause button, because the earlier implementation would have always toggled the state of a VI. So if you if one VI in a selection was already paused and you clicked (Un)Pause to pause all VIs in the selection, that one VI will now resume instead of staying Paused.
  
• Close BD button added. This will help to close block diagrams of all selected VIs. This should make life easier after you have paused all the zillion clones of a VI, which would have opened that many block diagram windows.
  
• Double Clicking on a VI in the task manager will bring the BD to front if already open, otherwise it will bring the FP to front if already open. Bringing BD to front works only for non-reentrant VIs.
  
• Tree symbols added to mark paused VIs. Also, if a clone initiates a pause, a different pause symbol is used for that clone to show which of the clones initiated the pause.
  
• UI has been rearranged (filters on top, action buttons on the bottom) for clarity and to make more room (for feature creep)
  
• Windows Task Manager style menu with Update Speed and Refresh Now items added.
  
• When new VIs are launched, they don't automatically get added to the Task Manager. Hit F5 or select Refresh Now menu item to read all VIs from memory and add them to the tree. The update in the timeout case only updates the current state of all VIs in the tree.
  

Launch the \\LabVIEW Task Manager R3\Test VIs\Parallel VIs Launcher.vi to launch one normal and four clones of a reentrant VI. This will give you a quick test case for playing with the Task Manager.

Now about the bad news that AQ broke last night about the inability to programatically abort a running SubVI.

I'm not sure really how big of a deal is this. If abort fails on a SubVI, can't we simply open its BD and hit the abort button. Am I missing something here?

[Aristos Queue]

> I'm not sure really how big of a deal is this. If abort fails on a SubVI,

> can't we simply open its BD and hit the abort button. Am I missing something here?

The reason I started building these tools is that I have at least 10 up to a couple hundred independently running clones. Hitting all those Abort buttons takes a while. My work around has been to close the project, which throws away the entire application instance, but that looses all of my probes, which I found frustrating.

[Aristos Queue]

Ok, I see what you did in the Pause/Unpause code. You tried to fix what seemed like a bug in the UI -- the button as I had it just toggled the state, so if I had a mixed bag of some paused VIs and some unpaused VIs, hitting the button would pause some and unpause others.

The toggle behavior was actually a feature to me. The toggle behavior lets me freeze all the server VIs, allow the clients to run for a while, then flip the two halves, given the server time to run. I can see the use of a flat out Pause button to just select a bunch and freeze them without accidentally unfreezing something else, but I'd still like my (Un)Pause button as a third button.

Minor side issue: fix the label of the "Resume" button.

Otherwise, looks very good.

[Ravi Beniwal]

> I'm not sure really how big of a deal is this. If abort fails on a SubVI,

> can't we simply open its BD and hit the abort button. Am I missing something here?

The reason I started building these tools is that I have at least 10 up to a couple hundred independently running clones. Hitting all those Abort buttons takes a while. My work around has been to close the project, which throws away the entire application instance, but that looses all of my probes, which I found frustrating.

I knew I was missing something.

So, the test VIs I created did not include an asynchronous call to open a reentrant VI. When I pressed the abort button in the toolbar of one of the clone VIs, it aborted all VIs. Now I added an asynchronous call to the reentrant VI and saw that aborting that VI did not abort any others.

So I guess LabVIEW 2012 will be the answer

I'll fix the label and anything else that people find and will post the code again tomorrow.

The toggle behavior was actually a feature to me. The toggle behavior lets me freeze all the server VIs, allow the clients to run for a while, then flip the two halves, given the server time to run. I can see the use of a flat out Pause button to just select a bunch and freeze them without accidentally unfreezing something else, but I'd still like my (Un)Pause button as a third button.

I've added the (Un)Pause feature again. Should we call it (Un)Pause or Toggle Pause?

[drjdpowell]

Ravi,

Here's, if you would like to use it, is a "Find Clones" VI that searches for clones up to some number. It can be inserted into the list of VIs after filtering.

Find Clones.vi

[Ravi Beniwal]

Hi James,

Thanks! I'll add this VI to the Task Manager with a checkbox on the UI to enable/disable the search.

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.

The concern below kept me from going this route. But I guess having it can't hurt, if finding every single clone is not absolutely critical.

It is certainly easier than dropping the Clones VIs FG.vi in every single Reentrant VI. Speaking of which, we could create a scripting VI that can go through an entire folder of VIs checking for their reentrancy and dropping this VI in if a VI is reentrant (and if this VI is not already present). We could conditionally disable it so it runs only in development mode and not in Runtime.

[drjdpowell]

I'll add this VI to the Task Manager with a checkbox on the UI to enable/disable the search.

You might want to instead have a numeric control of the clone number to search up to. Zero would mean disabled, the default could be 100 or so, and Users could increase the number if they were working with higher-numbered clones.

BTW, an idea to improve the tool is to group VI's by class/library, like this:

Not sure if that's easy to do, but it would greatly improve readability for LVOOP projects that tend to have large numbers of identically-names VIs (as well as not particularly descriptive names such as "Do.vi").

-- James

Edited September 22, 2011 by drjdpowell

[Ravi Beniwal]

You might want to instead have a numeric control of the cone number to search up to. Zero would mean disabled, the default could be 100 or so, ...

interesting! I just happened to do exactly that this morning. Great minds think alike, I guess

...Users could increase the number if they were working with higher-numbered clones.

Would one always know if he is working with higher-numbered clones? AQ suggested otherwise!

[Aristos Queue]

Darren Nattinger had a different attempt to the "find the clones" problem. His solution gets all the statically referenced clones.

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

Would one always know if he is working with higher-numbered clones? AQ suggested otherwise!

My experience is that when working with dynamic clones, the count keeps going up on each debug run of the VIs, so you might know but it is easy to lose track.

[Ravi Beniwal]

Darren Nattinger had a different attempt to the "find the clones" problem. His solution gets all the statically referenced clones.

Thanks Darren! I have included your VI in the solution.

Here is the latest package that include most of what we have discussed so far.

LabVIEW Task Manager R4.zip

My experience is that when working with dynamic clones, the count keeps going up on each debug run of the VIs, so you might know but it is easy to lose track.

After including Darren's VI for searching statically referenced clones, we no longer need to include the Clone VIs FG.vi in the reentrant VIs that are statically referenced. But if you put this FG into a reentrant VI that is called asynchronously, it will make sure all clones are found.

[drjdpowell]

Thanks Darren! I have included your VI in the solution.

Hi Ravi, Darren's VI seems to be missing from the R4 zip file. -- James

[Ravi Beniwal]

Sorry about that! When I downloaded Darren's VI, it went straight to my Downloads folder and was being linked from there. I've fixed that now and have actually included it this time Here is the updated R5.

LabVIEW Task Manager R5.zip

I've added grouping by class/library that you suggested. I've also added a Close FP button and improved the numeric sorting of the data tree.

Please let me know if anything is missing this time or if you have any suggestions/comments.

[Samapico]

Could this be saved as 2010? I'm curious to try it out...

Thanks

[Ravi Beniwal]

Here's the Task Manager R5 saved for LabVIEW 2010!

LabVIEW Task Manager R5 - 2010.zip

[Samapico]

It looks like it could be useful, but I have a few comments:

When sorting by "state", it seems to be sorting items in each class/library by themselves... So there's no way to tell right away which VI's are running if you have a large project. It's not easy though, I guess you'd have to split library/class groups if they have VI's in different states. For example:

[-] a.lvlib:

____someVI.vi (RunTop)

____anotherVI.vi (RunSub)

[-] b.lvlib:

____something.vi (RunSub)

____bleh.vi (RunSub)

...

[-] a.lvlib:

____hmmm.vi (Idle)

[...]

I'd guess that doing that would be quite hard... but how about a way to filter by state instead? You could quickly find running VI's in a short list.

The project I'm running has over 1000 VI's... this task manager takes about 20 seconds for a single refresh. It's pretty painful... Do you guys have any optimization in mind that could improve this?

Still a handy tool, thanks for sharing

[Ravi Beniwal]

Adding a filter for VI state sounds like a good idea. I'll look into it and any optimization for adding large number of VIs to the tree. May be use add multiple items to tree instead of adding each item individually. But during a refresh, it has to get the properties of each VI and update them. Well may be not, if we specify which properties (columns) will change during execution and check only those.

I'll post an update or list of issues

[drjdpowell]

Three months later...

Thought I’d post on something I developed from Ravi’s Task Manager. I found I had difficulty using the Task Manager, not because there is anything wrong with it, but because the LVOOP-heavy framework I use has a ridiculously large number of subVIs loaded at any one time. The actual VIs that I’m really interested in are very few and are hard to pick out from the noise. And the massive amount of VI Server calls looking for all the potential clones of all these subVIs took forever. So in the end, I rewrote almost all of it to make it a very narrowly specialized tool that lists only the VIs I most need. These VIs are the core of what I call “Actors”, dynamically-launched VIs that communicate only through exchanging messages (here’s a post on an earlier version), so it’s called the “Actor Manager”. Here’s a screenshot where the Manager is observing three open projects, one running a TCP Server and two others as TCP clients (an earlier post on the TCP stuff is here).

All the items with black dots are Actors, arranged in a tree according to who launched who. In the common launch code for actors, information about it, including what VI launched it and an optional short description of the new actor, is posted in a named notifier (name based on a clone name of a preallocated subVI used in the launch process, so that it is unique). The notifier remains in existence while the actor is running. The Actor Manager uses VI server to run a “Find Actors” VI on each open project; this VI searches through all possible notifier names. The search by notifier name is very fast, so I can search for clone names up to 10,000 on each application instance without taking much time.

So, this is sort of the same as the “Task Manager”, but also totally opposite, in that it is a completely specialized tool, useless outside of the framework it’s designed for, rather than being a generally applicable tool. But that narrow focus also allows it to do its specialized task very well (being able to clearly see the tree of who launched who is very important to me). For anyone else with a similar framework (“Actor Framework”, for example, or MJE’s “MessagePump”) I can recommend making a similar tool. It took me more time to do that it should have, because at first I was trying to maintain the generality of Ravi’s Task Manager while adding specialized features too it, but that proved too difficult. So I recommend a separate tool (and also use Ravi’s excellent Manager when a general tool is needed).

— James

[Stobber]

James, any chance of you sharing the source for your custom tool or contributing it to a new community project to develop an "Actor Manager" we can all use?

[ohiofudu]

I spent some time handling Error in the Task Manager Project .I also did some file hierarchy and proper Naming.

Here is the Rework in LV 2010.

LabVIEW Task Manager R6 with Error Handling - 2010.zip

[drjdpowell]

James, any chance of you sharing the source for your custom tool or contributing it to a new community project to develop an "Actor Manager" we can all use?

My Actor Manager is very specific to my messaging framework, but I did a trial prototype for the 2012beta Actor Framework here.