certificacinoficialcomm-tec

certificacinoficialcomm-tec
Formacin oficial Comm-Tec para obtener el certificado de programador de Sistemas AMX: Manual que prepara para la realizacin de las pruebas de conocimientos mnimos necesarios para la realizacin del seminario.

>>

manual de programacin bsica AMX

Manual de productos Axcess y NetLinx

Pgina 1 de 1

certificacinoficialcomm-tec

Manual de programacin bsica AMX

Advertencia
Este manual est en ingls. Estamos trabajando para tener listo una versin completa en castellano prximamente.

Importante
Durante el presente manual se hace referencia a unos archivos de programacin que puede descargarse en la siguiente direccin: http://www.amx.com/webtraining/intro_amx_prog/code_files/Tutorial_Program_Fil es.zip Necesita el programa NetLinx Studio para practicar las lecciones que encuentra en este manual. Descrgueselo desde aqu. Nota: Si alguno de los vnculos est roto, escriba un e-mail a marketing@comm-tec.es

Table of Contents
Introduction to AMX Programming ............................................................................................................... 4 What is Axcess?.......................................................................................................................................... 4 What is NetLinx? ........................................................................................................................................ 4 The AMX Language Tutorial ..................................................................................................................... 4 Unit 1: Language Basics ................................................................................................................................. 5 Chapter 1 - Simply the Basics......................................................................................................................... 5 Introduction................................................................................................................................................. 5 Format of the language ............................................................................................................................... 5 Statements and compound statements......................................................................................................... 5 Comments within the program.................................................................................................................... 6 Identifiers.................................................................................................................................................... 7 Reserved words........................................................................................................................................... 7 Special characters and operators ................................................................................................................. 7 Chapter 2 - The Definition Sections ............................................................................................................... 8 Starting a new program............................................................................................................................... 8 Defining devices ......................................................................................................................................... 8 Defining constants ...................................................................................................................................... 9 Defining variables....................................................................................................................................... 9 Startup code .............................................................................................................................................. 10 Mainline.................................................................................................................................................... 10 Chapter 3 - Using Input and Output.............................................................................................................. 11 Controlling something over there ............................................................................................................. 11 The device-channel concept...................................................................................................................... 11 All about the channel ................................................................................................................................ 11 Push........................................................................................................................................................... 11 Release...................................................................................................................................................... 12 Push_Device ............................................................................................................................................. 12 Release_Device......................................................................................................................................... 12 Changing the state of a channel ................................................................................................................ 13 ON ............................................................................................................................................................ 13 OFF ........................................................................................................................................................... 13 TOTAL_OFF ............................................................................................................................................ 13 TO ............................................................................................................................................................. 14 PULSE ...................................................................................................................................................... 14 Direct assignment ..................................................................................................................................... 14 Putting input and output together.............................................................................................................. 15 Chapter 4 - Channel Characteristics.............................................................................................................. 16 The parts of an output channel.................................................................................................................. 16 Mutually exclusive.................................................................................................................................... 16 Putting it all to work ................................................................................................................................. 17 Programming feedback ............................................................................................................................. 18 Grouping feedback statements .................................................................................................................. 18 Chapter 5 - Your First Program .................................................................................................................... 20 The program and the panel ....................................................................................................................... 20 Unit 2: Conditionals and Waits..................................................................................................................... 24 Chapter 6 Conditional Expressions............................................................................................................ 24 Introduction............................................................................................................................................... 24 Conditional expressions ............................................................................................................................ 25 The IF statement ....................................................................................................................................... 25 The IF...ELSE set of statements................................................................................................................ 25 Repeating IF...ELSE set of statements...................................................................................................... 26 Nesting...................................................................................................................................................... 26 The SELECT...ACTIVE statement........................................................................................................... 27 Trying it out .............................................................................................................................................. 27 The variable assignment method ........................................................................................................... 28

More Conditional operators ...................................................................................................................... 29 Chapter 7 The Wait Keywords................................................................................................................... 31 Controlling time within the AMX System ................................................................................................ 31 The WAIT list........................................................................................................................................... 31 Multiple Waits .......................................................................................................................................... 32 Special uses of Wait.................................................................................................................................. 33 Naming Waits ........................................................................................................................................... 33 Cancelling, pausing, and restarting Waits................................................................................................. 33 The WAIT_UNTIL keyword .................................................................................................................... 34 Misusing WAIT_UNTIL .......................................................................................................................... 34 Naming and removing Wait_Untils .......................................................................................................... 34 Unit 3: Levels................................................................................................................................................ 35 Chapter 8 Creating Levels ......................................................................................................................... 35 Introduction............................................................................................................................................... 35 What is a level?......................................................................................................................................... 35 Creating levels .......................................................................................................................................... 35 Chapter 9 Using Levels.............................................................................................................................. 38 Reading levels........................................................................................................................................... 38 Making a preset......................................................................................................................................... 38 Using bar graphs ....................................................................................................................................... 38 Connecting levels...................................................................................................................................... 39 Unit 4: Arrays, Strings and Buffers .............................................................................................................. 40 Chapter 10 Arrays and Strings ................................................................................................................... 40 Introduction............................................................................................................................................... 40 Defining arrays ......................................................................................................................................... 40 Accessing and storing array values........................................................................................................... 40 Strings ....................................................................................................................................................... 41 The string expression ................................................................................................................................ 42 Arrays as strings........................................................................................................................................ 42 String lengths ............................................................................................................................................ 42 Sending strings and arrays ........................................................................................................................ 44 ASCII codes.............................................................................................................................................. 44 Integer arrays ............................................................................................................................................ 45 Chapter 11 Working with Arrays............................................................................................................... 46 Grouping Data........................................................................................................................................... 46 Conversion keywords................................................................................................................................ 46 ITOA......................................................................................................................................................... 46 ITOHEX ................................................................................................................................................... 46 ATOI......................................................................................................................................................... 47 Array manipulation keywords................................................................................................................... 47 LEFT_STRING ........................................................................................................................................ 47 RIGHT_STRING...................................................................................................................................... 47 MID_STRING .......................................................................................................................................... 47 Finding strings .......................................................................................................................................... 48 Removing strings ...................................................................................................................................... 48 Uppercase vs. lowercase ........................................................................................................................... 49 Setting uppercase and lowercase............................................................................................................... 49 Chapter 12 Using Buffers .......................................................................................................................... 50 Communicating to the outside world ........................................................................................................ 50 Receiving strings....................................................................................................................................... 50 Creating buffers ........................................................................................................................................ 50 Storing characters ..................................................................................................................................... 51 Retrieving characters ................................................................................................................................ 51 Clearing a buffer ....................................................................................................................................... 52 Conclusion .................................................................................................................................................... 53 Glossary ........................................................................................................................................................ 54

Introduction to AMX Programming

AMX Programming consists of the Axcess programming language and the NetLinx Programming language. Both languages are developed by AMX Corporation to allow control of devices in AMX systems. Axcess was developed in the late 1980s as the programming language for the Axcess system. As system capabilities grew it became obvious that a major revision to the Axcess system and the Axcess programming language was necessary. In the late 1990s AMX introduced the NetLinx system and the NetLinx programming language, a superset of the Axcess programming language.

What is Axcess?
The Axcess system is a microprocessor based control system capable of controlling the simple to the most complex devices. Its basic function is to give you complete control of every device in an AMX system. Through a flexible language, Axcess can be programmed to handle almost any task. Axcess can automatically dim lights, increase volume controls to preset levels, turn on video projectors, and much more. AMX designed the Axcess programming language to be user friendly. Although there are over 90 commands, many are self-explanatory and take little time to master. If you accidentally make a mistake in your programming, the Axcess compiler finds the error and reports it to you. As a result, both minor and major changes in programming can be done quickly and easily. Axcess is not some strange language that only brilliant engineers can decipher. On the contrary, anyone with an average knowledge of computers and presentation devices should be able to understand this programming language without any difficulty.

What is NetLinx?
In the continuing evolutionary process of control systems AMX introduced the NetLinx control system. NetLinx is the most advanced control system developed in that process. The NetLinx system can not only control devices connected directly to its control ports and local control networks but can control and communicate seamlessly to other control systems and devices on Ethernet networks and the Internet. The NetLinx hardware takes the experience gained from more than a decade of Axcess system installations to make a more powerful control system. To enable this giant step in system development the Axcess programming language, the basis of the Axcess control system, was enhanced and supplemented to provide the programming power for NetLinx.

The AMX Language Tutorial

This tutorial takes the approach of teaching the common elements of both the Axcess and NetLinx languages while developing real world AMX control system programs. You will start with the basic commands and simple control scenarios, and progress on to more complex programming as you discover new programming functions and techniques. With the exception of additional keywords and objects in the NetLinx programming language, there are very few differences in many programs. The one thing that must be kept in mind however, is the understanding of which master processor, Axcess or NetLinx, will run the program, therefore which compiler is used to compile the program. Unless specifically noted, any references to the Axcess system and programming language will also apply to the NetLinx system and programming language.

Unit 1: Language Basics Chapter 1 - Simply the Basics

Introduction
This unit will help you start writing AMX programs. By the end of this unit you should be familiar with several concepts: Basic ground rules for writing AMX programs The device channel concept The different sections that make up an AMX program How Axcess executes a program Basic input and output functions Simple feedback. As you progress through the chapters you will develop a simple Axcess program containing these basic features, and you will build on this program in later units.

Format of the language

The AMX languages can be written in a free format, meaning that the source code is independent of tabs and carriage returns. Because of this, it is advised to use a consistent method of code placement in order to make the code more readable. In this manual, an outline format is used; that is, each subsection of a section is slightly indented. For example:
PUSH[PANEL,1] { IF (X = 1) { Y = 2 Z = 3 } }

Statements and compound statements

During programming, most of the keywords and operators require a complete statement. A keyword is a word or series of words that signifies the operation for the system to execute. That keyword and all its parameters form the statement. For example, the keyword to turn a channel on is merely ON. However, the statement to turn on a particular channel is ON[RELAY_CARD,RELAY]. Statements can also involve mathematical or logical operations when operators are used. An operator is a character that performs a specific mathematical or relational function. For example, the operator used to set a variable equal to a value is =. As expected, the statement used to set variable X to the number 5 is X = 5. You will frequently have to group several different statements together into one compound statement. The braces { } are used to enclose this type of statement. Compound statements are used if several statements are to be executed in a situation where program syntax will allow just one. The statements are executed in the sequence in which they are programmed. The number of open braces { and close braces } must be the same in your program. The compiler will point out this error to you if the quantities are different after compiling. Compound statements give you the ability to group multiple statements together into one unit, much like grouping sentences together into one paragraph. The most common example of compound statements occurs with the PUSH keyword. (This keyword is explained in depth later.)
PUSH[PANEL,1] { ON [RELAY_CARD,5] X = 5 }

In this example, when button 1 on PANEL is pressed, relay 5 on RELAY_CARD is turned on. Also, the variable X is assigned the value of 5. The open brace indicates the beginning of the compound statement, and the close brace ends it. If you only needed the relay to be turned on, the statement could have been written like this:
PUSH[PANEL,1] ON [RELAY_CARD,5]

Or if you prefer, braces could be added around the statement to make it easier to read:
PUSH[PANEL,1] { ON [RELAY_CARD,5] }

Since there is one (and only one) statement after the line PUSH[PANEL,1], braces are not needed, but are recommended.

Special operators
Operator {} [] Function Combine several statements into a compound statement. Enclose the device-channel: [device, channel] Enclose the location of a storage space in an array Enclose the instance number for use with a System_Call Enclose a variable to be turned on or off () Parentheses Enclose the expression after an If statement Enclose a mutually exclusive set in the Define section Group a mathematical operation Notes: The uses of braces, brackets, and parentheses cannot be interchanged within the program. Name Braces Brackets

Comments within the program

AMX programming languages allow you to place helpful comments inside your program. A comment is a description or remark that is not considered part of the actual program. Any text after (* and before *) will not be compiled, even if the text is separated over several lines. See the following example:
(* This section will define all the devices used. *) DEFINE_DEVICE VCR = 1 (* Video cassette recorder *) CD = 2 (* Compact disc player *)

You can place any number of comments in your program. However, when the program is compiled, the compiler will pass over these. They have no effect on the actual operation of the program. It is wise to use comments. They are especially helpful in a long program, where you can label each part of the program for future reference. If changes have to be made, you can merely look for the label of the section you need to edit. As illustrated in the next example, descriptions of Push statements are very useful.
PUSH[T_PANEL,1] (* { (* statement(s) } PUSH[T_PANEL,2] (* { (* statement(s) } PUSH[T_PANEL,3] (* SLIDE preset *) *) VHS preset *) *) V_PROJ preset *)

{ (* statement(s) *) }

This will help you find the SLIDE preset, VHS preset, and the V_PROJ preset of the device T_PANEL much faster.

