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.

Not sure. The sad part about all this is that my interest extends to solving one particular bug. I'm not sure how much utility all of this will generally have in the future, so I'm not recommending anyone pour too much time into it. Having said that, I'm thrilled to have what you've built thus far!

There's nothing sad about this. I've used the some workaround to achieve similar functionality in the past and have certainly used the Task Manager a lot. Cleaning all this up and adding all this functionality can only help everybody.

Besides, we are having fun doing this, which is the whole point IMO!

> 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?

Hi Pravin, can you please elaborate on exactly what you want to achieve?

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?

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

Should there be an option to let a pause condition in a clone, pause other clones of the same VI only, instead of pausing all VIs registered with the Simultaneous Breakpoint Manager?

I guess we could combine the LabVIEW Task Manager and the Simultaneous Breakpoint tool, if that makes some things easy. So you could select VIs from the Task Manager and add them to the Simultaneous Breakpoint tool.

Can someone please put their creative hat on and suggest a name for this. I'm getting tired of typing "Simultaneous Breakpoint tool". I'd rather be connecting boxes with lines coding

OK, I couldn't wait for tomorrow; here it is!

I believe it does most of what you asked for. Let's see those bonus points too

So, the code consists of a Breakpoint Manager and a Functional Global (FG). Drop the FG in any VI that you want to pause on demand. It will add the VI (clone or otherwise) to the Breakpoint Manager's list. You can Pause/Resume All/Selected.

I added two lists, one for paths and one for VI names because clones will not have paths. Also, It might be just easier to drop the VI into a VI rather than copying/pasting its path in a paths array. Although, the functionality is there if that works better in some cases.

Instructions:

1. Run the Breakpoint Manager (SBP_Main.vi) first so that it can initialize the FG.

2. Run the "Parallel VIs Launcher.vi", which will launch a couple of clones of a reentrant VI.

I didn't make a custom probe as I din't know what datatype the probe was supposed to work with. Just drop the FG with Action:Pause in any custom probe. When the probe trips, it will pause all VIs registered with the Breakpoint Manager.

Simultaneous Breakpoints Manager.zip

Had some fun working on this today. Almost done; will share the code tomorrow!

It gets better:

If you turn off "allow user to resize window" (which you most likely would to make it a toolbar) and host your toolbar VI as a child window in your main UI window, you'll get really thin borders. Check this out!

I have also used ARRAY of CLUSTERS, where the cluster contains Numeric and Boolean indicators, or in one case even a 2D Picture and a Boolean, to show the selected item. Works pretty well!

Hi Olivier,

I created a custom probe for my Queues a while ago. Please feel free to include it in your tool, if you see a fit. This especially helps while monitoring the execution of a consumer loop in a queued message handler. You can slow the execution down so you can actually read the queued messages.

The code is pretty simple, but has helped me a lot.

Message Queue Probe.vi

I have been using this tool for for last couple of days and loving it! It integrates really well with Project Explorer.

Initially, I tried the version that you can download from their website (r277). It looked really good in principle as it changed the icon overlay for each item in Project Explorer to match the icon overlay in Windows Explorer. This made things really easy to visually see the status of each item. But it made LabVIEW crash every now and then. Apparently, it was updating the icons that LabVIEW did like.

The guys at Viewpoint Systems recommended that I download the latest version from their ftp server. So now I have r290. No more crashes, but the icon overlays are gone. But it still works great.

One advantage I see for this tool compared to the JKISVN tool is that I don't have to select an item in the Project Explorer and then go to the Tools menu for every action. This tool adds all the SVN functions in the context menu and of course in the toolbar.

That came to a screeching halt in no time... The XControl is password protected!

The 3D graph, if memory serves, is an unlocked XControl, so you should probably be able to edit it, although I don't know how easy it would be and you would need to create a copy of the entire library so that it's not overwritten when you upgrade LV. Presumably it's somewhere in vi.lib and you should be able to easily see it by right clicking a 3D graph and selecting Advanced>>Show Diagram, which I believe should be available in all XControls.

Thanks for the clue!

I've done something similar to the XControl for Spectrogram in the Order Analysis toolkit in the past.

I'll try this one and will post the code if something good comes out of it.

I need to draw objects in a 3D Graph Control, just like we do in the 3D Picture Control.

Since the 3D Graph Control is "made from" the 3D Picture Control, I got the 3D Picture Control ref from the convenient property node. Then I created a cube and drew it in this picture control ref. Now the result wasn't what I wanted, but it also didn't surprise me. All the axes and grids were wiped out and all I got was the cube.

Now if I rotate the view and leave the mouse button, the cube is gone and we get the axes and grid planes back. The 3D Graph Control probably has a redraw function that made this happen.

Is there a way to hack the 3D Graph Control so that we can use the surface plots, cursors etc. that it was intended for, but also draw geometries and textures as we can do with the 3D Picture Control?

Drawing Object in 3D Graph Control - 2009.vi

It certainly doesn't work for an XControl in a VI that is inside a subpanel .

In my particular case, I had a child window of the main application, which had a SubPanel, which in turn hosted a VI with an XControl.

The Xcontrol had multiple panes and had a color ramp in one of them. Since a color ramp (z-scale) doesn't resize with panel (only the color box part does), I had to resize the color ramp height on pane resize. Now every time you resize any component in this chain, it produces a million pane resize events and you see the color ramp resizing animation for a while after you are done resizing. This issue made me search for the topic and I landed on this page.

After failing to catch the "ending only" of the resize operation at the XControl level and the SubPanel, I have resorted to catching this event in the child window and then pass the message through the VI in the subpanel to the XControl. Not an elegant solution, but it works.

It doesn't work for panel resize for an XControl facade VI either, when I resize an XControl on another VIs FP. The facade VI didn't get that last panel resize event, for which old and new bounds are supposed to be the same.

Hi Michael,

This is neat. I wish it worked for pane resize too.