Task Manager
The purpose of the Debug Server's Task Manager is to show you which Workers in your applications are running, along with their status. The Task Manager also allows you to interact with your Workers, allowing you to, for example, jump into the running instance of a Workers QMH or call the shutdown routine of a Worker.
An example of the Task Manager is shown below, showing various Workers applications that have been/are connected to the Debug Server.
Columns
Worker ID
This column shows the Workers applications that are/have been connected to the Debug Server, showing a tree list of an application's Worker call-chain hierarchy. The names represent the aliases of the Workers in the application.
In addition to the Workers themselves, the following information is also displayed in this column:
Type
This column shows you how a Worker is linked to its Manager.
SL : the Worker is statically linked to its Manager
DL : the Worker is dynamically loaded by its Manager
Clone ID
This column shows you the clone ID of a Worker's Main.vi. If the Worker's Main VI is not a clone, then Not a Clone will be displayed for a Worker.
Status
This column displays the status of a Worker. A Worker is assigned a number of different statuses by the framework, to provide developers with state feedback during the initialization and shutdown routines of a Workers application. Developers can also assign their own statues to their Workers, by use of the Workers palette VI: Update Worker Status.vi. Statuses assigned to Workers by the framework include the following:
| Status | Description |
|---|---|
Queue Created | The message queue for the Worker has been created by the Worker's Setup subWorker - (Worker Name).vi (or by the Setup Head Worker.vi if the Worker is the Head Worker.) If you see this: the Worker’s Main VI does not exist on the block diagram of its Manager, and therefore messages sent to it will never be dequeued. |
Pre-Initialized | The Worker’s Main VI has been loaded and it is able to dequeue messages that are sent to it.
If you see this: the Worker has not yet had its <Initialize> case called by its Manager. This is performed by the use of Initialize subWorkers.vi in the Manager. |
Initialized Called | The Worker’s <Initialize> case has been called by the Worker’s Manager. If you see this: the Worker has not yet notified its Manager that it has been successfully initialized. This is performed in the Worker by Initialized Notify.vi. |
Initialized | The Worker has notified its Manager that it has been successfully initialized by the use of Initialized Notify.vi.
If you see this: this is the status you will see when your Worker has been initialized correctly. No other framework statuses will appear for this Worker until the Worker starts to shut down. |
Start Exiting Called | The Worker’s <Start Exiting> case has been called by use of either Worker Start Exiting.vi or by the Worker’s Manager's use of Start Exiting subWorkers.vi.
If you see this: the Worker has not yet notified its Manager that it has successfully exited. This is performed in the Worker by Exited Notify and Cleanup.vi. This VI should be the very last VI that is called by the Worker’s Main VI. |
Exited | The Worker has notified its Manager that it has successfully exited by use of Exited Notify and Cleanup.vi.
If you see this: this is the status you will see when your Worker has completed a clean shutdown. This is the final framework status of the Worker. |
Stopped (Critical Error) | A critical error has occurred in the Worker. The Worker has stopped and can no longer be accessed by the framework.
If you see this: The Worker’s message queue has been destroyed unexpectedly. |
(Aborted) | This string is appended to any of the above statuses whenever the application is terminated pre-maturely. |
Last updated