Identifiers
Identifiers are used to denote a device, constant, or variable. For example, T_PANEL could represent an AMX Touch Panel, PLAY could represent the first channel, and CD_SELECT could represent the current compact disc player. The guidelines for identifiers are as follows: They must begin with a letter followed by any combination of letters, numbers, or underscores. No spaces are allowed. o Valid identifiers: CD3, TOUCH_PANEL, VCR3_SELECT o Invalid identifiers: 3VHS, CD PLAYER, *RGB4 The identifier must have less than 26 characters. Identifiers are not case sensitive. For example, Touch_Panel is the exact same identifier as
TOUCH_PANEL

The identifier must be unique. Once you define VHS3, do not choose the same name later for a different identifier.

Reserved words
There are certain words that are reserved as keywords or functions. These are integral to the system and cannot be redefined or used as identifiers. For example, PUSH cannot be used as an identifier, because the system recognizes it as a keyword.

Special characters and operators

There is also a complete set of symbols that are used within the program. These symbols represent a wide variety of characters and operators.

Special Mathematical Operators

Operator () * / % + Function Parentheses Multiply Divide Modulus Add Subtract Operator < > <= >= <> = Function Less than Greater than Less than or equal to Greater than or equal to Not equal to Equal to

Chapter 2 - The Definition Sections

Starting a new program
Now that the ground rules are laid out, you can start writing your first program! When you begin a new program, also referred to as a source code file, in NetLinx Studio you are not given an empty file with which to work. (See the NetLinx Studio Tutorial for more information.) Instead, there are several definition headings to signify what should be defined in each section. The definition sections that are given to you are the following:
DEFINE_DEVICE DEFINE_CONSTANT DEFINE_TYPE (Used in NetLinx programs only.) DEFINE_VARIABLE DEFINE_LATCHING DEFINE_MUTUALLY_EXCLUSIVE DEFINE_START DEFINE_EVENT (Used in NetLinx programs only.) DEFINE_PROGRAM

Feel free to delete any of these headings you do not need, and keep those that you do. If you do not have any statements under one of these headings, your program will not operate any differently. However, you might want to keep the headings there for future reference. Although the definition sections are not used within the main program, they create the materials the main program needs. Devices and their channels are given names, channels are given different characteristics, and variables are formed. Even the immediate startup procedures of the AMX control systems are within a definition section. If you develop a good understanding of the Define statements, you will be able to build an excellent foundation for the main part of your program.

