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
Summary of Contents for NETLINX PROGRAMMING LANGUAGE
Page 15: ...Table of Contents xiii NetLinx Programming Language Reference Guide...
Page 16: ...xiv NetLinx Programming Language Reference Guide Table of Contents...
Page 18: ...Introduction 2 NetLinx Programming Language Reference Guide...
Page 76: ...Language Elements 60 NetLinx Programming Language Reference Guide...
Page 106: ...Combining Devices Levels and Channels 90 NetLinx Programming Language Reference Guide...
Page 112: ...Master To Master M2M 96 NetLinx Programming Language Reference Guide...
Page 182: ...Reserved Identifiers 166 NetLinx Programming Language Reference Guide...
Page 204: ...NetLinx UniCode Functions 188 NetLinx Programming Language Reference Guide...
Page 244: ...Appendix B Glossary 228 NetLinx Programming Language Reference Guide...
Page 245: ...Appendix B Glossary 229 NetLinx Programming Language Reference Guide...