Module

The Module is a mainclass inherited from the Actor class. Put very simply, the Module is an event-driven, complex state machine that runs in parallel with the Actor. The Module is the basic “building block” of the Framework. Despite its relatively simple structure, it provides the ability to solve complex tasks in a modular way using module commands. Using the Module table, created to store various state variables and configuration variables, you can create a list of variables tailored to the task without having to make any changes to the Module itself.

Variables of the Module class

• Name: The name of the module, which makes it easily identifiable to other modules

• Module Events: A list of events that the module can generate. (In the LabVIEW Event Loop, these are registered and called)

• ErrorData: An array containing LabVIEW error messages and the module’s error status

• Available Messages: A list of callable messages—if a message arrives that is not listed here, it is ignored

• Message Name List: An array of strings containing the names of the available messages

• Module Parameters: Contains the Module table (for storing variables and sharing them with other modules) as well as the Debug parameters (for debugging assistance)

• Application Name: The name of the application being developed (often the project name)

• Application Data Path: The path where the project saves the data required for execution

• Interface Module Commands: A list of module commands that can be called by other modules

Module class messages

Main functions of Module class

Pre Launch Init.vi

Before the Module begins processing messages, this VI runs. This is where the variables critical to the class’s operation are initialized. There are variables without which message processing would either fail to occur or generate an error; these must be set just before execution begins. These include, for example, the available messages, the module commands that can be called by other modules (Interface Module Commands), and the module variables to be loaded into the Module table; additionally, if the module’s default events are insufficient, user-defined events are also initialized. Functions called in Pre Launch Init:

• Initialize Module: Initializes the module table and the error buffer
• Set Module Name: Sets the module name
• Initialize Module Events: Initializes callable events
• Initialize Messages: Creates a list of callable messages and organizes their names into a list
• Initialize Interface Commands: Creates and stores a list of callable module commands
• Initialize User Events: Derived classes can create new events by overriding this VI
• Initialize Debug Parameters: Initialize parameters to assist with debugging
• Initialize Module Keys: Create variables to be stored in the Module table
• Module Counter: Increment the count of running modules

Actor Core.vi

This is where the basic state machine is implemented, which includes a few initialization steps, error handling, and waiting for and responding to events generated by messages or by the class itself. By default, after initialization, the class waits for events or messages. It continues to do so until the Shutdown event is received. If we create a derived class from the Module (or one of its descendants) within a project, we implement the main functionality by overriding this VI.

Module Table functions

Using the Module Table and the Resource Manager (both of which are explained in detail in their own chapters), you can not only read and write to a class’s variables, but you can also subscribe to them, which means that when the value of a variable changes, an event is generated (Module Key Update). VIs that manage the Module table: