EasyManuals Logo

AMX NETLINX PROGRAMMING LANGUAGE User Manual

AMX NETLINX PROGRAMMING LANGUAGE
246 pages
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Page #113 background imageLoading...
Page #113 background image
Mainline
97
NetLinx Programming Language Reference Guide
Mainline
Mainline is the program section executed continuously by the NetLinx Central Controller as long as the
Controller has power.
DEFINE_PROGRAM contains the code known as mainline.
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.
Not all of the sections listed above are required to create a complete program. In an Axcess system, only
DEFINE_PROGRAM is required. In a NetLinx system, either 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.
Axcess communication updates occur only between passes through mainline (or after each iteration
through
LONG_WHILE loops). This places timing constraints on mainline processing in order for the
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
DEFINE_EVENT section. This provides a more efficient mechanism for processing
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
DEFINE_EVENT section for processing events, the role of mainline in a NetLinx
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.
Program Sections
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

Table of Contents

Questions and Answers:

Question and Answer IconNeed help?

Do you have a question about the AMX NETLINX PROGRAMMING LANGUAGE and is the answer not in the manual?

AMX NETLINX PROGRAMMING LANGUAGE Specifications

General IconGeneral
BrandAMX
ModelNETLINX PROGRAMMING LANGUAGE
CategorySoftware
LanguageEnglish

Related product manuals