Workers Application Manager
Workers Debug Server
Last updated
Workers Debug Server
Last updated
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.
Removes all Worker application instances that are no longer connected to the Debug Server (red dots), from the Application Manager's tree list.
Opens the Debug Server's Settings dialog window.
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:
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
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.
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:
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.
