Mainline - AMX NETLINX PROGRAMMING LANGUAGE Manual

Mainline

Mainline is the program section executed continuously by the NetLinx Central Controller as long as the
Controller has power.
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 in the following table.
Program Sections
DEFINE_DEVICE
DEFINE_COMBINE
DEFINE_CONSTANT
DEFINE_TYPE
DEFINE_VARIABLE
DEFINE_CONNECT_LEVEL
DEFINE_LATCHING
Not all of the sections listed above are required to create a complete program. In an Axcess system, only
DEFINE_PROGRAM
required. Other sections are required only to support code in one of these two sections, although the
Compiler might require more.
Axcess communication updates occur only between passes through mainline (or after each iteration
through
LONG_WHILE
system to operate properly. NetLinx avoids these constraints by processing network activity through a
separate thread of execution. Bus activity is serviced concurrently with event processing and mainline
execution.
The event processing that previously could occur only through mainline code can now be handled
through code in the
events; 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 runs. In effect, mainline becomes an idle time process.
With the addition of the
program becomes greatly diminished if not totally eliminated. Programs can still be written using the
traditional technique of processing events and providing feedback through mainline code. However,
programs written using the event table structure, provided in the NetLinx system, will likely run faster
and be much easier to maintain.
FIG. 1 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.
NetLinx Programming Language Reference Guide
contains the code known as mainline.
DEFINE_PROGRAM
DEFINE_MUTUALLY_EXCLUSIVE
DEFINE_TOGGLING
DEFINE_CALL
DEFINE_FUNCTION
DEFINE_START
DEFINE_EVENT
DEFINE_PROGRAM
is required. In a NetLinx system, either
loops). This places timing constraints on mainline processing in order for the
section. This provides a more efficient mechanism for processing
DEFINE_EVENT
section for processing events, the role of mainline in a NetLinx
DEFINE_EVENT
or
DEFINE_PROGRAM DEFINE_EVENT
Mainline
is
97