Workers Application Manager

Workers Debug Server

When you run the Debug Server application, the Workers Application Manager window will appear. The purpose of the Application Manager is to provide you with a single location where you can access and observe all of your running Workers applications. The following section will explain the various features of the Application Manager.

Every Debug Client is identified by a unique random ID number (this is not observable). Therefore, it is possible to have more than one Workers application with the same Head Worker ID (running on the same target) appear in the Application Manager.

Buttons

Clear all Disconnected

Removes all Worker application instances that are no longer connected to the Debug Server (red dots), from the Application Manager's tree list.

Settings

Opens the Debug Server's Settings dialog window.

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 Caller.

SL : the Worker is statically linked to its Caller
DL : the Worker is dynamically loaded by its Caller

Clone ID

This column shows you the clone ID of the Worker's Main VI. If the Worker's Main VI is not a clone, then Not a Clone will be displayed for the 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 Caller, 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 Caller. This is performed by the use of Initialize subWorkers.vi in the Caller.
Initialized Called	The Worker’s <Initialize> case has been called by the Worker’s Caller. If you see this: the Worker has not yet notified its Caller that it has been successfully initialized. This is performed in the Worker by Initialized Notify.vi.
Initialized	The Worker has notified its Caller 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 Caller's use of Start Exiting subWorkers.vi. If you see this: the Worker has not yet notified its Caller 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 Caller 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.

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 Caller, 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 Caller. This is performed by the use of Initialize subWorkers.vi in the Caller.

Initialized Called

The Worker’s <Initialize> case has been called by the Worker’s Caller.

If you see this: the Worker has not yet notified its Caller that it has been successfully initialized. This is performed in the Worker by Initialized Notify.vi.

Initialized

The Worker has notified its Caller 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 Caller's use of Start Exiting subWorkers.vi.

If you see this: the Worker has not yet notified its Caller 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 Caller 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.

PreviousWorkers Debug Server NextRight click menu

Last updated 11 months ago

Columns

Worker ID

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 Caller.

SL : the Worker is statically linked to its Caller

DL : the Worker is dynamically loaded by its Caller

Clone ID

This column shows you the clone ID of the Worker's Main VI. If the Worker's Main VI is not a clone, then Not a Clone will be displayed for the Worker.

Status

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 Caller, 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 Caller. This is performed by the use of Initialize subWorkers.vi in the Caller.
Initialized Called	The Worker’s <Initialize> case has been called by the Worker’s Caller. If you see this: the Worker has not yet notified its Caller that it has been successfully initialized. This is performed in the Worker by Initialized Notify.vi.
Initialized	The Worker has notified its Caller 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 Caller's use of Start Exiting subWorkers.vi. If you see this: the Worker has not yet notified its Caller 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 Caller 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.

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 Caller, 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 Caller. This is performed by the use of Initialize subWorkers.vi in the Caller.

Initialized Called

The Worker’s <Initialize> case has been called by the Worker’s Caller.

If you see this: the Worker has not yet notified its Caller that it has been successfully initialized. This is performed in the Worker by Initialized Notify.vi.

Initialized

The Worker has notified its Caller 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 Caller's use of Start Exiting subWorkers.vi.

Exited

The Worker has notified its Caller 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.