Worker Message Logs
Workers Debug Server
Last updated
Workers Debug Server
Last updated
A Workers Message Log allows you to:
see the flow and sequence of messages sent between Workers at run-time
see when and where any errors have occurred in your applications
access a running Worker's MHL cases (right-click menu option)
see custom debug messages
An example of a Workers Message Log is shown below, showing the sequence of messages that have been sent to Worker MHL cases.
A single Message Log window is created for each Workers application that is defined by the Head Worker's Alias and the IP Address of where the Workers application is running. Therefore, it is possible to have more than one Workers application sending messages to the same Message Log, IF the Head Worker's Alias and IP Address of the applications are the same.
Pauses only the visible updating of new messages to the Message Log front panel. It does not pause the logging of messages to file (if Live Logging is selected).
Automatically resizes the width of all columns based on the longest string in each column.
Applies a filter to the message log, based on the contents in the fields: String to Filter, Column and Type.
More than one filter can be applied, allowing you to apply filters on top of filters.
Un-applies the previously applied filter.
Clears all applied filters.
Every time a message is dequeued within a Worker's MHL, meta-data about the message is forwarded to the Worker's Debug Client (if one exists), and then sent to the Debug Server's Message Log (if one exists). The following information about the message is provided in the Message Log's columns.
Good to know
When a Message Log connects to a Debug Client, the order of the messages that appear in the Message Log is the order that the messages were dequeued by their respective MHLs, and not the order that the messages were enqueued. Pressing the Sort button will sort the messages by the time the messages were enqueued.
This column exists on the very right of the Message Log, and contains a high-resolution timestamp of when the message was enqueued (provided by the LabVIEW palette VI: High Resolution Relative Seconds.vi.) It is not possible to disable this column.
Provides a human-readable low resolution timestamp of when a message was enqueued.
The WID or alias of the Worker that enqueued the message.
The MHL case that the message was enqueued from.
The WID or alias of the Worker that dequeued the message.
The MHL case that received the message.
The priority of the message.
Messages sent between MHL cases do not contain an additional message string. This column is reserved for use by Error and User messages (see below).
Sent by the framework's Error Handler.vi which exists after the case structure in every Worker MHL. If an error is received on this VI's error in input terminal, the error will be sent to the Message Log. The timestamp for the message is created within Error Handler.vi.
Good to know
Error Handler.vi can be placed anywhere in your code where you want to catch errors to be sent to the Message Log.
Sent by use of the Worker's palette VI: Send Debugger Message.vi. Users can place this VI anywhere in their code where they want to send a custom message to the Message Log. The timestamp for the message is created within Send Debugger Message.vi.
Good to know
The Enque and Deque columns contain data for both error and user messages. This data comes from the MHL case that sent the error or user message, allowing you to see, for example, which Worker MHL case sent the error or user message (i.e. Deque Worker and Deque Case).
When TRUE, any new messages that are acquired by the Message Log will be logged to a comma delimited text file, with each Message Log (regardless of whether they are visible or not) separated with a comma. You can set Live Logging to be either TRUE or FALSE when a Message Log is created, from within the Debug Server's .
Will sort the Message Log rows by the high resolution timestamp value in the column.
Toggles between the Worker's ID (WID) or the Worker's Alias for both the and columns.
If this field is blank, it is probably because the message was enqueued without the Caller's connected to the Caller input terminal of a Public Request VI. This terminal is not required if the Public Request VI is being used from an external LabVIEW application or from TestStand.
If this field is blank, it is probably because the message was enqueued without the Caller's connected to the Caller input terminal of a Public Request VI. This terminal is not required if the Public Request VI is being used from an external LabVIEW application or from TestStand.