Defining devices
When you start writing a program, you should first label each device in the system. Each device connected to the master must have a unique device number. Card 1 may have device number 1, and card 2 may have device number 2. Any time these device numbers are referenced in the program, the master checks the corresponding device. However, with a long list of devices connected to the control networks, these numbers can be difficult for a programmer to remember. Assigning actual names to these devices is much easier. This is the function of the DEFINE_DEVICE section. It is placed at the beginning of the program, and it lets you name the devices. Whenever you use this device name in your program, the compiler will automatically use the corresponding device number to reference the device. You should start writing your program by first defining the devices in your system. Suppose you have a VCR, a CD player, and a cassette deck, and you are controlling them with the first three cards in an Axcess CardFrame. These cards have device numbers 1, 2, and 3. Additionally, you also want to control a projection screen, some drapes, and lights. Two relay cards, one in slot 4 and one in slot 5, will control these (the first card handles both the screen and drapes). A Touch Panel will be used to control all of these devices. Here is what your DEFINE_DEVICE section should look like:
DEFINE_DEVICE VCR CD CASS RELAY LIGHTS TP = = = = = 1 2 3 4 5 (*AXC-IR/S (*AXC-IR/S (*AXC-IR/S (*AXC-REL8 (*AXC-REL8 #1*) #2*) #3*) #1*) #2*)

Begin writing your program copying the programming sections you see in this tutorial. Open NetLinx Studio and create a new program using the Axcess template.

= 128 (*AXT-CA10 TOUCH PANEL*)

From this point on, you can reference device 1 with the name VCR, device 2 with the name CD, and so on.

Defining constants
Constants are identifiers whose values remain unchanged throughout the entire program. The process of defining them is very similar to defining devices. Assigning a value to an identifier in this section locks that value to the identifier for the entire program, making it possible to use descriptive names instead of just numbers in your program. In your system, the VCR, CD player, and cassette deck devices have channels that activate the various transport functions, such as Play and Stop. As a general rule, Play is usually channel 1 and Stop is channel 2. You could define these channel numbers as constants in your program to make it more readable.
DEFINE_CONSTANT (* TRANSPORT (IR CARD) CHANNEL NUMBERS *) PLAY = 1 STOP = 2 PAUSE = 3 FFWD = 4 REW = 5 (* THE RELAY CARD CHANNEL DEFINITIONS *) SCREEN_UP = 1 SCREEN_DOWN = 2 SYS_POWER = 3 DRAPE_OPEN = 4 DRAPE_CLOSE = 5 DRAPE_STOP = 6 (* THE LIGHT LIGHT_FULL = LIGHT_MED = LIGHT_LOW = LIGHT_OFF = CARD CHANNEL DEFINITIONS *) 1 2 3 4

The value of the constant PLAY is 1. STOP has a value of 2. Both of these values cannot be changed anywhere in the program. Later in your program when you need to activate the Play function of the VCR, you dont have to remember that it is channel 1 of the devicejust use the constant PLAY and the system knows to use channel 1. More than one constant can have the same number. For example, PLAY and FWD can both equal 1. You will probably come across this if two cards do not have the same channels for the same functions. PLAY on the VCR control card might be channel 1, and FWD on the slide control card might also be channel 1. By definition, the same constant cannot reference more than one number. This may seem obvious, but this type of error could work its way into large programs. If you make this mistake, the compiler will notify you with a Duplicate symbol error message upon compiling.

Defining variables
Variables are places to store data that will change as the program is executed. Think of a variable as an anything box; nearly anything can be placed in here. For example, a variable can represent a number. For integers, the numeric range is from 0 to 65,535. If one integer variable is subtracted from another, the result will be positive. (If, however, you do subtract a larger number from a smaller number, the result wraps around at 65,535. For instance, if you subtract 20 from 10, the result is 65,525). Once the system is turned off, variables do not lose their value. If a certain variable equals 3 when the Axcess control system is shut down, it will remain 3 when the system is reactivated. This function has both advantages and drawbacks. It obviously helps when you need the system to retain values for the variables. However, if you need those variables to be reset when the system is turned on, they must be reset manually within the DEFINE_START section. In your first program you will not be using variables, but keep the DEFINE_VARIABLE header because you will be using them in the future. The DEFINE_MUTUALLY_EXCLUSIVE, DEFINE_LATCHING, and DEFINE_TOGGLING sections are also explained later.

Startup code
When the AMX control system is turned on, the program that was last loaded into the system will begin to operate. However, you can tell Axcess to run a series of statements immediately when the system is turned on. These statements are placed under the DEFINE_START header, and they are run only once on power-up. They cannot be executed again until another system power-up. In your program, you may want to reset all three decks to STOP when the system is powered up. Here is what your DEFINE_START section should look like:
DEFINE_START PULSE[VCR,STOP] PULSE[CD,STOP] PULSE[CASS,STOP]

(Pulse is explained later in more detail.) If variables need to be reset to certain values, the statements needed to do this should be in this section. Remember, variables retain their values even if the system loses power.

Mainline
Before you begin the main program, you must have the DEFINE_PROGRAM header. This has no real function except to tell the control system where the actual program begins. It is used simply like this:
DEFINE_PROGRAM (* YOUR PROGRAM STARTS HERE. *)

The DEFINE_PROGRAM header marks the start of what is called mainline. Mainline is the section of the program that actually runs while the Master is operating. Mainline is the heart of the AMX control system program. The most important feature of mainline is that it runs in a continuous loop. Most programming languages have a beginning and an end; they start at the top, continue until they are finished, and quit. Mainline is like a circle: when the Master gets to the end, it goes back to the DEFINE_PROGRAM header and passes through that section again.

Chapter 3 - Using Input and Output

Controlling something over there
The basic idea behind remote control is to do something over here to make something happen over there. In an AMX system, the something over here is usually some kind of control panel, such as a wireless remote control panel or a Touch Panel. The something over there can range from a simple relay to a complex lighting system. In mainline you define what happens when these inputs occur. But how do you get your inputs in the program? How do you generate an output? The answer: you use devices and channels.

The device-channel concept

Everything that an AMX system controls is controlled through a device in the system. Each device communicates to the master through control networks such as AXlink, ICSNet, ICSHub and Ethernet. Most devices, such as a Touch Panel or a relay card, have channels which either accept an input, generate an output, or both. These inputs and outputs are referred to in the program as a device-channel, which is written like this:
[5,1]

This device-channel references channel 1 of device 5. If device names and constants are used instead of numbers, the same reference could look like this:
[VCR,PLAY]

Using device names and constants is obviously much more readable. This concept of the device-channel is the most basic concept of the entire AMX control system, as it is the most common way that the program communicates to the outside world.

All about the channel

Almost all methods of control using an AMX system require the use of channels on devices. Every channel has two aspects: the input function and the output function. When a button is pressed on a control panel, the input function of the button sends an input change to your program. The input change alerts the Master to scan your program for a reference to that input. When there is an input change, the Master passes through the DEFINE_PROGRAM section once to see if the change is referenced. If so, the Master executes the statement(s) in the program associated with the input change. There are six keywords used in conjunction with input changes:
PUSH RELEASE PUSH_DEVICE RELEASE_DEVICE PUSH_CHANNEL RELEASE_CHANNEL

Push
The PUSH keyword is used to find out if a channel has had an input change from off to on, such as when a button is pressed. If the channel has been turned on, the corresponding PUSH statement is activated. The operation or operations following this PUSH statement are only executed once after the channel is turned on.

The PUSH keyword requires two parameters: a device number and a particular channel enclosed in brackets. A device name or constant can be used in place of a literal number. For example:
PUSH[128,1] { Y = 2 Z = 3 }

If PANEL is defined as device number 128, and PLAY is defined as a constant with a value of 1, the following is the same:
PUSH[PANEL,PLAY] { Y = 2 Z = 3 }

Following the PUSH statement is the operation to be executed when the PUSH occurs. If more than one event must happen, a compound statement must follow the PUSH. (See the earlier discussion on compound statements.)

Release
The RELEASE keyword is used in the same way as a PUSH, except that the statements following a RELEASE statement will be executed if the associated channel is released.
RELEASE[PANEL,PLAY] { Y=1 }

Push_Device
PUSH_DEVICE is a system variable containing the number of the device having the channel that was just turned on due to an input change. If a button for device PANEL was pressed, PUSH_DEVICE would be

equal to the device number of PANEL. This variable is set when a channel is turned on, and it remains constant until the end of mainline is reached. If no channel has been turned on, PUSH_DEVICE will contain zero.

Release_Device
RELEASE_DEVICE is a system variable that stores the number of the device containing the channel whose button was most recently released. If a button for device PANEL was released, RELEASE_DEVICE would be equal to the device number of PANEL. This system variable is used in a program in the same manner as PUSH_DEVICE. This variable will have the same value for only one pass through the program.

NOTE: PUSH_DEVICE and RELEASE_DEVICE cannot both have a non-zero value during the same pass through mainline. At least one will always be zero.

Push_Channel
PUSH_CHANNEL is the similar to PUSH_DEVICE, except in this case the channel number that was most

recently turned on is stored inside the variable.

Release_Channel
RELEASE_CHANNEL, stores the channel whose button was most recently released. This system variable is used in a program in the same manner as PUSH_CHANNEL.

NOTE: PUSH_CHANNEL and RELEASE_CHANNEL cannot both have a non-zero value during the same pass through mainline. At least one will always be zero.

Changing the state of a channel

So now you can respond to an input change in your program, and you want it to activate a different device-channel. The next series of keywords allow you to activate channels based on an input change. This activation is called an output change, which is a message to the output function of a channel. The keywords to do this are:
ON OFF TOTAL_OFF PULSE TO MIN_TO

When you use one of these keywords to activate a channel in a device, the device starts the operation that is associated with the channel. For instance, activating channel 5 on a relay card activates relay number 5, whereas channel 5 on an infrared/serial card causes it to generate the infrared pattern it has stored at location 5. Variables can be used as output channels also, but doing so does not actually cause an output change. When a variable is activated as a channel, turning it on gives it a value of 1, and turning it off gives it a value of 0. Following are brief definitions of each of the output change keywords.

ON
The ON keyword simply turns on a channel or variable. If the channel or variable is already on, its status will remain unchanged. Here are two different examples:
ON[1,2] ON[TEMP]

This turns on channel 2 of device 1. This sets the value of the variable TEMP to 1.

A variable is considered on if it contains a nonzero number; in this case, the value is 1. If a variable contains the value zero, it is considered off.

OFF
The OFF keyword turns a channel or variable off. The channel or variable will remain off if it is already off. Here are two different examples:
OFF[1,2] OFF[TEMP]

This turns off channel 2 of device 1. This sets the value of the variable TEMP to zero.

TOTAL_OFF
The TOTAL_OFF keyword acts in the same manner as OFF, except that it also turns off the status of a channel or variable that is in a mutually exclusive set. Mutually exclusive sets are discussed later in this unit.

PULSE
The PULSE keyword turns on a channel or variable for a certain amount of time. Once the time elapses, the channel or variable is turned off. As an example, refer back to the discussion on DEFINE_START. The PULSE keyword was used to activate the three decks Stop function. The duration of this pulse is one halfsecond, but it can be changed if necessary with the SET_PULSE_TIME keyword. The pulse time is measured in tenths of seconds. The default value is one half-second or five tenths of a second. The pulse time remains the same value until it is changed within the program. For example:
SET_PULSE_TIME (12)

This sets the current duration of future pulses to 1.2 seconds.

TO
The TO keyword is used to activate a channel or variable for as long as the corresponding device-channel of its PUSH statement is activated. When the device-channel referenced by the PUSH statement changes from OFF to ON, the TO starts activating the device-channel or variable in the brackets following it. When the device-channel of its PUSH is released, the TO statement stops activating its device-channel or variable. The To keyword has several conditions: It must be used only below a PUSH statement. It cannot be used with the WAIT keyword. (This will be explained later.) It cannot be placed within the DEFINE_START section.

The channel or variable will act under the rules set by DEFINE_LATCHING, DEFINE_MUTUALLY_EXCLUSIVE, and DEFINE_TOGGLING.

MIN_TO
The MIN_TO keyword is used to activate a channel or variable for at least a minimum amount of time or as long as the corresponding device-channel of its PUSH statement is activated. When the device-channel referenced by the PUSH statement changes from OFF to ON, the MIN_TO starts activating the device-channel or variable in the brackets following it. When the device-channel of its PUSH is released, the MIN_TO statement stops activating its devicechannel or variable if the button was held for at least the minimum amount of time as set by the pulse time. The MIN_TO keyword has the same conditions as the TO keyword: It must be used only below a PUSH statement. It cannot be used with the WAIT keyword. It cannot be placed within the DEFINE_START section.

Direct assignment
There is another method of generating an output change, but it does not involve the use of any keywords. Any reference to a device-channel that does not have the keywords Push or Release preceding it is a reference to the output side of the channel. Thus assigning a value directly to a device-channel changes the output of the channel. For example:
[PANEL,1] = 1

This statement will send an output change to channel 1 of device PANEL, telling the channel to turn on since the master interprets any non-zero number as on. Putting this statement in mainline will make the channel be forever on. Using direct assignment is only appropriate in feedback statements. In most other situations, the keywords ON, OFF, and TO are more appropriate.

Putting input and output together

Combining input and output changes into one statement is the basis of most AMX control system programming. Now that you have these tools, you can write the code that can actually accomplish this. On your Touch Panel, you will have button numbers 1 through 5 activate the five transport functions of the VCR: Play, Stop, Pause, Fast Forward, and Rewind. Here is your first section of program code:
PUSH[TP,1] { PULSE[VCR,PLAY] } PUSH[TP,2] { PULSE[VCR,STOP] } PUSH[TP,3] { PULSE[VCR,PAUSE] } PUSH[TP,4] { PULSE[VCR,FFWD] } PUSH[TP,5] { PULSE[VCR,REW] }

In this code, there are actually five separate but similar statements. Examine the first to see how it all fits together. First there is the keyword PUSH, followed by a device-channel reference, in this case [TP,1]. This tells the control system, OK, if channel 1 on device 128 receives an input change from off to on execute the statement that follows. If such an input change occurs, the corresponding PULSE statement executes. The PULSE statement tells the control system, Turn on device 8, channel 1 for 5 tenths of a second, then turn the channel off. You may be wondering where the numbers came from, since the PUSH and PULSE statements have the words TP, VCR, and PLAY. Remember, TP and VCR are identifiers for devices 128 and 8 respectively, and PLAY is a constant with a value of 1. Duplicate the above section for the CD player and the cassette deck, replacing VCR with CD and CASS where needed. Also be sure to use different channel numbers for the Push statements, or one activation of channel 1 could make all three decks play at the same time. Now that you have the transport functions of your decks programmed, you can add the rest of the functions on your panel to the program. But before you do that, you need to learn about the other definition sections: those that define the characteristics of a channel.

Chapter 4 - Channel Characteristics

The parts of an output channel
An output channel actually has two parts, the physical part and the status part (simply referred to as status). The physical part is the device-dependent physical control, such as a relay on a relay card, a button light (lamp) on a button panel, or an infrared pattern in an infrared card. The status is what records the state of the physical part. In most applications, these two parts act exactly the same; when one is on, so is the other. However, you can change the way the status part of an output channel behaves. In this chapter, you will be shown how to change the status behavior, which in turn changes the way a channel reacts when it is activated by the output change keywords. All channels are momentary by default.1 When a momentary channel is activated with a TO keyword, it activates its output and status only as long as the button which activated the TO keyword is pressed. For example, the Focus channel for a certain slide projector is momentary. When the corresponding Focus button is pressed, the slide projector will focus. The projector will continue to do so until the button is released.

Mutually exclusive
Channels can be defined as mutually exclusive. A mutually exclusive group is a set of channels in which only one channel of the set can be turned on at a time. When a channel is turned on in a mutually exclusive set, it activates its physical output as long as the button is pressed. When the button is released, the physical output stops. The status, however, does not work in the same manner. Even after the physical output stops, the status still indicates that the channel is on until another channel in the mutually exclusive set is activated. The status is on to let you know which channel in the set was last activated. This is sometimes called last button pressed feedback. When a channel or variable in this set is activated, all the other members of the set are turned off beforehand. This is called break before make logic. This prevents an accidental activation of more than one channel at the same time, which could cause serious damage to some devices. For example, consider the drape and screen channels of the device RELAY. Since you cannot open and close a drape all at once, and you cannot raise a screen and lower it at the same instant (it could damage some motors if you tried!), only one channel can be turned on at a time. They must be defined as mutually exclusive. When SCREEN_UP is activated, the SCREEN_DOWN channel is turned off and SCREEN_UP turns on. The corresponding SCREEN_UP status stays on even though the relay is de-energized when the button is released. When SCREEN_DOWN is activated, SCREEN_UP is turned off. The SCREEN_DOWN status is now the only status turned on. You also will define the lighting relays as mutually exclusive so that you can utilize the last button pressed logic when you program the feedback for these buttons. This will allow the user to look at the panel and know which lighting preset he or she activated last. Members of a mutually exclusive set are placed in parentheses underneath the DEFINE_MUTUALLY_EXCLUSIVE keyword. The double period (..) shortcut is used to indicate a range of channels. For example:
DEFINE_MUTUALLY_EXCLUSIVE ([RELAY,SCREEN_UP],[RELAY,SCREEN_DOWN]) ([RELAY,DRAPE_OPEN]..[RELAY,DRAPE_STOP]) ([LIGHTS,LIGHT_FULL]..[LIGHTS,LIGHT_OFF]) ([VCR,PLAY]..[VCR,REW]) ([CASS,PLAY]..[CASS,REW]) ([CD,PLAY]..[CD,REW])

Actually, the correct terminology here is the status of all channels is momentary by default. However, in the common language of programmers, status is understood. From this point on in the manual, the behavior of status will be described in this manner.

The first set defines the two screen channels as mutually exclusive. Using the shortcut, the second set defines the three drape channels as mutually exclusive, and the third set defines the four lighting relays as mutually exclusive. The fourth through the last sets also use the shortcut to define the five transport functions as mutually exclusive. This is done to achieve last button pressed status for those decks. When you add the feedback statements to the program, the buttons for the VCR, CD player, and cassette deck will indicate the last button selected from each group. Once a channel has its status turned on in a mutually exclusive group, there will always be one channel with its status on in that group, unless it is turned off with the TOTAL_OFF keyword.

Putting it all to work

Now that you know just how all these different types of channels operate, you can skip down to the mainline section of the program and add these lines to activate your system power, screen, drape, and lighting relays:
PUSH[TP,31] { ON[RELAY,SYS_POWER] } PUSH[TP,32] { OFF[RELAY,SYS_POWER] } PUSH[TP,33] { TO[RELAY,SCREEN_UP] } PUSH[TP,34] { TO[RELAY,SCREEN_DOWN] } PUSH[TP,41] { TO[RELAY,DRAPE_OPEN] } PUSH[TP,42] { TO[RELAY,DRAPE_CLOSE] } PUSH[TP,43] { TO[RELAY,DRAPE_STOP] } RELEASE[TP,43] { OFF[RELAY,DRAPE_STOP] } PUSH[TP,45] { TO[LIGHTS,LIGHT_FULL] } PUSH[TP,46] { TO[LIGHTS,LIGHT_MED] } PUSH[TP,47] { TO[LIGHTS,LIGHT_LOW] } PUSH[TP,48] { TO[LIGHTS,LIGHT_OFF] }

This section accomplishes several tasks:

A press of the System Power On button turns on the SYS_POWER channel on the device RELAY. A press of the System Power Off button turns off the SYS_POWER channel on the device RELAY. A press of the Screen Up button turns on the SCREEN_UP channel on device RELAY, after turning off SCREEN_DOWN. The Screen Down button acts the same way as the Screen Up button, but with the opposite channels. Pressing Drape Open, Drape Close or Drape Stop does several things. If it is off, it makes sure the other drape channels are off (due to its mutually exclusive relationship), then it turns on. When the Drape Stop button is released it turns off the DRAPE_STOP relay on the relay device, but its status(feedback) remains on. (Remember, to turn off the status of a channel in a mutually exclusive group, use the keyword TOTAL_OFF.) Since the LIGHTS channels are mutually exclusive, a press of the Lights Full button turns on the LIGHT_FULL channel on the device LIGHTS, after turning off any LIGHTS channel that was previously on. The other LIGHTS channels operate in a similar fashion.

Programming feedback
So far you have been shown how a channels output is affected in a program. You know what to do with the input changes and how to create output changes, but now you want to see some feedback on your control panel. Feedback refers to the lighting of a button during and after it is pressed. The master will not do this automatically; you must tell the system how to light the button. Feedback involves only one statement per button. The first part of the statement references the device-channel of the button that is going to be lit. It is followed by an equal sign (=) and the device-channel corresponding to the source of the feedback. For example:
[TP,1] = [VCR,PLAY]

When VCR channel 1 (the constant value of PLAY) is on, the light of TP button 1 will also be on. When the channel is off, the light will be off. Remember that any reference to a device-channel that does not have the keyword Push or Release preceding it is referring to the output side of the channel. This is a very important concept, because it is the basis of how feedback works. Also recall that one way of creating an output change is to assign a value directly to the device-channel. If the value that you are assigning is another device-channel reference, this is in effect saying to the system, Take the output status of channel PLAY on device VCR, and send it as an output change to channel 1 of device TP. Since you defined the device-channel [VCR,PLAY] as being in a mutually exclusive group, its status will be on if it was the last channel activated in that set, and the feedback assignment will light button 1 on the control panel. Once a channel has feedback on in a mutually exclusive group, there will always be one channel with feedback on in that group, until turned off with TOTAL_OFF.

Grouping feedback statements

The feedback statement is sometimes found after the end of a Push statement. For example:
PUSH[TP,1] { PULSE[VCR,PLAY] } [TP,1] = [VCR,PLAY]

When TP button 1 (Play) is pressed, both VCR channel 1 (PLAY) and the Feedback (output) of the button are turned on. Notice that the feedback statement is outside of the PUSH statement. This is a very important concept. If the feedback statement is included in the PUSH statement it would not operate as desired, but would show the feedback of the last PUSH not the current state. The feedback statements can also be grouped together in a feedback section at the end of the program. For example:

[TP,1] = [VCR,PLAY] [TP,2] = [VCR,STOP] [TP,3] = [VCR,PAUSE]

This feedback section will act no differently if each statement is placed under its corresponding PUSH statement. Where you locate your feedback statements inside your program makes no difference to the operation of the system, but it does make a difference in the readability of your program. Grouping all of the feedback statements at the end of the program is fine, but in larger programs it can be a hassle to skip from the top where the PUSH is located to the bottom where the feedback statements are located. Smaller programs, however, may be easier to manage if all the PUSH statements are together and all the feedback statements are together. A good compromise is to break your program into sections of code where each section has a similar group of functions, and put the feedback statements for each section right below it.

Chapter 5 - Your First Program

The program and the panel
This chapter contains your first finished program and a drawing of the control panel layout. On the next few pages is the entire source code for the program you developed in this unit. Notice that in this system, all of the feedback is at the bottom. If your program does not look exactly like this one, dont worry! Ten people could write the same program and none would look exactly the same. What is important is that it operates the way in which you intend.

PROGRAM_NAME='STEP1' (* DATE:03/15/02 TIME:12:00:00 *) (***********************************************************) (* DEVICE NUMBER DEFINITIONS GO BELOW *) (***********************************************************) DEFINE_DEVICE VCR CD CASS RELAY LIGHTS TP = = = = = 1 2 3 4 5

= 128

(***********************************************************) (* CONSTANT DEFINITIONS GO BELOW *) (***********************************************************) DEFINE_CONSTANT (* TRANSPORT CHANNEL NUMBERS *) PLAY = 1 STOP = 2 PAUSE = 3 FFWD = 4 REW = 5 (* THE RELAY CARD CHANNEL DEFINITIONS *) SCREEN_UP = 1 SCREEN_DOWN = 2 SYS_POWER = 3 DRAPE_OPEN = 4 DRAPE_CLOSE = 5 DRAPE_STOP = 6 (* THE LIGHT LIGHT_FULL = LIGHT_MED = LIGHT_LOW = LIGHT_OFF = CARD CHANNEL DEFINITIONS *) 1 2 3 4

(***********************************************************) (* VARIABLE DEFINITIONS GO BELOW *) (***********************************************************) DEFINE_VARIABLE (***********************************************************) (* LATCHING DEFINITIONS GO BELOW *) (***********************************************************) DEFINE_LATCHING (***********************************************************) (* MUTUALLY EXCLUSIVE DEFINITIONS GO BELOW *) (***********************************************************) DEFINE_MUTUALLY_EXCLUSIVE ([RELAY,SCREEN_UP],[RELAY,SCREEN_DOWN]) ([RELAY,DRAPE_OPEN]..[RELAY,DRAPE_STOP]) ([LIGHTS,LIGHT_FULL]..[LIGHTS,LIGHT_OFF]) ([VCR,PLAY]..[VCR,REW]) ([CASS,PLAY]..[CASS,REW]) ([CD,PLAY]..[CD,REW]) (***********************************************************) (* STARTUP CODE GOES BELOW *) (***********************************************************) DEFINE_START PULSE [VCR,STOP] PULSE [CD,STOP] PULSE [CASS,STOP]

(***********************************************************) (* THE ACTUAL PROGRAM GOES BELOW *) (***********************************************************) DEFINE_PROGRAM PUSH[TP,1] { PULSE[VCR,PLAY] } PUSH[TP,2] { PULSE[VCR,STOP] } PUSH[TP,3] { PULSE[VCR,PAUSE] } PUSH[TP,4] { PULSE[VCR,FFWD] } PUSH[TP,5] { PULSE[VCR,REW] } PUSH[TP,9] { PULSE[CD,PLAY] } PUSH[TP,10] { PULSE[CD,STOP] } PUSH[TP,11] { PULSE[CD,PAUSE] } PUSH[TP,12] { PULSE[CD,FFWD] } PUSH[TP,13] { PULSE[CD,REW] } PUSH[TP,17] { PULSE[CASS,PLAY] } PUSH[TP,18] { PULSE[CASS,STOP] } PUSH[TP,19] { PULSE[CASS,PAUSE] } PUSH[TP,20] { PULSE[CASS,FFWD] } PUSH[TP,21] { PULSE[CASS,REW] } PUSH[TP,31] { ON[RELAY,SYS_POWER] } PUSH[TP,32] { OFF[RELAY,SYS_POWER] }

PUSH[TP,33] { TO [RELAY,SCREEN_UP] } PUSH[TP,34] { TO [RELAY,SCREEN_DOWN] } PUSH[TP,41] { TO [RELAY,DRAPE_OPEN] } PUSH[TP,42] { TO [RELAY,DRAPE_CLOSE] } PUSH[TP,43] { TO [RELAY,DRAPE_STOP] } RELEASE[TP,43] { OFF[RELAY,DRAPE_STOP] } PUSH[TP,45] { TO [LIGHTS,LIGHT_FULL] } PUSH[TP,46] { TO [LIGHTS,LIGHT_MED] } PUSH[TP,47] { TO [LIGHTS,LIGHT_LOW] } PUSH[TP,48] { TO [LIGHTS,LIGHT_OFF] } (* FEEDBACK *) [TP,1] = [VCR,PLAY] [TP,2] = [VCR,STOP] [TP,3] = [VCR,PAUSE] [TP,4] = [VCR,FFWD] [TP,5] = [VCR,REW] [TP,9] = [CD,PLAY] [TP,10] = [CD,STOP] [TP,11] = [CD,PAUSE] [TP,12] = [CD,FFWD] [TP,13] = [CD,REW] [TP,17] = [CASS,PLAY] [TP,18] = [CASS,STOP] [TP,19] = [CASS,PAUSE] [TP,20] = [CASS,FFWD] [TP,21] = [CASS,REW] [TP,31] = [RELAY,SYS_POWER] [TP,32] = (1-[RELAY,SYS_POWER]) [TP,33] = [RELAY,SCREEN_UP] [TP,34] = [RELAY,SCREEN_DOWN] [TP,41] = [RELAY,DRAPE_OPEN] [TP,42] = [RELAY,DRAPE_CLOSE] [TP,43] = [RELAY,DRAPE_STOP] [TP,45] = [LIGHTS,LIGHT_FULL] [TP,46] = [LIGHTS,LIGHT_MED] [TP,47] = [LIGHTS,LIGHT_LOW] [TP,48] = [LIGHTS,LIGHT_OFF] (***********************************************************) (* END OF PROGRAM *) (* DO NOT PUT ANY CODE BELOW THIS COMMENT *) (***********************************************************)

Unit 2: Conditionals and Waits Chapter 6 Conditional Expressions

Introduction
While your first program may look complicated at first, it really doesnt show the power of the AMX programming languages. The program is what we at AMX call one-to-one. That means that each button has one and only one function, with no special conditions or considerations. The control panel has a separate section of buttons for each piece of equipment. But suppose you want the same number of functions with fewer buttons. A common solution is to have several groups of buttons with similar functions reduced to one group, with a set of buttons that selects which piece of equipment the buttons control. In your program, you could have one button for each piece of equipment to select each deck, and one set of transport buttons. Your panel could now look like the one below:

You now have fewer buttons than you did before. What you want to happen with this panel is that the user selects the deck with a Select button, then control it with the Transport buttons. This will not be a one-to-one program because the Transport buttons each have three possible functions. In the program you will use conditional expressions to select the correct function of the Transport buttons. Additionally, the System Power has been reduced to one toggling button, which will have its feedback turned on when the system is powered and off when the system is not powered.

Conditional expressions
A conditional expression is used to tell the system whether or not to execute a particular function or functions in the program. Picture yourself walking along a path in the country. Suddenly you come upon a fork in the road. Which way should you go? If you guess, you might become lost. Therefore you judge certain conditions before continuing. Is the left road heading north? Is the right road heading east? This is what the master must do whenever you branch off in different directions in your program. Either the master continues in the direction it is going, or it must jump to a different section. A conditional expression can have one of two results, true or false. In AMX programming, any non-zero value is true and a zero value is false. When the master evaluates a conditional expression, it assigns a 1 for a true result, and a zero for a false result.

The IF statement
The most common keyword in AMX programming that uses conditional expressions is the IF keyword. Every IF statement must be followed by a conditional expression enclosed in parentheses. This provides the beginning of a conditional execution of statements. The structure is as follows:
IF(conditional expression) { Statement 1 }

If the conditional expression is true, the master executes Statement 1 and then continues with whatever statements follow. If the conditional expression is false, Statement 1 is ignored.

The IF...ELSE set of statements

This is similar to the basic IF statement, with the addition of one more branch. If the conditional expression is false, the master executes a function independent of the true conditional expression. For example:
IF(conditional expression) { Statement 1 } ELSE { Statement 2 }

If the conditional statement is true, then Statement 1 is executed. Statement 2, underneath the ELSE statement, is ignored. If the conditional statement is false, then Statement 2 is executed. Remember that Statement 1 is automatically ignored if the expression is false.

Repeating IF...ELSE set of statements

Using IF... ELSE allows two different paths for conditional branching. By repeating the IF... ELSE statements multiple paths can be created. The master will stop conditional evaluation at the first true conditional expression and execute the associated statements. After completion, it goes on to the rest of the program. For example:
IF(Conditional expression) { Statement 1 } ELSE { IF(Conditional expression) { Statement 2 } ELSE { IF(Conditional expression) { Statement 3 } ELSE { Statement 4 } } }

The last ELSE statement placed at the end of the conditional branching operates as a default statement. That is, if the master processor does not find a true IF statement, it executes the final ELSE statement. However, the last ELSE statement is not necessary.

Nesting
Once the master processor is traversing along a branch (for example, Statement 1 above), you can tell it to branch off again with another IF statement. This branch within a branch is called nesting. An IF can be within an IF within an IF, and so on. The only restriction is the amount of memory available. When you are nesting IF... ELSE statements, be sure to use braces. Look at the following incorrect example:
IF(X = 5) Statement 1A IF(Y = 10) Statement 1B ELSE Statement 2

You can see by the alignment of the ELSE statement with the IF(X = 5) that these two should be associated. The second IF statement is not supposed to have an ELSE counterpart in this example. However, such is not the case. The master pairs the second IF statement with the ELSE, because the compiler associates the ELSE with the closest IF statement. With braces, you can force the compiler to associate the ELSE with IF(X = 5). For example:
IF(X = 5) { Statement 1A IF(Y = 10) Statement 1B } ELSE Statement 2

By using the braces, you isolate the IF(Y = 10) statement from the IF... ELSE set of statements.

The SELECT...ACTIVE statement

There is a way to make nesting easier: the SELECT...ACTIVE statement. This allows the easy placement of several branches from one path. Here is the format:
SELECT { ACTIVE(conditional expression 1): { Statement 1 } ACTIVE(conditional expression 2): { Statement 2 } ACTIVE(conditional expression 3): { Statement 3 } (* ...etc. *) }

Each one of the conditional expressions, in order, is evaluated until one is found to be true. The statements associated with that true expression are then executed, and the path then flows to whatever statements follow the closing brace. Using a SELECT...ACTIVE is much preferred to multiple IF...ELSE statements; it uses less memory and it runs faster. If too many IF...ELSE statements are chained together, they can overflow the Master processor memory and crash the entire system. Obviously it is much better to use SELECT...ACTIVE in such situations. When using the IF...ELSE set of statements, the code following the ELSE is the default statementif the condition of the IF is false, the default statement following the ELSE is executed. So what happens in a SELECT...ACTIVE if none of the conditions evaluate as true? In such a case, no code of any Active statement will be executed, since SELECT...ACTIVE has no default statement. You can, however, create your own default for a SELECT...ACTIVE:
SELECT { ACTIVE(conditional expression 1): { Statement 1 } ACTIVE(conditional expression 2): { Statement 2 } ACTIVE(conditional expression 3): { Statement 3 } ACTIVE(1): { Default statement } }

Here, the last ACTIVE will always be true (remember in AMX programming a 1 is true and a 0 is false), and will execute only if all of the conditions of the previous ACTIVEs are false. This makes the last ACTIVE statement the default statement.

Trying it out
Now you can write the code for your new panel layout. Before you do, however, you will need to update your definition sections a little. The preferred method of implementing select groups is to use one variable and change its value based on which deck is selected.

The variable assignment method

This is the preferred method of programming select groups. Assigning different values to one variable depending on what is selected. This method is actually more powerful than other methods, as it provides more flexibility while using a lot less code. First add just one variable, DECK to the program you wrote previously (or STEP1.AXS). This will be the select variable. How you define this variable depends upon whether you are programming for an Axcess master or a NetLinx Master. For a NetLinx master you will define the variable to contain NetLinx device address information by using the DEV keyword as shown below: Axcess
DEFINE_VARIABLE DECK

NetLinx
DEFINE_VARIABLE DEV DECK

To this variable you will assign the device number of your currently selected deck. Here is your Select buttons code:
PUSH[TP,1] { DECK=VCR } PUSH[TP,2] { DECK=CD } PUSH[TP,3] { DECK=CASS }

You can reduce the number of transport sections from three to just one by using the variable DECK as the device number in the TO statements, instead of using VCR, CD, and CASS. Heres the section of code:
PUSH[TP,17] { TO [DECK,PLAY] } PUSH[TP,18] { TO [DECK,STOP] } PUSH[TP,19] { TO [DECK,PAUSE] } PUSH[TP,20] { TO [DECK,FFWD] } PUSH[TP,21] { TO [DECK,REW] }

Notice that no IF statement is necessary, no mutually exclusive variables are necessary, and this is the only deck transport section of programming needed in the whole program! But how does this work? Suppose you want to play the CD player. First you press the CD Select button. This assigns the value 2 (the constant value of CD) to the variable DECK. Now the device-channel references of the TO transport statements will reference device number 2 (the CD device). Pressing button number 17 on the Touch Panel will activate [DECK,PLAY], which the master will interpret as [2,1]. The feedback for the transport section works in the same manner as the control section. The feedback statements use the DECK variable as the device from which to get the feedback. These statements for the selection buttons, however, are something new:

[TP,1] = (DECK=VCR) [TP,2] = (DECK=CD) [TP,3] = (DECK=CASS)

These statements, like all feedback statements, are direct assignment output changes; however, the source of the assignment is a conditional expression. In interpreting this kind of feedback statement, the master first evaluates the conditional expression. If the expression is evaluated as true, the expression is replaced with a 1; otherwise it is replaced with a zero. (Remember, only one of these will be evaluated as true because a variable cannot have two different values at one time.) Thus the direct assignment will assign a 1 (on) to the Touch Panel button for which the expression is true, and a zero (off) to the false ones. Recall that assigning a 1 to a device-channel is the same as turning the output of a device-channel on

Conditional Operators
The previously discussed IF and IF...ELSE statements can only base the program flow on one condition. You can, however, combine two of these conditions with a conditional operator. This operator sets the rules for determining the end result. The conditional operators used in AMX systems are AND, OR, XOR, and NOT. These are placed in between the two conditions after the IF statement. For example:
IF((X = 10) AND (Y = 5)) { Statement 1 }

If the end result of the conditional expression is true, the system continues with Statement 1. If the end result is false, the system simply ignores Statement 1. The conditional operators can be abbreviated in your program as shown below:

Conditional Operator Abbreviations

Abbreviation && || ^^ ! Function Logical AND Logical OR Logical XOR Logical NOT Abbreviation & | ^ ~ Function Bitwise AND Bitwise OR Bitwise XOR Bitwise NOT

In most conditional expressions, the possible conditions of two statements are analyzed to achieve one result. A text formula can be followed to find that result: If <condition 1> is <its condition (true or false)> < conditional operator> <condition 2> is <its condition>, then the result of the expression is <result of statement conditions>. The result is found by basing the conditions of the statements against the rules set by the conditional operator. Here are those specific rules: AND Both statements must be true for the result to be true. OR At least one of the conditions must be true for the result to be true. XOR Only one statement can be true for the result to be true. NOT If the statement is true, the result is false. On the contrary, if the condition is false, the result is true. This expression uses only one statement.

Consider the following IF statement:

IF((NUM1 = 5) AND (NUM2 = 4))

Assume that it has been previously defined that NUM1 = 5 and NUM2 = 3. Insert the variables from the example into the text formula: If NUM1 = 5 is true and NUM2 = 4 is false, then the result of the expression is false. The statement would have been true if NUM2 had been equal to 3, because in an AND expression both statements must be true. We can use the NOT operator to allow us to program the single power button on this touch panel layout. Since the state of an output channel can be on (1) or off (0), using the NOT operator on a device channel will change its state from off to on or on to off. The code for this button is shown below:
PUSH[TP,31] { [RELAY,SYS_POWER] = NOT[RELAY,SYS_POWER] }

Each press of the button will toggle the state of the SYS_POWER relay. The feedback for this button will track the state of the relay channel:
[TP,31] = [RELAY,SYS_POWER]

Chapter 7 The Wait Keywords

Controlling time within the AMX System
Within the AMX system, there are a variety of timing keywords available for your use. Functions can be delayed for a few seconds, or they can be delayed until certain conditions are right. This chapter will help you learn each of these keywords and show you how to apply them to your programs. You will build on your previous program (STEP2.AXS), but this time you will not be changing the layout of your Touch Panel; youll just add more functions to the existing buttons.

The WAIT List

The most common keyword relating to time is the WAIT keyword, which is used to activate functions after a specified delay time has elapsed. The program flow does not stop when a WAIT is encountered. Instead, the master places the statement associated with the WAIT keyword into a list in memory and continues on with the rest of the program. After each pass through the program, the master scans this list, and if any WAITs have come due, the master executes the statement or compound statement associated with the expired WAIT keyword. Up to 50 WAIT references are allowed in the list at a time. (Refer to the Axcess Programming Guide for a complete discussion of mainline and the Axcess bus.) Time in the WAIT list is measured in tenths of a second. A WAIT of 10 is one second, a WAIT of 15 is one and a half seconds, a WAIT of 20 is two seconds, and so on. Suppose in your system you have two relays controlling system power. One is for the audio amplifier, and the other is for the rest of the equipment (well call that rack power). In many cases, a time delay is desired between powering up the source equipment and powering up the audio amplifier. The reason is that if both are powered up at the same time, there is sometimes a loud pop over the audio system from the source equipment; but if there is a delay, the source equipment is already on and there will be no pop when the amp is turned on. In most cases a one half-second delay is enough. In your program, you will first add a constant definition for your new relay and change the name of the existing system power relay to RACK_POWER. If you use relay 7 (the next available relay on the card), the line to add to the DEFINE_CONSTANT section looks like this:
AMP_POWER = 7

You will also change the constant identifier SYS_POWER to RACK_POWER. As for the System Power button, you want the rack power to come on first (relay 3) when the power is turned on; one half-second later, the amp power should turn on. When you turn the power off, you want the reverse to happen. Heres the new code for the System Power button:
PUSH[TP,31] { IF([RELAY,RACK_POWER]) { OFF[RELAY,AMP_POWER] WAIT 5 OFF[RELAY,RACK_POWER] } ELSE { ON[RELAY,RACK_POWER] WAIT 5 ON[RELAY,AMP_POWER] } }

First, look at the organization of this set of statements. Here is a simplified outline of the structure of this code:
PUSH[TP,31] { IF (device-channel) compound statement ELSE compound statement }

From this simpler outline you can more easily examine what is happening here. Following the PUSH statement is a single IF...ELSE statement which has only a device-channel reference for its condition. In this case the master checks that channels status. If it is on, the master evaluates the condition as true and executes the first compound statement. Otherwise the compound statement following the ELSE is executed. The first compound statement, which is executed if the rack power is on, uses a WAIT to accomplish a time-delayed powering-down of the system. The first statement inside the compound statement turns off the amplifier relay. The next statement is a WAIT statement for five-tenths of a second (same as one half-second), followed by an OFF statement to the rack power relay. The master places this WAIT into the WAIT list and continues with the program. Since these statements are part of an IF compound statement, the master does not execute the compound statement following the ELSE. As the system continues to run, the WAIT is still in the Wait list. After one half-second has elapsed, the master will execute the statement immediately following the WAIT, which in this case turns off the rack power. The corresponding WAIT is then taken out of the list. The compound statement following the ELSE is nearly the same as the one just described; its functions are just slightly different. The master first turns on the rack power, waits a half-second, and then turns on the amp power.

Multiple Wait Statements

Now that you know how to delay an action for a specific amount of time, you can add a little pizzazz to your system. Suppose you want a series of several events to happen when you press just one button. At this point, the System Power button completes just two events with a delay in between. Now you will make the System Power button accomplishes several more things when the power is being turned on and off. Suppose that when the power is being turned on, you want a series of timed events to take place. First, the rack power comes on as before. At the same time, the screen starts to come down and the drapes start to close. One half-second later, the amp power comes on, just like before. Twenty seconds after the button is pressed, the Medium lighting scene is selected. When the power is turned off, a different sequence happens. First the amp power is turned off, lights go to the Full setting, the screen is raised, and the drapes are opened. One half-second later the rack power turns off. Two minutes later the lights go to the Off setting. Here is the code for the System Power Push for the described scenario:
PUSH[TP,31] { IF ([RELAY,RACK_POWER]) (* power being turned off *) { OFF[RELAY,AMP_POWER] TO[LIGHTS,LIGHT_FULL] TO[RELAY,SCREEN_UP] TO[RELAY,DRAPE_OPEN] WAIT 5 OFF[RELAY,RACK_POWER] WAIT 1200 PULSE[LIGHTS,LIGHT_OFF] } ELSE (* power being turned on *) { ON[RELAY,RACK_POWER] TO[RELAY,SCREEN_DOWN] TO[RELAY,DRAPE_CLOSE] WAIT 5 ON[RELAY,AMP_POWER] WAIT 200 PULSE[LIGHTS,LIGHT_MED] } }

Notice the use of the PULSE keyword. This is done, as you may recall, because TO cannot be used inside a Wait. Since the lighting buttons are momentary, you use a Pulse to actuate the relay for just a moment. Waits can appear inside other Waits. This is called nesting Waits. You dont need to nest Waits in your program here, but here is how it is done:
WAIT 200 { ON[RELAY,SCREEN_UP] WAIT 200 OFF[RELAY,SCREEN_UP] }

In this example, the system would wait twenty seconds, turn on the Screen Up relay, wait twenty more seconds, then turn off the Screen Up relay. Any timed sequence of events can be accomplished with or without nested Waits. Using nested Waits is in many cases more readable than non-nested Waits. Nonnested Waits, however, use less code. Here is the same example without nesting:
WAIT 200 ON[RELAY,SCREEN_UP] WAIT 400 OFF[RELAY,SCREEN_UP]

Special uses of Wait

Any one Wait can only be placed in the Wait list once. If a particular Wait is already in the Wait list, it cannot be placed into the list a second time until the first instance is either cancelled or expired. For instance, suppose the following line appears in mainline where it will be executed every pass through mainline:
WAIT 5 FLASH = NOT FLASH

The first time this is executed, the Wait is placed into the Wait list. But what if this line is executed again before the Wait expires? Since the Wait is already in the Wait list, the line is simply ignored. One halfsecond after the first execution of this statement, the value in variable FLASH is inverted; if it was zero it will be changed to 1, and if it was non-zero it will be changed to zero. On the next pass through mainline, the Wait will again be placed into the Wait list and the cycle will repeat for the duration of the program. This in effect creates a variable whose state inverts every half-second.

Naming Wait Statements

When a Wait is given a unique name, it can be cancelled, paused, or restarted. To name a Wait, simply place a name in single quotes after the Wait statement. For example:
WAIT 30 DELAY

Once DELAY is entered into the list, it cannot be re-entered until the first has been removed (cancelled or expired). There are certain considerations in naming Waits: They should not be previously defined constants or variables. They cannot be names that have already been assigned to buffers or subroutines They can contain spaces, unlike other identifiers.

Canceling, Pausing, and Restarting Wait Statements

Once a WAIT is named, it can be manipulated within the program with several keywords. PAUSE_WAIT places a WAIT on hold. The WAIT does not continue counting down until it is resumed with RESTART_WAIT. The WAIT then continues from where it was paused. CANCEL_WAIT completely nullifies a Wait, removing it from the Wait list. CANCEL_ALL_WAIT nullifies every WAIT currently in the list. The keywords PAUSE_ALL_WAIT and RESTART_ALL_WAIT act the same as PAUSE_WAIT and RESTART_WAIT, except they affect all WAIT in the WAIT list, named and unnamed. You could use a named WAIT in your System Power PUSH routine. Suppose the user just turned off the power. The program now has a two-minute WAIT in the WAIT list for the lights to go off. If the user turns the power back on before this WAIT executes, the power-on sequence will start, but the events of the

LIGHT_OFF WAIT will still happen! The user could end up in a very dark room, which is definitely not what he or she wanted. In this case it would be advantageous to name that WAIT and cancel it in the poweron section of the PUSH. To do this, simply add the WAIT name to the WAIT in the power-off section like

this:
WAIT 1200 LIGHTS OFF PULSE [LIGHTS,LIGHT_OFF]

To cancel the Wait in the power-on section, simply add this line:
CANCEL_WAIT LIGHTS OFF

The WAIT_UNTIL Keyword

The WAIT_UNTIL keyword is not a true timing keyword; the system does not wait for a certain amount of time to elapse. Instead, it checks to see if a condition is true. When the condition becomes true, the master executes the statements listed directly below the WAIT_UNTIL statement. All WAIT_UNTIL statements go into another list very similar to the Wait list, called the WAIT_UNTIL list. Just as it does with WAIT statements, each pass through mainline the master checks to see if any WAIT_UNTIL conditions have become true. For each one that has, the system immediately executes the sequence below the WAIT_UNTIL statement. If not, the system keeps the WAIT_UNTIL in the WAIT_UNTIL list until its condition becomes true.

Misusing WAIT_UNTIL
Since the system only checks the status of pending WAIT_UNTILs after completely running mainline, make sure that the condition has a chance to become true, or you will defeat the purpose of the WAIT_UNTIL statement. You dont need WAIT_UNTIL in your program yet, but this program segment illustrates the misuse of WAIT_UNTIL:
WAIT_UNTIL (Y=4) { (* statements *) } Y=4 Y=3

As you can see, Y will never equal four at the end of the program. The WAIT_UNTIL in this case is completely useless. It would be hard to make this mistake in a small program such as the one you are working on, but this problem could make its way into a fairly large program. The compiler cannot detect this sort of error, so make sure each WAIT_UNTIL statement can become true one way or another.

Naming and removing Wait_Untils

In the same manner as a Wait, a WAIT_UNTIL can be named. To do this, a name in single quotes is placed at the end of the statement. Once a WAIT_UNTIL has a name, it can be cancelled with the CANCEL_WAIT_UNTIL keyword, which removes it from the WAIT_UNTIL list. The CANCEL_ALL_WAIT_UNTIL keyword removes all WAIT_UNTILs from the WAIT_UNTIL list.

Unit 3: Levels Chapter 8 Creating Levels

Introduction
So far, you have used channels in devices to interact both with the user and with what he or she wants to control. Channels, however, are not the only method of controlling some devices, such as volume control, voltage generator, and pan/tilt control devices. Devices such as these use levels to interface with the outside world. Also, several control panels have bar graph displays capable of displaying a level. This unit will show you how to create, read, and modify these levels, plus show you how to use bar graphs and sliders on some of these devices.

What is a level?
An input/output (I/O) channel in AMX control systems is usually digital in nature; that is, it can only have an on or an off state. Several devices, such as the volume control card and the pan/tilt control card, have analog input and/or output capabilities. An analog input or output may have many different states. Devices using analog I/O internally store the values relating to the state of each of these analog inputs and outputs; these values are called levels. On a volume card, levels relate to the volume levels of the card. Levels can be used to tell a pan/tilt control card where to position a camera, or tell a voltage generator card the amount of voltage to generate. Imagine that a volume control card has two volume knobs: one for the left speaker and one for the right. Each knob has a range of values from 0 to 255. These knobs represent the two levels present in the volume control card. When a level is discussed in the text, it is usually referring to the value of one of these imaginary knobs.

Creating levels
In most AMX devices levels can have a value between 0 and 255. Level values can be stored in a variable for later use. In order to read a level from a device that supports levels, you use the keyword CREATE_LEVEL. Here is the syntax:
CREATE_LEVEL device, level number, variable CREATE_LEVEL takes three parameters:

The device from which to read the level Which level of the device to read (some devices have many different levels) The variable in which to store the level

This keyword creates an association between the specified level of the device and the specified variable. During execution of your program, the master will continually update the variable to contain the value of the level with which it is associated. Since this association only needs to be done once, this keyword is only allowed to appear in the DEFINE_START section of your program. In this unit, you will develop a new program that handles levels. This system will contain a volume control card to control a volume level, and a Touch Panel for the user to control the volume card. On the Touch Panel, there will be four buttons: Volume Up, Volume Down, Volume Mute, and Volume Preset. There will also be a bar graph on the Touch Panel to display and control the volume level.

Here are some code excerpts to get started:

DEFINE_DEVICE VOLUME TP = 1 = 128

DEFINE_CONSTANT (* Three channels to control both outputs together *) V_UP = 1 V_DN = 2 V_MT = 3 DEFINE_VARIABLE VOL_LEVEL PRESET (* This will store the volume level value of the card *) (* This will store the preset level value*)

DEFINE_MUTUALLY_EXCLUSIVE DEFINE_START CREATE_LEVEL VOLUME, 1, VOL_LEVEL

This code defines the devices you will use, a variable in which to store the volume level value, and the statement in the startup code to create the association between level number 1 of the volume card and the VOL_LEVEL variable. It also defines some constants that give names to the different channels available in the volume control card. By turning on and off these channels the user can raise, lower, and mute the volume levels of the card. Here is the code for the Volume Up, Volume Down, and Volume Mute buttons on the Touch Panel:

DEFINE_PROGRAM PUSH[TP,1] { OFF[VOLUME,V_MT] TO[VOLUME,V_UP] } PUSH[TP,2] { OFF[VOLUME,V_MT] TO[VOLUME,V_DN] } PUSH[TP,3] { [VOLUME, V_MT] = NOT[VOLUME, V_MT] } [TP,1] = [VOLUME,V_UP] [TP,2] = [VOLUME,V_DN] [TP,3] = [VOLUME,V_MT]

Notice that the Volume Up and Volume Down buttons will automatically un-mute the volume before starting to ramp the volume up or down. Also, these control channels affect both levels of the volume card simultaneously, ramping both up and down together. This code handles all of the functions of your system except for the bar graph and the Volume Preset button. You will add the code for these in the next chapter.

Chapter 9 Using Levels

Reading levels
When a level is associated with a variable using CREATE_LEVEL, The master continually keeps the variable updated with the value of that level. In your program, as the user ramps the volume level up, the value in VOL_LEVEL increases. When the volume is ramped up to the maximum, VOL_LEVEL will contain 255. The same goes for ramping down; when the volume is muted, the variable will contain zero. (NOTE: AMX volume devices remember the previous level when it is muted so that it can un-mute to that same level..)

Making a preset
Now you are going to add the code necessary to create a preset. A preset is a level stored for later retrieval. What you will do here is give the Volume Preset button a dual role. If the button is pressed and held for two seconds, the current level of the volume card is stored in the variable PRESET. If the button is pressed for less than two seconds, it sends a command to the volume card to set the level of the card to the previously saved level in PRESET. First, here is the code:
PUSH[TP,4] { WAIT 20 VOL_PRESET { PRESET = VOL_LEVEL } } RELEASE[TP,4] { CANCEL_WAIT VOL_PRESET SEND_COMMAND VOLUME, "'P0L', ITOA(PRESET)" OFF[VOLUME,V_MT] } [TP,4] = (PRESET = VOL_LEVEL)

This code uses the WAIT and CANCEL_WAIT keywords to test the amount of time between the PUSH and the RELEASE of the Preset button. If the time is greater than two secondsremember, wait times are measured in increments of one-tenth of a secondthen the current level of the card (stored in VOL_LEVEL) is saved into the variable PRESET. If the button press is less than two seconds the WAIT is cancelled then a command is sent to the volume card to go to the level saved in PRESET, and the volume is un-muted. Note that the feedback for the Volume Preset button is turned on whenever the current volume level equals the value of the PRESET variable.

Using bar graphs

Now you will add the code to continuously display the current level of the volume card on the Touch Panels bar graph. To update a bar graph on a device, you use the SEND_LEVEL keyword. Here is the syntax:
SEND_LEVEL device, level number, value

This keyword is used to update a level in a device. Assume your bar graph display on the Touch Panel has level number 1. In order to keep the display updated continually, you will add the following line into your program (on mainline):
SEND_LEVEL TP, 1, VOL_LEVEL

Since this code resides in mainline it will be executed continually, thus making sure that the bar graph reflects the value of level number 1 of the volume card. As the volume ramps up, VOL_LEVEL increases and the bar graph fills. As the volume ramps down, VOL_LEVEL decreases and the level indicated on the

bar graph also decreases. Since both volume levels are ramping together, you only have to track one of them for the bar graph.

Connecting levels
Touch Panel bar graphs have a unique feature if they are set to the active bar graph type: you can touch and slide the bar graph itself and the level will raise or lower to that point; the level simply tracks the movement of your finger. However, to do this you must set up a connection between the bar graph and the volume level. That is what the keyword DEFINE_CONNECT_LEVEL accomplishes. DEFINE_CONNECT_LEVEL is not a keyword that is used inside mainline, but is actually a definition section like DEFINE_DEVICE or DEFINE_START. When you use it, the best location to place it is immediately following the DEFINE_DEVICE section. Underneath the DEFINE_CONNECT_LEVEL header is where all level connections are listed. Here is how DEFINE_CONNECT_LEVEL is used:
DEFINE_CONNECT_LEVEL (device 1,level number 1,device 2,level number 2,...etc.)

The section inside the parentheses represents a single connection. All levels listed in the connection will follow each other. If any one level changes, all others will change to match. Any number of levels may be supported per connection, and there is no limit to the number of connections. Here is how you would use DEFINE_CONNECT_LEVEL in your program to connect the Touch Panel's bar graph to the volume card's levels:
DEFINE_CONNECT_LEVEL (TP, 1, VOLUME, 1, VOLUME, 2)

This connects level number 1 on the Touch Panel (your bar graph) and levels 1 and 2 on the volume device together. The reason that two levels on the volume card are included is because volume control cards have two levels: the left audio channel and the right audio channel. These connections are a two-way street: anytime the bar graph is changed, both volume levels will follow, and anytime a volume level is changed (probably by the volume control buttons on the Touch Panel), the bar graph will automatically follow. When using DEFINE_CONNECT_LEVEL, it is not necessary to use the SEND_LEVEL keyword in your program since the connection constantly takes care of updating the bar graph.

Unit 4: Arrays, Strings and Buffers Chapter 10 Arrays and Strings

Introduction
In the previous units you developed a program that demonstrates the most common features of the AMX programming languages. In this unit, more advanced concepts will be introduced: arrays, strings, buffers, and two-dimensional arrays. Understanding these concepts and the keywords that go with them will allow you to easily handle data, and will provide another means of communicating with the outside world. In this chapter, you will develop a small example program. For this program, you will need to create a level and assign it to a variable. You will use the variable VOLUME_LEVEL for this. Your control panel will have nine buttons: Volume Up (button 1), Volume Down (button 2), Store (button 3), Preset 1, Preset 2, Preset 3, Preset 4, Preset 5, and Preset 6 (buttons 9 through 14). The Volume Up and Volume Down buttons ramp a volume card up and down. The Store button simply toggles a state on and off. The Preset 1 6 buttons either store or recall a preset, depending on whether the Store button is on or not.

Defining arrays
In the program developed in Unit 2, you used a variable called DECK. This variable could only hold one value at a time. However, if you need a variable to hold several values at once, use an array. An array is a single variable that has more than one storage location. Arrays must be defined as variables within the DEFINE_VARIABLE section of your program. Its definition has two parts: a unique identifier and its storage capacity. The variable must be named using a valid identifier first. (See Chapter 1 for the rules concerning identifiers). Second, the number of storage locations in the array must be indicated; a maximum of 255 locations can be specified for Axcess systems, 65535 locations for NetLinx systems. For your new program, you want to store several preset levels for the volume control card. You could create several individual variables and use IF statements or SELECT...ACTIVE statements to select the preset you want to use. Or even better, you could create an array and use an index value to pick the preset you want to use. Here is your array declaration:
DEFINE_VARIABLE PRESETS[6]

This declares a new variable, PRESETS. The variable PRESETS is an array that can hold six distinct values, as defined by the number 6 inside the brackets.

Accessing and storing array values

To access a particular value in an array, simply refer to the storage location inside the array you wish to retrieve, such as follows:
THE_LEVEL=PRESETS[3]

The number inside the brackets is called the index value. The index value is the number that tells Axcess which location in the array to retrieve, and it must be a number from 1 to 255. This example assigns the

value in the third location of PRESETS to the variable THE_LEVEL. Retrieving a value from an array does not in any way change the array. You can place values into a storage location by setting the particular location equal to the needed value. For example, PRESETS was previously defined as having six locations. If you want the second location to hold a value of 6 you would type the following:
PRESETS[2]=6

The number 6 is placed into the second location. From now on, anytime PRESETS[2] is referenced, its value is 6.

In the example program, pressing a Preset button either stores or recalls a preset. Examine the section of code that accomplishes this:
PUSH[TP,3] { STORE = NOT STORE } [TP,3] = STORE IF((PUSH_CHANNEL >= 9) AND (PUSH_CHANNEL <= 14)) { IF(STORE) PRESETS[PUSH_CHANNEL - 8] = VOLUME_LEVEL ELSE SEND_COMMAND VOLUME_CARD,"'P0L',ITOA(PRESETS[PUSH_CHANNEL - 8]) " }

The first PUSH[TP,3] is the Store button, which simply toggles the STORE variable using the NOT operator. (Remember, NOT inverts the state of whatever follows it.) A feedback statement for the STORE button immediately follows the PUSH statement. The next statement is an If statement which checks to see if PUSH_CHANNEL is greater than or equal to nine, and less than or equal to 14. In other words, the statements inside the conditional statement are executed if one of the Preset buttons is pressed. Inside the conditional statement is another IF statement which uses the state of the variable STORE to determine whether to assign the volume location in the PRESETS array, or to send a command to the volume card telling it to go to a previously stored level. In order to place the variable VOLUME_LEVEL into the array PRESETS at the correct location, 8 must be subtracted from PUSH_CHANNEL to find the index value.

Strings
Many times you may need to reference entire groups of values at once. You can do this by using strings and string expressions. A string is a set of values grouped together with single and/or double quotes. Strings enclosed in single quotes are called string literals. Single quotes can only enclose values ranging from decimal 32 (the space character) to decimal 126 (the tilde character ~). These string literals are constant values that are set at compile time. Once loaded into the master these strings cannot be changed, except when a new program is loaded into the master. Here is an example of assigning a string to an array:
PRESETS='FOUR'

When the master processes this assignment, it places the F (ASCII value 70) in location 1 of PRESETS, O (ASCII value 79) in location 2, and so on. String FOUR is placed in the array PRESETS. Note that an index value is not given when strings are assigned to arrays. The first letter is automatically placed into the first storage location; the second letter is placed into the second storage location; and so on.

The string expression

AMX control system masters interpret single and double quotes in two different ways. Whereas single quotes enclose string literals, double quotes represent a different operation: they enclose string expressions. A string expression combines several types of data into a single string. A string expression can contain any ASCII value (0 to 255), as well as variables, string literals, and arrays. The difference between a string literal and the string expression is that the string expression is built at run time instead of compile time. As the master processes a string expression, it evaluates each member of the expression from left to right, and the result is a complete string. Here is an example:
PRESETS="PLAY,5,0,'NO',X"

Assuming that PLAY is a constant with the value of 1, and X is a variable with the value of 10, the string expression is evaluated as a string with the following values: 1,5,0,N,O,10.. Since the expression is evaluated at run time, whatever value is in the variable X when the expression is evaluated is what is placed into the result.

Arrays as strings
There are two ways of referencing data in arrays within Axcess programs: each location as an individual value, or each array as a group of values. So far you have seen how to access the individual locations. However, an entire array can be accessed as one unit. If you refer to an array without specifying an index value, the contents of the entire array are referenced as a string. Consider the following lines:
DEFINE_VARIABLE S1[10] DEFINE_PROGRAM S1='TEST ONE' SEND_STRING CARD,'TEST TWO' SEND_STRING CARD,S1

This small section of code will send two strings to the card named CARD: first TEST TWO, then TEST ONE. Notice that there are no quotes around the variable S1 in the second SEND_STRING. This is because the variable S1 is an array, and when an array is referenced as a single unit like this, it is considered a string. If you had assigned a string expression to S1 and then sent it to the card, the entire contents of the string expression would be sent. Suppose that during power-up of the Axcess system you want to set all of the presets to default values. You could do this by assigning values to each individual location in the PRESETS array. A better solution, however, is to use a string expression to set all six at once, like this:
DEFINE_START PRESETS = 0,30,90,128,191,255 (* set all preset values at power-up *)

String Lengths
Every array declared in the DEFINE_VARIABLE section has a string length value associated with it. The string length of an array is an internal value set for arrays by string assignment operations. This number is different than the storage capacity declared in the DEFINE_VARIABLE section. You can get this length value of an array by using the LENGTH_STRING function. Here is an example:
Y = LENGTH_STRING(PRESETS)

Here are examples of some assignments, and what the above line of code would return to the variable Y in each case:
PRESETS PRESETS PRESETS PRESETS = = = = 'FOUR' (* Y = 4 *) 'ONE' (* Y = 3 *) "12,5,'123'" (* Y = 5 *) "PLAY,5,0,'NO',X" (* Y = 6 *)

The length of a string array cannot exceed the number of storage locations allocated to it in the DEFINE_VARIABLE section. If the string GOODBYE is placed in the PRESETS variable, the array will only contain the string GOODBY, dropping the final E because PRESETS was defined to hold a maximum of six locations. The length of PRESETS would also be set to 6. Assigning string literals and string expressions automatically sets the length of the string array to the length of the string literal or string expression being assigned to it. However, assigning values to individual elements of an array does not affect the length value of the array. For instance, if the letters W, O ,R, and D are assigned individually to elements of PRESETS as shown below, the length will not change. If the length was previously 3, it will still be 3.
PRESETS[1] PRESETS[2] PRESETS[3] PRESETS[4] = = = = 'W' 'O' 'R' 'D'

There is a way, however, to explicitly set the string length value of an array variable. The SET_LENGTH_STRING keyword accomplishes this. For instance, to set the length value of PRESETS to 4, you would use the following statement:
SET_LENGTH_STRING(PRESETS,4)

After execution, the string length value of the array PRESETS is 4. String lengths play an important role in the handling of strings. Consider this string expression that contains an array in the expression:
"5,PRESETS,'GO'"

As the master constructs a string from this string expression, the number of characters from the array PRESETS it will add will be equal to PRESETS string length value. If PRESETS contains 1,2,3,4,5,6 but its string length value is 3, the resulting string from the above string expression will look like this:
"5,1,2,3,'G','O'"

The string length value of an array is very important to many string operations in AMX Programming. This value determines how much of the string is used when the entire array is referenced as a string. Knowing this will prevent subtle errors from creeping into your code. For instance, if you assign values to individual elements in an array, and then assign that array to another, nothing will actually be copied. Here is an example:
PRESETS[1] = PRESETS[2] = PRESETS[4] = SAVE_PRESETS 5 6 'A' = PRESETS

What do you think the array SAVE_PRESETS will contain after this code is executed? It will totally depend on the length value of the PRESETS variable. If this were the entire program, PRESETS would have a default length of 0, so nothing would be copied into SAVE_PRESETS. In order to assure that SAVE_PRESETS were to hold a copy of PRESETS, you would first need to set the length value of the PRESETS array with this line inserted before the copy statement:
SET_LENGTH_STRING (PRESETS,4)

After this, the length value of PRESETS is 4, so the first 4 locations of PRESETS will be used in all cases where you refer to the entire array.

Sending strings and arrays

To send a string to the outside world, you use the SEND_STRING keyword. Here is the syntax:
SEND_STRING device,<string, variable, or string expression>

The first value after the SEND_STRING keyword is the device number or identifier to which you wish to send the string. Following that is a comma, then the string, variable (which can be either a normal variable or an array), or string expression you wish to send. When an array variable is specified, the number of characters from the array that are sent is determined by the length value for the array. (Remember, you can set that value with the SET_LENGTH_STRING function.) For instance, if you need to send the PRESETS array to a card named RS232, you would write the following line:
SEND_STRING RS232,PRESETS

String literals and string expression can also be sent using SEND_STRING. Here are some examples:
SEND_STRING RS232,'THIS IS A STRING LITERAL' SEND_STRING RS232,"'EXPRESSION ',PRESETS,$0D,$0A"

The first example sends the entire set of characters enclosed in the single quotes, from left to right, to the card named RS232. The second example first builds the string expression using a string literal, followed by however many characters from PRESETS as defined by its length value, and then two numbers expressed here in hexadecimal. (The hexadecimal numbers in the example represent the codes for carriage return and line feed, respectively.)

ASCII codes
As you have learned, a string is broken up into single letters when placed into a string array. Each storage space returns the letter it is holding when referenced. For example, assume that PRESETS[3] holds the letter R. There are actually three ways you can reference this array location (in this example using If statements):
IF(TEMP[3] = 'R') { (* statement(s) *) }

or
IF(TEMP[3] = 82) { (* statement(s) *) }

or
IF(TEMP[3] = $52) { (* statement(s) *) }

The ASCII character R has a value of 82 decimal, which is equivalent to 52 in hexadecimal. In AMX Programming, hexadecimal numbers begin with a dollar sign ($). Therefore, the third example above shows $52, meaning, this number, 52, is a hexadecimal number. All three methodsletters, decimal ASCII codes, and hexadecimal ASCII codescan be used interchangeably. Feel free to use whichever method is easiest for the task at hand.

Integer arrays
So far, in all of the arrays you have seen, the range of values in each location is zero to 255. Recall that the range of values in a single variable is zero to 255, and when a value greater than 255 is assigned to an array location, the number is truncated above 255. For instance, if the number 500 is assigned to a location in an array, the actual number that is assigned is 244. (The way to find this is to keep subtracting 256 from the number until the number is less than 256.) So what could you do if you need to create an array in which each location can contain values greater than 255? The answer is to use an integer array. An integer array is just like a normal array, except that each location can hold values from zero to 65,535. To declare an integer array, simply place the keyword INTEGER in front of the array definition in the DEFINE_VARIABLE section. If you wanted your PRESETS array to be an integer array, here is how you would declare it:
DEFINE_VARIABLE INTEGER PRESETS[6]

This declares an integer array with six locations; each location can hold values from zero to 65,535. There are certain limitations of integer arrays. If an integer array is assigned to a normal array, all values are truncated above 255. (See the earlier discussion on truncating values.) This also happens if an integer array is sent to a device using the keywords SEND_STRING or SEND_COMMAND. There is no problem, however, in assigning a normal array to an integer array. If your array is only going to hold only alphanumeric values, do not make it an integer array.

Chapter 11 Working with Arrays

Grouping Data
The ability to group data into cohesive units (arrays) is one of the more powerful features of the AMX programming languages. Thus there are many keywords to help you manipulate arrays and strings. These keywords can be grouped into two classes: conversion keywords and array manipulation keywords.

Conversion keywords
There are several string conversion keywords available:
UPPER_STRING LOWER_STRING ITOA ITOHEX ATOI

The first two keywords convert a string into all uppercase or all lowercase. The last three serve to convert numberseither as a constant, in a variable, or explicitly definedinto its string representation, and vice versa. The three keywords ITOA, ITOHEX, and ATOI automatically set the length value of the resulting string.

ITOA
ITOA, which is short for integer to ASCII, creates a string that represents the decimal value of a number.

Here are some examples:

DEFINE_CONSTANT CONST = 456 DEFINE_VARIABLE STR[5] VAR DEFINE_PROGRAM VAR = 789 STR = ITOA(123) (* STR = 123 *) STR = ITOA(CONST) (* STR = 456 *) STR = ITOA(VAR) (* STR = 789 *)

The comment after each statement shows the value of the array STR after each assignment. The length value of STR is set to 3 in each case, even though its storage capacity is 5.

ITOHEX
This keyword is short for integer to hexadecimal. ITOHEX works in the exact manner as ITOA, except that the integer is transformed into a hexadecimal ASCII string. If you substitute the ITOA keywords in the previous example with ITOHEX keywords, this would be the result:
STR = ITOHEX(123) (* STR = 76 *) STR = ITOHEX(CONST) (* STR = 1C8 *) STR = ITOHEX(VAR) (* STR = 315 *)

Notice that result does not contain a dollar sign. This is because the dollar sign indicates a numerical value expressed in hexadecimal, and is only used when telling the system that a number is hexadecimal. The result is an ASCII string which contains a representation of the hexadecimal value.

ATOI
The ATOI keyword stands for ASCII to integer and does just that. It takes a string literal, string expression, or array as a parameter, and returns a single integer as the result. Here are some examples:
DEFINE_CONSTANT STR1 = 456 STR2 = YES789GO19 DEFINE_PROGRAM NUM = ATOI('123') (* NUM = 123 *) NUM = ATOI(STR1) (* NUM = 456 *) NUM = ATOI(STR2) (* NUM = 789 *)

If the string contains all non-numeric characters (such as HELLO), ATOI returns the integer 0. However, if there are any numeric characters embedded within the string, ATOI returns the first complete set it comes upon, as is the case with STR2 above. Notice that only the first set of numbers from STR2is returned.

Array manipulation keywords

There are a number of keywords at your disposal that allow you to manipulate arrays and to retrieve certain portions of an array:
LEFT_STRING MID_STRING RIGHT_STRING FIND_STRING REMOVE_STRING

LEFT_STRING
For this keyword, you must specify two parameters: the string or array you are referencing and the number of characters you need. LEFT_STRING returns a string containing the number of characters specified starting at the beginning of the string. Here is an example:
STR = LEFT_STRING (PRESETS,3)

After execution of this line, the array STR will contain the first 3 characters of the array PRESETS. If PRESETS has a length of 5 and contains the string HELLO, then STR will contain HEL. Also, the length value of STR will be set to 3.

RIGHT_STRING
This keyword requires the same parameters as LEFT_STRING. However, RIGHT_STRING begins reading at the end of the string array for the specified amount of characters. Assuming PRESETS still contains HELLO, replacing LEFT_STRING in the previous example with RIGHT_STRING will assign the string LLO to STR. This keyword also will set the length value of the array receiving the result.

MID_STRING
This keyword returns the specified amount of characters starting at a specified location in the source string. Three parameters, rather than two, are needed for its operation: the string to reference, the position at which to start, and the number of characters to return. Here is an example:
STR = MID_STRING (PRESETS,2,3)

This line tells the master: Place three characters from the array PRESETS, starting at location 2 and moving to the right, into the array variable STR. If PRESETS contains HELLO, this line will assign ELL to the array STR. This keyword also will set the length value of the array receiving the result.

Finding Strings
The keywords explained previously are helpful when you know where certain parts of strings are located within a string array. However, there will be many times when you have no idea where to look. In these cases, the FIND_STRING keyword is used. This keyword will search through a string for a specified sequence of characters. As soon as it finds a duplication of the sequence, it returns the beginning position of that duplication. For example, suppose you dont know the exact contents of the PRESETS array, but you want to find out if it contains the string LO. Assume that PRESETS has a length of 5 and contains HELLO and the following line is executed.
X = FIND_STRING (PRESETS,'LO',1)

When the master executes this statement, it will search the array PRESETS from the beginning, looking for the string LO. If the system finds the search string, as in this case it will, it returns the starting position of the search string in the PRESETS array: in this case, 4. The third parameter (in this example, 1) tells the master where in the array PRESETS to start the search.

Removing Strings
The REMOVE_STRING keyword works much like the FIND_STRING keyword. However, when the master finds the sequence it is looking for, it extracts every character up to and including the sequence. All the other characters move up to fill in the space. Here is an example:
DEFINE_VARIABLE SOURCE[20] DEST[20] DEFINE_PROGRAM SOURCE = THIS IS A TEST DEST = REMOVE_STRING (SOURCE,IS,1)

After the last line is executed, DEST will contain THIS and SOURCE will contain IS A TEST. Notice that after the removal, the first location of the array SOURCE contains a space. This is because REMOVE_STRING removed all characters from the beginning of SOURCE up to and including the string IS. It did not remove the space following the string IS in SOURCE. Also notice that the first occurrence of IS is embedded in the word THIS. The length values of both arrays are set according to the results of the operation. In this case, the length value of SOURCE is set to 4, and DEST is set to 10. In FIND_STRING, each of the first two parameters can be a string literal, string expression, or array. However, in the case of REMOVE_STRING, having anything except an array as the first parameter makes no sense because the master cannot remove part of a string literal or string expression, only an array variable. This is because string literals are constant values and string expressions may contain constant values. Once loaded into the master, constant values cannot be changed. Look at these examples:
STR = REMOVE_STRING(PRESETS,12,1) (* OK this works*) STR = REMOVE_STRING(2,HELLO,10,13,HELLO,1) (* NO this doesnt work *)

Remember that REMOVE_STRING changes the first parameter after it removes whatever characters it needs, and only variables can be changed at run time. Also remember to supply the starting position of the search as the third parameter for both FIND_STRING and REMOVE_STRING.

UPPERCASE vs. lowercase

When using FIND_STRING and REMOVE_STRING, as well as when comparing two string values, it is important to remember that such comparisons are case sensitive, which means that uppercase and lowercase values are not evaluated the same. As you recall, the compiler is not case sensitive when it comes to keywords and identifiers. The compiler is case sensitive, however, when it comes to values inside single quotes (string literals). Here are some examples:
DEFINE_PROGRAM Identifier_1 = 'Fred' Identifier_2 = 'FRED' if(IDENTIFIER_1 = IDENTIFIER_2) { (* This will not be true because 'Fred' and 'FRED' are not the same. *) }

Notice that the string literals FRED and Fred are not the same. However, in the case of identifiers IDENTIFIER_1 and IDENTIFIER_2, the compiler makes no differentiation based on the case of the letters making up the identifier name. Also notice that in this example the keyword IF is not capitalized. This also makes absolutely no difference to the compiler.

Setting uppercase and lowercase

Within the system, the lower case letter a is not the same as the upper case letter A. Each has its own decimal ASCII value; the value for a is 97, and the value for A is 65. This could become a problem when, for example, your program compares an incoming string ABC against another:
IF (ABC = 'YES') { (* statement(s) *) }

If the incoming string is YES there is no problem. The statements are executed as expected. However, what if ABC equals Yes? Since YES and Yes do not have the same decimal ASCII value, the statements below the If would not be executed. The solution is to change all incoming strings to either uppercase or lowercase. The keywords that do this are UPPER_STRING and LOWER_STRING. For example, the following statement could have been added before the preceding program:
ABC2 = UPPER_STRING(ABC)

The If statement can now compare ABC2 against YES, providing that the If statement reads IF(ABC2 = YES). The string Yes is accepted since it has been converted into uppercase. As expected, LOWER_STRING converts a string into lowercase in the same manner that UPPER_STRING operates.

Chapter 12 Using Buffers

Communicating to the outside world
One of the most powerful features of the AMX control systems is its ability to send and receive any combination of values using RS-232, RS-422, RS-485, MIDI, and a variety of other formats. You have the ability to construct any combination of numbers and characters with the string expression and send it to an external device. In addition, you can receive strings from external devices and interpret them to obtain useful information.

Receiving strings
Receiving strings requires several more steps than sending strings. To be able to receive strings from a device, you must first create a buffer for that device. A buffer is an array variable that is associated with a particular device for the purpose of storing information received from the device.

Creating buffers
To create a buffer, use the CREATE_BUFFER keyword. This keyword can only appear in the DEFINE_START section of your program, and it has the following syntax:
CREATE_BUFFER device, array

The CREATE_BUFFER keyword directs the master to place any data received from the specified device into the specified array. When the master places the byte into the array, it increments the length value for the array and then places the byte into the array at the current end of the array. Even though the array is acting as a buffer, it is still an array and can be treated as one. You can still access the individual locations, send it to a device, assign it to other arrays, assign other arrays to it, as well as use the array manipulation keywords discussed in the previous chapter.
When data comes in from a device, it goes into the spot determined by the length value of the array. Here, the length value was 3. So the Y is put into location 4, and the length value is incremented to 4.

Storing characters
When a device sends string information to the master, the master places the incoming information into the buffer created for that device, and updates the buffers length value. (Remember, a buffer is an array.) These actions are executed after the master has passed through mainline. If the buffer is full when a character needs to be inserted into it, the master drops the first character, shifting the contents of the buffer left in order to insert the new character at the end of the buffer. A buffer is said to be full when its length value is equal to its storage capacity.

Retrieving characters
This is where the keyword GET_BUFFER_CHAR comes into play. This keyword has a two-part operation: First, it retrieves the first character in the buffer for your own utilization. This creates the same effect as if you retrieved the first storage location of a normal string array. Second, it removes that character from the buffer, causing all the other characters to shift up one place. The second character is now the first, the third is now the second, and so on. Here is the syntax of this keyword:
string = GET_BUFFER_CHAR(array)

The parameter passed to GET_BUFFER_CHAR must be an array, but does not need to be a buffer. (Remember: All buffers are arrays, but not all arrays are buffers.) The statement will operate identically in either case. The result must be a simple variable (not an array), because one and only one character will ever be returned. In these examples, you will create an array called BUFR with a capacity of ten characters. Then you will make it a buffer associated with a device named RS232.
DEFINE_VARIABLE BUFR[10] CHAR DEFINE_START CREATE_BUFFER RS232,BUFR

Now all string data sent to the Master from the device RS232 will go into the array BUFR, as described earlier. Now, suppose you want to get the data out of the buffer as soon as it enters. This is usually a twostep process. Here is an example:
IF(LENGTH_STRING(BUFR)) { CHAR = GET_BUFFER_CHAR(BUFR) }

These two lines of code are actually one statement: an IF statement. The condition of the If is the result of the LENGTH_STRING keyword; if there are not any characters in the buffer (length value of BUFR is zero), then the master will skip the second part of the statement. The second part, which will be executed if there are one or more characters in BUFR, tells the master to get the first character in BUFR place it into the variable CHAR.

Characters should be continuously retrieved and removed from the buffer so that incoming strings have spaces to completely enter. Be sure to place a GET_BUFFER_CHAR statement in a position to do this. Remember, the master system is constantly running through the main program, and it will execute the GET_BUFFER_CHAR statement as long as it is in its path of execution.

Clearing a buffer
AMX programming provides a single keyword that clears a buffer: CLEAR_BUFFER. Here is how it is used:
CLEAR_BUFFER BUFR

This keyword effectively sets the length of the buffer to zero, so that subsequent GET_BUFFER_CHAR statements will not return anything. Using CLEAR_BUFFER is preferable to other methods, such as assigning a null string to the buffer, or using SET_LENGTH_STRING. The CLEAR_BUFFER keyword actually compiles into smaller code and executes faster than the other methods, plus it is clearer to the reader as to what the programmer is trying to accomplish.

Glossary
Analog
An input or output that can have many values.

Array
A single variable that has more than one storage location.

ASCII
A coding scheme that assigns numeric values to letters, numbers, and other characters.

AXlink
The AXCESS communications bus.

Bar graph
A visual representation of a level.

Baud rate
Speed of data transmission; measured in bits per second (bps).

Bitwise operator
A keyword or symbol that performs a bit-by-bit operation between two items.

Boolean expression
A conditional statement used to tell the master whether or not to execute a particular function or functions in the program. This is also known as a relational expression.

Boolean operator
A keyword or symbol that creates a relation between two items.

Buffer
An array variable that is associated with a particular device for the purpose of storing information sent by the device.

Caller
The Call statement that called a subroutine.

Case sensitive
Uppercase and lowercase values are not evaluated the same; for example, CASS is not the same as cass.

Cell
One particular location in a two-dimensional array.

Channel
The basic input/output unit. Channels correspond to actual control functions such as relays and infrared signals. Each AXCESS device has 255 channels, although all are not always used.

Comment
A description or remark within a program that is not considered part of the actual program; it is ignored by the compiler.

Compilation error
An error that occurs at compile time.

Compile time
When the program is compiled.

Compound statement
A group of several statements enclosed by a set of braces.

Constant
An identifier whose value remains unchanged throughout the entire program.

Decimal
Base 10 numbering system.

Default statement

A statement (or compound statement) that is executed if none of the conditions being tested is true.

Definition section
One of the various divisions of an AMX program. These sections include DEFINE_DEVICE, DEFINE_CONSTANT, DEFINE_VARIABLE, DEFINE_LATCHING, DEFINE_MUTUALLY_EXCLUSIVE, DEFINE_START, and DEFINE_PROGRAM.

Device
A component connected to an AMX system to control another piece of equipment.

Device-channel
A reference to a specific channel in an AMX system in the format [device,channel].

Device number
A unique number from 1 to 255 designated to each device connected to an AXCESS master or from 1 to 32000 designated to each device connected to a NetLinx master.

Digital
An input or output that can have only two values: on or off.

DIP switch
A switch on a circuit board that can be turned on or off to determine various settings.

Direct assignment
Generating an output change by assigning a value to a device-channel.

Downloading
The sending of data from a computer to a device (such as an AMX Master).

EPROM
Acronym for erasable programmable read-only memory.

Executable code
A translated version of the source code that the system master can understand.

Feedback
The lighting of a button during and after it is pressed.

Firmware
Residing within the EPROMs in many AXCESS devices, this software enables these devices to operate.

Flag
A variable that is used to store an on or off state.

Free format
A characteristic of the AMX programming languages that allows the source code to be independent of tabs and carriage returns.

Global variable
Any variable in the DEFINE_VARIABLE section of the program. The scope of these variables extends throughout the entire program.

Hexadecimal
Base 16 numbering system.

Identifier
A combination of letters, numbers, or underscores that represents a device, constant, or variable.

Index value
The number that tells the system master which location in an array to retrieve.

Infinite loop
A loop which will never terminate.

Input change
A signal sent by the input function of a channel that causes the AMX master to scan the program for a reference to that signal.

Instance number
A number enclosed in brackets after the SYSTEM_CALL keyword to denote which copy of the compiled library file to call.

Integer

A 16 bit binary number in the range of whole numbers from 0 to 65,535, inclusive.

Integer array
An array where each location can hold a value ranging from zero to 65,535. Note that an integer array will take up twice as much memory than a normal (character) array of the same storage capacity.

Keyword
A word or series of words that signifies the operation for the system master to execute.

Latching
A defined behavior of status that causes its output channel to stay on or off until activated once more.

Level
A value that is related to an analog input or output on an AMX device.

Library file
A special file containing program code. These files are used only for System_Calls.

Local variable
A variable declared in a subroutine, and whose scope is limited to that subroutine.

Locking
When flags are used to disable events.

Logic error
An error in the actual design of the program.

Loop
A block of code that is continuously executed until a condition is satisfied.

Mainline
The section of the program that actually is executed continuously by the system master. This is also known as the DEFINE_PROGRAM section.

Momentary
A defined behavior of status that causes its output channel to be activated as long as the corresponding button is pressed.

Momentary mutually exclusive

A characteristic of status that allows only one channel of a pre-defined set to be on at a time. The output channel is activated as long as the corresponding button is pressed.

Mutually exclusive latching

A characteristic of status that allows only one channel of a pre-defined set to be on at a time. The output channel stays on until another channel of the set is activated.

Mutually exclusive set

Only one channel or variable in this set can be on at a time.

Mutually exclusive toggling

A characteristic of status that allows only one channel of a pre-defined set to be on at a time. The output channel stays on until it is re-activated or another channel of the set is activated.

Name mangling
The process where the name of the DEFINE_CALL and any WAITs and WAIT_UNTILs in a library file are changed so that multiple separate copies can be compiled into a program.

Nesting
Placing conditional branches inside other conditional branches.

Null string
An empty set of single quotes, which represents a string literal with no content and a length value of zero.

One-to-one
Each button has one and only one function, with no special conditions or considerations.

Operator
A character or group of characters that performs a specific mathematical or relational function.

Output change
A message to the output function of a channel.

Preset

A level saved for later retrieval. When a preset is recalled, the level returns to the preset value.

Program file
File containing the program source code; it has the DOS extension AXS.

Ramp
To change a level from one value to another smoothly over a period of time.

Re-assignment
When the master assigns a new value to a parameter variable after a subroutine is executed, but before it returns to the caller.

Relational expression
See Boolean expression.

Reserved word
An identifier reserved for use by the control system program.

Row
A one-dimensional array of values in a two-dimensional array.

Run time
When the program is executed.

Run-time error
An error that occurs during program execution.

Scope
The part of the program where the variable can be accessed. A variable has global scope if the entire program has access to it; a variable has local scope if only a section of the program has access to it.

Select group
A group of buttons that selects a single deck or device out of a group.

Select variable
A variable whose value determines which device in a group is currently selected.

Serial
The transfer of data one byte at a time.

Source code
The program that you type and edit.

State
The on or off status of a channel.

Statement
A keyword and all of its parameters or conditions.

Status
Records the state of the physical part of a channel.

String
A set of values grouped together with single and/or double quotes.

String expression
Enclosed by double quotes, this expression combines several types of data into a single string.

String length
An internal value set for arrays by string assignment operations.

String literal
A set of characters (decimal values ranging from 32 to 127) enclosed in single quotes.

Subroutine
A section of code that stands alone and can be called from anywhere else in the program.

System variable
A value kept in the system memory that can be referenced by certain keywords.

Transport function
A common function of devices such as VCRs and cassette decks. For example: Play, Stop, Pause, Fast Forward, and Rewind.

Two-dimensional array

A storage place holding multiple one-dimensional arrays.

Uploading
The opposite of downloading; the computer receives data from a device.

Variable
A place to store data that will change as the program is executed.

Wait list
A list containing unexpired Wait statements. After each pass through mainline, the master scans this list to see if any have expired.

Wait_Until list
A list containing unexpired Wait_Until statements. After each pass through mainline, the master scans this list to see if any have expired.

Warning
A statement by the compiler urging caution with a potentially hazardous statement in the source code.

Wildcard character
Allows any character to be in its place; in AXCESS programs, this is the question mark (?). This is only valid when comparing dates and times.