Leopard II manual Table of Contents
|
|  Yüklə 3.21 Mb.
|
IF Time of Day, Comparison, Data Description: Compares the current Time of Day against the specified data; either a constant, a variable, or the current day’s sunrise or sunset time (with an offset of up to 120 minutes). The time is in military (24 hour) format ie: 6:00 PM = 18:00 and would be entered as 1800 . Example: 0001 - IF Time of Day becomes = 18:00 // At 6:00 PM 0002 - THEN X-10 House F / Unit 7, Turn OFF // stop the pool filter 0003 - IF Time of Day becomes = Sunset offset 30 minutes // At half hour past sunset 0004 - THEN X-10 House D / Unit 12, Turn ON // turn on porch light Timing: The Time of Day is obtained from the Leopard II’s internal real time clock (system clock). The sunrise and sunset times as well as daylight savings or standard time are calculated, based on the daylight savings time check box and longitude/latitude values entered in the C-Max Comms Setup screen. Whenever the time advances to the next minute, the new time value will be valid beginning with the next pass. This allows for predictable “becomes” behavior whereby the lower numbered program lines always see a new time first. Work Variable: When the comparison involves a constant or a variable’s contents, the current value of the Time of Day* is captured in the work variable. If the comparison is against sunrise or sunset, then the sunrise or sunset time* for that day will be captured in the work variable. The current day’s sunrise or sunset time is available as soon as the day begins, at midnight. This allows you to use it for calculations ahead of the actual sunrise/sunset times, or for display purposes. * The Time of Day and sunrise or sunset time is captured as a “minutes after midnight” value. For example, 6:00 PM which is normally 1800 in military time will be returned as 1080 (18 x 60). You can use division and modulo to convert it to military time as follows (military time will appear in variable# 1): 0001 - IF Time of Day is > 00:00 // look at Time of Day 0002 - THEN Load Data to: Variable #0 // and capture in Var# 0 0003 - THEN Variable #1 = Variable #0 // and also copy to Var# 1 0004 - THEN Variable #1 / 60 // calculate hours 0005 - THEN Variable #1 * 100 // convert hours to HHxx 0006 - THEN Variable #0 % 60 // calculate “minutes” value 0007 - THEN Variable #1 + Variable #0 // add to hours: HHMM 0008 - ELSE Variable #1 = 0 // if midnight, then time = 0 Notes: Since the Time of Day is a number that increases in value from midnight to 11:59 PM, numerical comparisons need to take that into account for proper behavior. For example, if you want to write a program segment that tests true for nighttime (after sunset and before sunrise), you need to use an OR statement since you’re looking for a value that can be at both ends of the Time of Day scale: 0001 - IF Time of Day is > Sunset offset 0 minutes // If past sunset 0002 - OR Time of Day is < Sunrise offset 0 minutes // or before sunrise (nighttime) While a test for daytime uses an AND statement: 0001 - IF Time of Day is > Sunrise offset 0 minutes // If past sunrise 0002 - AND Time of Day is < Sunset offset 0 minutes // and before sunset (daytime) Be careful about scheduling any critical tasks between 1:00 and 3:00 AM because this time period falls in the adjustment range when the time switches from standard time to daylight savings time or vice versa. For example, when going from daylight savings time to standard time in the Fall, the time goes from 2:00 AM to 1:00 AM and an event scheduled between 1:00 AM and 2:00 AM will be executed twice. Similarly, in the Spring the time changes from 2:00 AM to 3:00 AM and an event scheduled between these two times will not be executed. IF Month, Comparison, Data Description: Compares the current month against the specified data; either a constant or a variable. Months are numbered from 1 (January) to 12 (December) Example: 0001 - IF Month is = December (12) // If in December 0001 - AND Time of Day becomes = Sunset offset 0 minutes // and at sunset 0002 - THEN X-10 House E / Unit 3, Turn ON // turn on Christmas lights Timing: The month is obtained from the Leopard II’s internal real time clock (system clock). The month will advance to the next month at midnight and the new month value will be valid beginning with the next pass. This allows for predictable “becomes” behavior whereby the lower numbered program lines always see a new month first. Work Variable: The current month number will be captured in the work variable. Notes: None. IF Day of Month, Comparison, Data Description: Compares the current day of month against the specified data; either a constant or a variable. Days of the month are numbered from 1 to the last day of the current month. Example: 0001 - IF Month is = December (12) // If in December 0001 - AND Time of Day becomes = Sunset offset 0 minutes // and at sunset 0002 - THEN X-10 House E / Unit 3, Turn ON // turn on Christmas lights Timing: The day of month is obtained from the Leopard II’s internal real time clock (system clock). The day of month will advance to the next day at midnight and the new day of month value will be valid beginning with the next pass. This allows for predictable “becomes” behavior whereby the lower numbered program lines always see a new day of month first. Work Variable: The current day of month number will be captured in the work variable. Notes: The number of days for any given month is automatically calculated by the system clock. Adjustments for leap years are also automatic, adding Feb. 29th as necessary. Sometimes it is necessary to determine if the day of the month is odd or even for things like lawn watering routines, etc. You can use the following routine to create an odd/even flag that can then be used elsewhere in your program: 0001 - IF Day of Month is > 0 // always true... 0002 - THEN Load Data to: Variable #0 // store in Variable #0 0003 - THEN Variable #0 % 2 // get modulo 2 (0 = even, 1 = odd) Variable #0 will be equal to 0 on even numbered days and equal to 1 on odd numbered days. IF Day of Week, Comparison, Data Description: Compares the current day of the week against the specified data; either a constant or a variable. Days of the week are numbered from 0 to 6: 0 = Sunday 1 = Monday 2 = Tuesday 3 = Wednesday 4 = Thursday 5 = Friday 6 = Saturday Example: 0001 - IF Day of Week is = Wednesday (3) // If today is Wednesday 0002 - AND Time of Day becomes = 06:00 // at 6:00 AM 0003 - THEN Send Module #3 -BOBCAT-A Message 34 w/ Variable #0 // Garbage day reminder… Timing: The day of week is obtained from the Leopard II’s internal real time clock (system clock). The day of week will advance to the next day at midnight and the new day of week value will be valid beginning with the next pass. This allows for predictable “becomes” behavior whereby the lower numbered program lines always see a new day of the week first. Work Variable: The current day of week number will be captured in the work variable. Notes: None. IF Year, Comparison, Data Description: Compares the current year against the specified data; either a constant or a variable. Years are entered as 4 digits. Example: 0001 - IF Year is = 2003 // If year is 2003 0002 - THEN Load Data to: Variable #90 // capture work variable 0003 - ELSE Load Data to: Variable #90 // no matter what year Timing: The year is obtained from the Leopard II’s internal real time clock (system clock). The year will advance to the next year at midnight and the new year value will be valid beginning with the next pass. This allows for predictable “becomes” behavior whereby the lower numbered program lines always see a new year first. Work Variable: The current year number will be captured in the work variable as a two significant digit value (ie: 2003 = 03 so the variable will contain 3). Notes: Performing actions based on the year value is quite rare, but capturing the year value in the work variable (as shown in the example above) can be useful for event logging routines where you want to include the date and time in formatted strings sent from a serial device like the Leopard II’s RS-2332 port or a serial Bobcat. IF Date (mm/dd/yy), Comparison, Date Description: Compares the current date against the date selected from the calendar. Clicking on the date list box will display a calendar allowing you to choose the date you want. On each side of the month-year name you will see an arrowhead button allowing you to go to the previous or next month. When you scroll past the first or last month of a year, the year will adjust and you will be able to keep scrolling through the previous or next year as applicable. Once you have the desired month and year displayed, click on the day of the month that you want. As a convenience, the current day’s date will be encircled in red when the current month is selected. Example: 0001 - IF Date is = 06/05/03 // If June the 5th 0002 - THEN Send Module #3 -BOBCAT-A Message 0 w/ Variable #5 // display birthday message Timing: The date is obtained from the Leopard II’s internal real time clock (system clock). The date will advance to the next date at midnight and the new date value will be valid beginning with the next pass. This allows for predictable “becomes” behavior whereby the lower numbered program lines always see a new date first. Work Variable: None. Always 0. Notes: None. IF Receive IR Module, IR Description: Looks for the reception of a recognized Infrared (IR) code from the master or a slave controller, as specified in the control wizard list boxes. Example: 0001 - IF Receive IR IR #19, from Leopard // If "TV On" IR code is received 0002 - THEN X-10 House N / Unit 8, Turn ON // turn on lamp 0003 - THEN Transmit X10, N - Dim (21), 5 time(s) // and dim it Timing: IR codes are received by a separate processor in the Leopard II. Whenever a recognized IR code is received, it is placed in the IR input buffer and at the beginning of every program pass, the buffer is checked for any received IR codes in it. If there is one or more, the oldest one (ie: the one that was received first) is made available as the current incoming IR code for comparison by this command throughout the pass. Any other buffered commands will similarly be read on subsequent passes. Work Variable: The packed buffer value of the current IR code will be in the work variable. The code is held in a 16 bit variable. The upper 8 bits contain the module number (adnet address) of the controller that received the code while the lower 8 bits contains the code number itself. If there are no recognized IR codes in the input buffer, a value of 65535 is returned. You can parse the 16 bit variable into two individual 8 bit fields using the divide and modulo math operators: 0001 - IF Receive IR IR #0, from Leopard // Look for an IR code 0002 - THEN Load Data to: Variable #1 // capture in variable #1 0003 - ELSE Load Data to: Variable #1 // in either case 0004 - IF Variable #1 becomes NOT = 65535 // If there is a code in input queue 0005 - THEN Variable #2 = Variable #1 // copy code to variable #2 0006 - THEN Variable #2 / 256 // get module number in var #2 0007 - THEN Variable #1 % 256 // get code number in var #1 Notes: Any slave controller(s) must be defined in the System Map or else the Control Wizard will not show you the module list properly to then allow you to select the IR code. Consult the C-Max utilities section of the manual to see how to learn and/or load IR codes into your controller(s). Among the configuration parameters that govern the Leopard II’s operation, parameter# 20 sets the highest IR code for which the controller will try to find a match whenever an IR signal is received at the controller’s IR sensor. Up to 256 IR codes can be compared against a received code before the controller decides that none of them match. It takes the controller a certain amount of time to go through all the codes so the best performance will be obtained when the controller has to search through the least amount of codes before giving up. Because of this, often recognized codes should ideally be learned in the lower code locations and parameter 20 should be set to the lowest number possible (ie: no higher then the actual amount of codes that need to be recognized). The Leopard II cannot transmit or receive IR and X10 simultaneously. You therefore cannot create a routine that looks for a stream of IR commands to perform X10 dimming, or an X10 dimming stream to perform an IR function like adjusting a volume level. You need to stop sending one type of data to let it transmit the other. IF X10 Status/Cmnd Pair X10 house/unit code, X10 Status Description: Looks for an X10 status or command pair. For X10 status, can look at the present status for the specified house code/unit code in the X10 status table (see notes below) or for a change in status. The instruction can also look for the reception of an actual On or Off command pair from the powerline. To look for individual X10 commands, see IF Receive Single X10. Examples: 0001 - IF X-10 House J / Unit 4, Is OFF // If air conditioner is Off 0002 - AND Module #1 -BOBCAT-T becomes > 76 // and temp goes above 76 0003 - THEN X-10 House J / Unit 4, Turn ON // turn it on. 0004 - // 0005 - IF X-10 House L / Unit 2, ON Command Pair // If On command pair for lamp 0006 - AND Time of Day is > Sunrise offset 0 minutes // and after sunrise 0007 - AND Time of Day is < Sunset offset 0 minutes // and not sunset yet 0008 - THEN Variable #4 = 1 // set lamp request flag to 1 Timing: X10 commands are received by a separate processor in the Leopard II. Whenever a complete X10 command is received, it is placed in the X10 input buffer and at the beginning of every program pass the buffer is checked for any X10 commands in it. If there is one or more, the oldest one (ie: the one that was received first) is made available as the current incoming X10 command for comparison by this command throughout the pass. Any other buffered commands will similarly be read on subsequent passes. Work Variable: The packed-format buffer value of the current X10 command will be in the work variable. See the description of the IF Receive Single X10 command to see the values that are returned. Notes: The difference between looking at the status table and for the actual commands can be subtle, but important. The Leopard II maintains an in-memory status table of all 256 X10 addresses, and memorizes that the device is either on or off. This can be used as a flag in making logic decisions, avoiding the need to use variables to keep track of X10 device status. The on or off status of a device will obviously be updated with the reception of the corresponding command pair for the given house and unit code, but also with the reception of a Status ON or Status OFF in response to a Status Request command. These commands do not have to be generated by the Leopard II itself, but can come from any X10 device (the Leopard II analyzes all X10 traffic on the powerline). The status transmitting device might also be configured to transmit it’s own status periodically. X10 Dim or Bright commands do not affect the status table entry of an X10 device. Looking for the actual command pair allows you to ignore the fact that a device is already on or off, letting you look for the significance of receiving the command multiple times, or when the device has local on/off control and it’s status cannot be reliably determined just from powerline commands. The Leopard II will receive any X10 commands it transmits itself, and will process them like commands from any other source. The Leopard II cannot transmit or receive IR and X10 simultaneously. You therefore cannot create a routine that looks for a stream of IR commands to perform simultaneous X10 dimming, or an X10 dimming stream to perform an IR function like adjusting a volume level. You need to stop sending one type of data to let it transmit the other. IF I/O Error Occurs Description: Traps Adnet bus I/O Errors (if the master can no longer access an expansion module that was present when the master was first powered up or restarted) Example: 0001 - IF I/O Error Occurs //if I/O error 0002 - THEN Load Data to: Variable #0 //put Adnet mod# in variable# 0 Work Variable: Returns the Adnet address of the unresponsive module. Returns the highest affected module address if several modules become unresponsive. Notes: You can use this instruction to log the error through the serial port or display an error message on the screen if one or more modules fail to respond to polling from the master controller. This can be useful for critical applications like reading temperatures or liquid levels, where a failure to keep control could have materially harmful consequences. If more then one module fails, then the highest numbered one (address-wise) will be the one reported in the work variable. This could happen due to a wiring or power fault affecting several modules at once. You need to verify and possibly adjust parameter 9 in your master to specify how many consecutive unsuccessful attempts must be made before the error condition is trapped (a value between 3 and 5 should be good). Note that if the module reappears on the bus following such an error, it will then again be accessed, without the master needing to be rebooted. You may also want to adjust parameter 8 to reduce the time wasted waiting for an unresponsive module, a value between 5 and 10 for this parameter should be sufficient. IF Touch Button Pressed Module, Button Description: Looks for a touch button (as defined on the screen) having been pressed on the master Leopard or a slave Leopard controller, as specified in the control wizard list boxes. Example: 0001 - IF Touch Object #2, Button Leopard is pressed // if button 2 is pressed 0002 - THEN Variable# 63 / Screen# = 5 // display screen # 5 Timing: Touch button presses are detected by a separate processor in the Leopard II. Whenever a touch button object is pressed on the screen, it’s object number is placed in the touch button input buffer and at the beginning of every program pass, the buffer is checked for any touch button codes in it. If there is one or more, the oldest one (i.e.: the one that was pressed first) is made available as the current touch button object number for comparison by this command throughout the pass. Any other buffered button presses will similarly be read on subsequent passes. Work Variable: The packed buffer value of the current touch button code will be in the work variable. The code is held in a 16 bit variable. The upper 8 bits contain the module number (Adnet address) of the controller on which the button was pressed while the lower 8 bits contains the button’s object number itself. If there are no touch button codes in the input buffer, a value of 65535 is returned. You can parse the 16 bit variable into two individual 8 bit fields using the divide and modulo math operators: 0001 - IF Touch Object #1, Button Leopard is pressed // if any button is pressed 0002 - THEN Load Data to: Variable #1 // capture in variable #1 0003 - ELSE Load Data to: Variable #1 // in either case 0004 - IF Variable #1 becomes NOT = 65535 // If there is a button code in input queue 0005 - THEN Variable #2 = Variable #1 // copy code to variable #2 0006 - THEN Variable #2 / 256 // get module number in var #2 0007 - THEN Variable #1 % 256 // get button number in var #1 Notes: Any slave controller(s) must be defined in the System Map or else the Control Wizard will not show you the module list properly to then allow you to select the touch button code. Consult the C-Max user guide section of the manual to see how to create touch screen layouts for your controller(s). Touch button #0 is defined as the “touch anywhere” button. You will get this code whenever you press any area on the screen that has a valid button defined, or press anywhere on screen #0; the bitmap display screen. Touching a valid button will in fact always queue two button press events; a “0” for the “touch anywhere” event followed by that actual touch button object number. These two values will be returned on two consecutive passes through the program. If the screen is displaying screen #0, you will get the object “0” event followed by touch object #255 being pressed. This allows you to distinguish between screen 0 being pressed and any other button being pressed. For touch button presses being detected on the master as coming from a slave Leopard, you will not get “touch anywhere” events; only the actual button object number. THEN Module / Point Module#, I/O point, I/O command Description: Sets an expansion module I/O point On or Off. An I/O point is either an input such as the ones found on SECU16 or SECU16I modules or output relays like the ones on the SECU16 or RLY8XA. Only output relays can be controlled by this instruction. Example: 0001 - IF Time of Day becomes = 05:00 // At 5:00 AM 0002 - THEN Module #5 -RELAY-08 Relay #2 Turns ON // turn on sprinklers Timing: The controller’s bus routine interrogates the modules continuously and transmits updates as needed, independently from the running C-Max program. Any I/O output commands are queued for transmission and are inserted between the module status interrogations, to maintain timely detection of input events. This means that a certain delay may be observed between the time the command is executed and the module output actually responds. This delay can be up to a second or so. Because of this, very short timing intervals for outputs cannot be reliably produced. If there is a need for short, momentary-type contact activation, please inquire about the availability of momentary closure mode modules. You must also avoid program logic where module output commands are issued on every pass. This will overrun the output buffer and can cause the controller to appear to lock up. Use single triggering logic tests and/or timers to issue module output commands only when needed. Notes: Your expansion module must be defined in the System Map or else the control wizard will not show you the I/O point and I/O command options. See the manual section on Projects to learn how to create/maintain the System Map. THEN Set Slave Variable Module#, Variable#, Data Description: Updates the value of a slave variable (in a slave controller) with the specified data; either a constant or the contents of a variable. The specified slave variable# can range from 0 to 63. Example: 0001 - IF Touch Object #18, Button Leopard is pressed // If temperature + button is pressed 0002 - THEN Variable #10 + 1 // increment setpoint variable 0003 - THEN Module #3 -Slave Leopard Variable #10 to: Variable #10 // and update slave Timing: The controller’s bus routine interrogates the modules continuously and transmits updates as needed, independently from the running C-Max program. Any slave variable update commands are queued for transmission and are inserted between the module status interrogations, to maintain timely detection of input events. This means that a certain delay may be observed between the time the command is executed and the slave variable is actually updated. This delay can be up to a second or so. You must also avoid program logic where slave variable updates are issued on every pass. This will overrun the output buffer and can cause the controller to appear to lock up. Use single triggering logic tests and/or timers to issue slave variable update commands only when needed. Notes: Your slave controller must be defined in the System Map or else the control wizard will not show you the variable# command options. See the manual section on Projects to learn how to create/maintain the System Map THEN Load Data to Variable Variable# Description: Copies the contents of the work variable to the specified variable. Examples: 0001 - IF Module #4 -SECU16 Analog #1 is < 256 // read analog input 0002 - THEN Load Data to: Variable #3 // and capture to variable #3 0003 - IF Touch Object #1, Button Leopard is pressed // if a touch button is pressed 0004 - THEN Load Data to: Variable #4 // save in variable #4 0005 - ELSE Load Data to: Variable #4 // in all cases Timing: The value is copied immediately. Notes: This instruction allows the tested resource’s present value (from the preceding test statement) to be copied to a variable for use in the program, display, etc. Whenever a resource like the X10 input command queue, Touch button press queue, a Timer, etc. is referenced by an IF statement, the specified resource is loaded into the work variable and then compared against the specified value in the statement; usually a constant or the contents of a variable. The test statement then sets the true/false condition according to the result of the logic test. The Load Data to Variable command allows you to capture the current value of the resource that was just tested. This greatly enhances the capabilities of the test statements because you can get the value itself, instead of merely testing it for a true or false condition. A good example of this is a SECU16 analog input. You certainly don’t want to use 256 IF/THEN statements to test for every possible value. With this statement, you can make one comparison (as shown in the first example above) just to access the value and then store it in a variable. Since this is an action statement, its execution is still dependent upon the true/false status of the test statement preceding it. Because analog input values for an analog SECU16 input always range from 0 to 255, the first example above will always test true and line 2 will always be executed. Other resource types like the touch button queue (second example above) force you to choose the test value from a list and therefore do not allow a test that will be guaranteed to test true at all times. In such cases, use a THEN and an ELSE statement as shown in lines 4 and 5 of the example to insure the capture of the work variable every time. The actual significance of the work variable’s value varies with the type of resource being tested. Read the reference manual entry for each type of test statement to see what the work variable will return. This is explained in detail under the work variable paragraph for each test statement. THEN Transmit Single X10 House code, Unit or Command code Description: Transmits a single X10 command consisting of a house code and either a unit code or command code. The house code is selected using the radio buttons while the unit or command code is selected from the list box. For the command codes, the list box also shows the numerical equivalent in parenthesis. Example: 0001 - IF Touch Object #6, Button Leopard is pressed // turn on kitchen lights 0002 - THEN Transmit X10, K - 1 // address overhead lights 0003 - THEN Transmit X10, K - 3 // then countertop lights 0004 - THEN Transmit X10, K - ON (19) // turn them on Timing: X10 commands are transmitted by a separate processor in the Leopard II. Whenever a statement to transmit an X10 command is executed, the command is placed in the X10 output buffer and program execution resumes immediately. The queued command will be transmitted as soon as any previously queued commands have finished transmitting, independently of the running program. Notes: This command is useful for sending raw X10 commands. Since the most common X10 command usage is with command pairs (eg: B/6 followed by B/ON to turn the device with address B/6 On) the X10 Quick ON/OFF command is more useful to send those. The Transmit Single X10 is mostly used to: 1- Address several modules before issuing a command that will concern all of them, like shown in the above example. This can include coordinated dimming too. 2 - Issue commands like Status Requests. 3 – Issue or respond a preset dim level. 4 – Any other situation where you want to issue specific X10 commands. Because this command is sometimes used in more unusual circumstances, System Map names are not used, given that house code/unit code pairs might not be referring to the device at that address but to things like a preset dim level instead. The Leopard II will receive any X10 commands it transmits itself, and will process them like commands from any other source. The Leopard II cannot transmit or receive IR and X10 simultaneously. You therefore cannot create a routine that looks for a stream of IR commands to perform X10 simultaneous dimming, or an X10 dimming stream to perform an IR function like adjusting a volume level. You need to stop sending one type of data to let it transmit the other. THEN Timer (seconds) Timer#, Data Description: Sets a Timer to the specified data; either a constant or the contents of a variable. A Timer set to a value other then 0 will increment once per second until stopped by either setting it 0 with program code or if it counts up to 65535 after which it rolls over to 0 and stops by itself. Example: 0001 - IF Time of Day is > Sunset offset 20 minutes // if time is past sunset 0002 - OR Time of Day is < Sunrise offset 0 minutes // and before sunrise (night) 0003 - AND Module #1 -SECU16 Input #2 Turns ON // and PIR detects movement 0004 - THEN X-10 House H / Unit 2, Turn ON // turn on hall light 0005 - THEN Timer #4 = 1 // and start the timer 0006 - IF Timer #4 becomes > 900 // if 15 minutes have elapsed 0007 - THEN Timer #4 = 0 // then stop timer 0008 - THEN X-10 House H / Unit 2, Turn OFF // and turn off hall light Timing: Timers can be set to any value by program code and will stay at that value for the remainder of that program pass (unless modified again by another instruction later in the same pass). Between every pass, the controller verifies if the controller’s real time clock has advanced to the next second. If it has, all running timers are incremented by 1 at the same time. This means that timer increments are aligned with the system’s real time clock and always occur between program passes. This allows for predictable “becomes” behavior whereby the lower numbered program lines always see a value change first. Notes: The timing considerations (as explained above) are the most important things to note about this instruction. Since the program looping runs independently of the clock (a shorter program will loop more times per second then a long one), the time between a timer being set to a value other then 0 and the time it first increments can be very short. This will happen if the real time clock was due to roll over to the next second during the program pass in which the Timer’s value was set. Because of this, a timed interval is precise to within a second. A very long program (2000 lines or more) could take more then a second to complete a loop, which means that a timer could theoretically increment by 2 between two consecutive passes. If that risk is present, it is better to avoid looking for a Timer being equal to a value and instead look for it to becoming greater then the desired value – 1 (as shown in the example above), which will still test true even if it was to increment by 2. THEN Variable Variable#, Operation, Source data (operand) Description: Performs the specified mathematical or assignment operation to the variable using the source data (a constant or the contents of the specified variable) as the operand and puts the result in the variable. Example: (convert temperature value from Fahrenheit to Celsius degrees) 0001 - IF Module #2 -BOBCAT-T is > -100 // Read temperature Bobcat 0002 - THEN Load Data to: Variable #2 // and capture value in variable 3 0003 - THEN Variable #2 - 32 // subtract 32 0004 - THEN Variable #2 * 5 // multiply by 5 0005 - THEN Variable #2 / 9 // divide by 9 0006 - THEN Variable #3 = Variable #2 // copy to display variable (now in Celsius) Timing: Variables are set to the new value immediately. See the reference page for the IF Variable command to see how a variable read by a device using the serial protocol or a variable linked to a screen text object can return intermediate values because of their timing considerations. If this is a concern, it is best to perform the calculations using a temporary variable and then copy the final result to the variable that will be read by the external device or referenced on the screen. Notes: You can perform straight assignment (=), the 4 regular math operations (add, subtract, multiply, divide) and modulo (the “%” operator). Modulo is the remainder portion after an integer division. For example: 23 % 3 = 2 because 23 divided by 3 = 7 with a remainder of 2. This is useful for base conversions such as converting from minutes to sexagesimal (base 60) time. The IF Time of Day command reference page has an example of using modulo to do this. Among the configuration parameters that govern the Leopard II’s operation, parameter# 22 sets the limit for the non-volatile variables. This means that the values for variable numbers at or above the number set in parameter# 22 will be retained even during a power failure, while the variables below that number will always be reset to 0 upon a power up. Having variables that predictably reset to 0 upon a restart can be useful to guarantee detection of a power interruption and to start in a known state. Having non-volatile variables can also be useful to retain certain things like user modified setpoints for temperatures or times even if the power fails. When scrolling through the list of variables that may be selected as the source data, you will see that the variables go from 0 to 127, and then continues with a list of “Data for Module #x” where x goes from 0 to 127. These are referred to as the extended variables and correspond to the raw data value (0 to 255) of Bobcat modules like the temperature Bobcat, humidity Bobcat, etc. For non-Bobcat modules, these variables will not contain any valid data. THEN Skip to (Program Jump) Line# Description: Instructs the command interpreter to continue program execution at the specified line number. Example: 0001 - IF Touch Object #3, Button Leopard is pressed // If toggle button is pressed 0002 - AND X-10 House A / Unit 3, Is OFF // and light is off 0003 - THEN X-10 House A / Unit 3, Turn ON // then turn light on 0004 - THEN Skip to line 7 // and skip rest of routine 0005 - IF Touch Object #3, Button Leopard is pressed // If toggle button is pressed 0006 - THEN X-10 House A / Unit 3, Turn OFF // then turn light off 0007 – IF … Timing: Immediate. Notes: This is the only command (other then the END statement) that causes the program flow to continue with a program line other then the following one. You can only jump forward in the program. Using this command to skip statements can greatly simplify program coding because you can create “nested” logic. For example: suppose you have an alarm system that sets a variable as an “away mode” flag. You want to simulate a lived-in look for the home when the system is armed so you would normally have many program segments looking for the Time of Day being equal to a certain value and the away mode flag being set to turn lights, etc. on and off. Using the Program Jump instruction, you can look for the flag being set and if not, skip the entire lived-in routine. The lived-in routine would only need to look for the Time of Day, without needing all the AND statements to also test the flag each time. The example above shows another common use for the Program Jump instruction. Creating a toggle button is an order sensitive task because a touch button press is true for an entire pass through the program, so the first instance would toggle the output and the second one toggle it right back. In our example, we avoid this by skipping over the second toggle if the first one was executed. This also saves us a logic test on the status of X10 device A/3 because the only way line 6 can be reached is if line 5 is true and line 2 is not true. Note that although the program editor shows the line with a destination line number, internally it stores the destination as an offset from the current line. This means that if you cut/copy and paste a program segment containing Program Jump instructions, the pasted segment will display the newly calculated destination line number(s), again as offsets from where they are. For example, you copy lines 10 to 17 and line 12 is a Program Jump that skips to line 16. If you paste the segment beginning at line 30, the Program Jump line will be at line 32 and will show that it skips to line 36. The editor also automatically adjusts the offset if any program lines are inserted or deleted between a Program Jump instruction and it’s destination line. Keep in mind that the current true/false status of the preceding test statements stays intact when a jump occurs, so you cannot selectively skip some THEN statements but execute others by using this command. Ideally, a program should always jump to an IF statement. THEN Set Displayed Icon Object#, Icon# Description: Dynamically selects an icon to be displayed on a touch button. The object# must refer to a touch button, any other screen object type will ignore the command. The icon# can be selected from the list of System Map named icons or by the contents of a variable. Example: 0001 - IF Module #1 -SECU16 Analog #3 is > 64 // if tank is one quarter full or more 0002 - THEN Touch Object #6 displays Icon# Icon #1 // show the "full" picture 0003 - ELSE Touch Object #6 displays Icon# Icon #2 // else show the "low level" picture Timing: Immediate. Notes: Although the object must be a touch button, nothing prevents you from using a touch button simply as a display-only object if you wish to do so. You can use this command to display detailed status information in the form of an icon, or to reflect the current status of a button that triggers a toggling action. Note that you cannot change an icon on a slave Leopard from the master controller with this command, this can only be done on the local controller. Read the application note on creating icons elsewhere in this manual to see the entire procedure involved in creating and using icons. THEN Send X10 Thermostat (RCS) House code, Function, Data Description: Sends X10 command to an RCS thermostat. Some functions like specifying the setpoint require a data value. Example: 0001 - IF Time of Day becomes = 16:00 // before coming home from work 0002 - THEN Set RCS X10 B Setpoint 72 // set temperature to 72 degrees Timing: The command is put in the X10 output queue and program execution resumes immediately. Notes: The RCS thermostat uses the original format X10 preset dim command to exchange data to and from a controller like the Leopard II. A given RCS thermostat uses an entire X10 house code for itself. This means that up to 16 RCS thermostats can be independently controlled. The use of the preset dim commands allows the thermostat to send and receive multiple analog values such as the current temperature even though it only has one house code to do so. The value of the dim level can be any one of 32 values for a single unit code, allowing a total of 512 different possible commands or values to be transmitted between the thermostat and the controller. See the RCS thermostat documentation to learn about all the possible commands and values. Requesting the temperature from a thermostat (or getting the value automatically by virtue of the thermostat’s “Auto Send” mode) causes one of many possible preset dim commands to be returned/sent by the thermostat. The Leopard II can be set to automatically look for these responses and store the equivalent temperature value in a pre-designated variable. To do this, set your controller’s parameter # 21 to a value of 1. Once this is set, the Leopard II will store the temperature from the thermostat at house code A in variable # 64, thermostat B in variable # 65, etc. Note that any X10 house codes that don’t have RCS thermostats using them will not be using it’s designated variable, so the designated variables for those house codes can be used as general-purpose variables. THEN Send Bobcat Thermostat Description: This command is for the support of a future product (Bobcat) designed to control non-X10 thermostats. THEN X10 Preset Dim (PCS) Switch type, House/Unit Code, Dim Level Description: Encodes and sends an X10 preset dim command to the PCS switch at the specified house and unit code. The house and unit codes will be replaced by the System Map name if one has been entered. The dim level is expressed as a percentage of full brightness and can be selected either directly (using the slider) or by the contents of the specified variable. Example: 0001 - IF Touch Object #4, Button Leopard is pressed // if button 4 is pressed 0002 - THEN Set X-10 House J / Unit 7, to: 45 % // set lights to 45 % brightness Timing: The command is put in the X10 output queue and program execution resumes immediately. Notes: This command is also used as the THEN X10 Preset Dim (Leviton) command. The switch type radio button determines which dim level encoding type will be done. The preset dim level can be one of 32 levels for PCS switches, and one of 64 levels for Leviton switches. In either case, the level closest to the specified percentage will be encoded and sent. THEN X10 Quick ON/OFF House/Unit Code, Command Description: Transmits an X10 command pair to turn a device On or Off. The house and unit codes will be replaced by the System Map name if one has been entered. Example: 0001 - IF Touch Object #54, Button Leopard is pressed // if button 54 is pressed 0002 - THEN X-10 House B / Unit 4, Turn ON // turn on basement light Timing: The command pair is put in the X10 output queue and program execution resumes immediately. Notes: This command is provided as a convenient way to turn X10 devices on an off using a single program line, even though two individual X10 commands are actually sent. Without it, you would need to use two consecutive THEN Transmit Single X10 commands to accomplish the same task. THEN Send Page Message # Description: Sends the specified message # to an alphanumeric pager. Example: 0001 - IF Touch Object #54, Button Leopard is pressed // if button 54 is pressed 0002 - THEN X-10 House B / Unit 4, Turn ON // turn on basement light Timing: The sequence to call the pager is initiated and program execution resumes immediately. Notes: Calling a pager requires the use of the Adicon modem. The modem must first be configured in C-Max. See the C-Max configuration section to see how to set up the pager. The User PIN and up to 15 pager messages are configured in the controller access utilities. Refer to the manual section on using C-Max to see how you can enter your pager message strings. Description: Transmits an infrared command (IR) using the specified module and zone numbers. The IR code number can be specified either with it’s system map name or by the contents of the specified variable. Example: 0001 - IF Touch Object #49, Button Leopard is pressed // if button 49 is pressed 0002 - THEN Module #4 -SECU16-IR, IR Zone #5 IR# 56 // send ir #56 to output 5 of SECU16IR Timing: The IR command is placed in the IR output queue and program execution resumes immediately. Notes: IR commands can be transmitted by either: the master controller, a slave controller, or a SECU16IR module. For a master or slave controller, the zone will always be #0 and corresponds to that controller’s built-in IR output. The SECU16IR module has 16 addressable outputs and the zone# corresponds to each one, allowing you to target individual IR controlled equipment when sending the commands. This gives you the ability to control similar types of equipment where the IR codes would otherwise interfere with each other. You also get individual signal amplification for each output, allowing many IR emitters to be used without loss of signal strength. The IR system map names shown in the list box are always those of the current project. If you are triggering the transmission of an IR code for a slave controller, it’s own IR codes might actually be different then the ones you see in the list box. The Leopard II cannot transmit or receive IR and X10 simultaneously. You therefore cannot create a routine that looks for a stream of IR commands to perform X10 simultaneous dimming, or an X10 dimming stream to perform an IR function like adjusting a volume level. You need to stop sending one type of data to let it transmit the other. THEN X10 Preset Dim (Leviton) Switch type, House/Unit Code, Dim Level Description: Encodes and sends an X10 preset dim command to the Leviton switch at the specified house and unit code. The house and unit codes will be replaced by the System Map name if one has been entered. The dim level is expressed as a percentage of full brightness and can be selected either directly (using the slider) or by the contents of the specified variable. This command is identical to the THEN X10 Preset Dim (PCS) command and actually uses the same control wizard screen. See the THEN X10 Preset Dim (PCS) command reference page for details on using this command. THEN Transmit X10 Group (Leviton) House Code, Group#, Set Command Description: Encodes and sends an X10 command to control a predefined Leviton switch group. The group is specified by the house code and the group number, as programmed in the switch at installation time. The set command can be to either have it go to its preset level, or to turn the group off. Example: 0001 - IF Time of Day is > Sunset offset 0 minutes // at sunset 0002 - THEN Send House F-Group# 14, Group to PRESET // set grp 14 of h/c F to dim levels. 0003 - IF Time of Day becomes = 23:30 // at 11:30 PM 0004 - THEN Send House F-Group# 14, Group to OFF // turn that group off Timing: The command is put in the X10 output queue and program execution resumes immediately. Notes: These commands can only be used on Leviton’s 16xxx and “Green Line” HC series switches. A Leviton group corresponds to a combination of a unit code and a learned dim level. A switch can belong to up to 4 groups. To use the THEN Transmit X10 Group (Leviton) command, you must first configure the switches to “teach” them their group numbers and dim levels. Normally this is done using a Leviton controller switch, but you can also use a handy C-Max utility to do this too. The utility is under the “X10” utilities on the controller access screen; simply click on “Send Leviton X10” to set up and manage your Leviton groups. The use of this utility is covered in the C-Max section of this manual. THEN Transmit Speak Easy Module#, Message# Description: Instructs the specified Speak Easy module to play back the selected message#. Example: 0001 - IF Module #2 -SECU16 Input #0 Turns ON // if driveway's car detector trips 0002 - THEN Send Module #1 -SPEAK-EZ Audio Message #5 // announce imminent arrival Timing: The command is sent to the speak easy module for playback and program execution resumes immediately. If a playback command is sent to a speak easy while a message is already playing back, the current message will be interrupted and playback of the new message will immediately begin. Notes: The Speak Easy is an expansion module that can play back recorded messages or sounds. As explained in the module’s documentation, you may configure it to be able to record and play back many (up to 50) short messages, or a lesser number of longer messages. You can only play back messages under program control. To record messages, follow the procedure under the C-Max module utilities, described elsewhere in this manual. THEN Transmit Ascii Message Module#, Embedded Variable#, Message# Description: Instructs the specified module to transmit the selected ASCII message. The ASCII message can contain a formatting string allowing the specified variable#’s contents to be displayed within the message. The message number can be specified by either a constant or by the contents of a variable. Example: 0001 - IF Module #1 -BOBCAT-T is > -100 // read temperature 0002 - THEN Load Data to: Variable #3 // and capture in var #3 0003 - ELSE Load Data to: Variable #3 // in all cases 0004 - IF Timer #5 becomes > 3600 // once per hour 0005 - THEN Timer #5 = 1 // restart the timer 0006 - THEN Send Module #2 -BOBCAT-A Message 6 w/ Variable #3 // and send the current temp. Timing: The formatted ASCII string is placed in the serial output queue and program execution resumes immediately. For Serial Bobcats or slaves, the command is sent to the module (along with the contents of the embedded variable) and program execution resumes immediately. Notes: ASCII messages can be transmitted by either: the master controller, a slave controller, or a Serial Bobcat. The use of an embedded variable is optional. If there is no formatting string within the ASCII message (ie: “%…”) then the embedded variable will be ignored. A Serial Bobcat must be at release 6 or higher to support embedded variables. Do not send ASCII messages to a controller’s serial port if that port is also being used by an external computer or device to exchange data using the ADI serial protocol. Doing so will cause a conflict and the external device will receive both types of serial messages, and could cause unpredictable behavior. There are several formatting options available for embedded variables. These use the same format strings as the C language’s printf command. See the application note on formatted variables in this manual to see a complete list of the available formatting options along with usage examples. ASCII strings are defined and loaded into your controller(s) or Serial Bobcat(s) using the C-Max controller utilities. See the manual section on using C-Max to learn how to do this. END Description: Terminates execution of the current program pass. Example: 0001 - IF Touch Object #5, Button Leopard is pressed // if light-on button is bressed 0002 - THEN X-10 House G / Unit 3, Turn ON // turn on the light 0003 - End Program // Timing: The program pass is immediately terminated and the command interpreter will begin the process of initiating a new pass. Notes: The END statement is not a standard action statement, but rather a separate command type. This is because the command will execute regardless of the current true/false state (hence the absence of a THEN or ELSE prefix). You can have more then one END statement in your program if you wish. Since the program interpreter executes every line in a program except those skipped over by THEN Skip to statements, the only way your program can get past any intermediate END statements is by having Skip to statements that cause the interpreter to not execute them. In that sense, you can think of intermediate END statements as a shortcut to skipping to the last line of your program. |