Skip to content

Mainline

Mainline is the section of the program that is executed continuously by the NetLinx Master Controller. DEFINE_PROGRAM contains the code known as mainline that is executed continuously as long as the Controller has power. Mainline is where all input (button events, level changes, command/string input, etc.) is processed. After each pass through mainline, NetLinx services the NetLinx bus and updates its internal structures.

NetLinx runs on multiple threads; mainline and event handlers run on parallel threads. Event handlers are defined within NetLinx and operate like mini-mainlines. They contain far less code and run faster than mainline. If an event occurs, and an event handler has been defined for that event, NetLinx bypasses mainline and runs the event handler.

A typical NetLinx program is composed of a number of different sections. Each section defines some aspect of a program such as device definitions, variable declarations, channel characteristics or event processing. The sections that can comprise a NetLinx program are listed below:

DEFINE_DEVICE DEFINE_MUTUALLY_EXCLUSIVE
DEFINE_COMBINE DEFINE_TOGGLING
DEFINE_CONSTANT DEFINE_CALL
DEFINE_TYPE DEFINE_FUNCTION
DEFINE_VARIABLE DEFINE_START
DEFINE_CONNECT_LEVEL DEFINE_EVENT
DEFINE_LATCHING DEFINE_PROGRAM

Not all of the sections listed above are required to create a complete program. Only DEFINE_PROGRAM or DEFINE_EVENT is required. Other sections are required only to support code in one of these two sections, although the compiler might require more.

The event processing is managed through code in the DEFINE_EVENT section. This provides an efficient mechanism for processing events, in that mainline does not have to be traversed to process a single I/O request. A handler can be defined for processing device-specific events as well as providing feedback for the device initiating the event notification. If a handler is present, mainline will not be called to process the event; the handler is called instead. Once the handler completes its execution, the system is ready to process the next input message. When no more messages are pending, mainline is run. In effect, mainline becomes an idle time process.

Note

Even if you do not include any code in mainline (the DEFINE_PROGRAM section), feedback statements from button event handlers are still run as part of mainline.

The illustration below illustrates message and mainline processing as it appears in the NetLinx system. Note that bus servicing is taken care of by a separate process thread (Connection Manager & Message Dispatcher) and therefore is not a task that must follow mainline as in an Axcess system.

Message_and_Mainline_processing

See Also