Leopard II manual Table of Contents
|
|  Yüklə 3.21 Mb.
|
2.6Timing is everythingWriting predictable programs requires that you know when events like timer increments, received X10 commands, etc. occur and become available to the running program. Many times, the order in which you will place your program segments will be important, based on the fact of which commands will detect an event first. This is so important that each command type in the reference section of the manual explains it’s timing in relation to the when they occur and when they become valid in the code. It is best to look at the reference section for each specific case but here is a summary classified by how the various command types work: X10 input IR input Touch button presses on a Leopard I/O latched reads ("IF Module/Point" commands) I/O analog reads ("IF Module/Parameter" commands) The main program will look at each one of these queues (or cached value for I/O reads) between program passes and if there is an input for any of these, that value will be true for one entire pass through the program. The I/O values stay as they are for all passes until the bus routine updates them from a new reading, but still only starts to give the new value between passes. Serial (input and output) Leopard screen updates (eg: displayed variables) As soon as the complete serial read or write command is received or whenever the screen processor asks for an update, and can occur between any two-program lines. X10 output IR output I/O value sets (analog and I/O points) These are put in an output queue and get sent out as soon as their respective processors or routines can send them, irrespective of the running C-Max program which is free to continue looping simultaneously. Timers Timers roll over to the next value between passes (unless modified right in the program code). Thus if your program loops 3 times per second, you will get the same value during 3 passes, then the next for 3 passes, etc. Furthermore, timers are aligned with the system clock, so timers all roll over to the next value together, when the real time clock advances to a new "second". This means that if you happen to start a timer just at the very end of a second and the clock rolls over for the next pass, then the timer will have advanced to the next value in that pass. Because of this, timers are only precise to +/- 1 second and short intervals are less precise (% wise) because of this. Time and Date Like the timers which they are related to the system clock as explained above, these roll over between passes, so the lowest numbered lines always see a new time or date first. 2.7C-Max VariablesC-Max variables are integers with values ranging from 0 to 65535. This apparently odd range is because they are internally represented by 16 bit binary memory locations. In a binary system, each bit (from right to left) represents an increasing value of a power of two. Thus the first bit is the 1’s , then the 2’s , the 4’s , the 8’s and so on until we get to the 16th bit which is the 32768’s. This is just like the more familiar decimal system where we have the 1’s, the 10’s, the 100’s, etc. The maximum value that can be represented is when we have each bit set. Therefore if we add 1 + 2 + 4 + 8 +....+ 32768 = 65535. You will notice that in C-Max, there are no negative numbers. The above description of your controller’s variables is called an “unsigned 16 bit integer”. If you try to make a variable go below zero by subtracting or decrementing it past zero, you will see noticed that it “rolls over” to 65535 and then continues to decrement downwards. This is very similar to a mechanical car odometer that counts up to 99999 and then rolls over to 00000. If you then turn it backwards it will show 99999 again and keep decreasing. In binary number usage, there is a convention that allows us to consider a 16 bit number as a “signed 16 bit integer”. In this case, the highest bit indicates whether the number is positive or negative (1 = negative, 0 = positive) and the remaining 15 bits give us the number’s value. We still have the same total range but it is now “shifted” to represent numbers from –32768 to 32767. In that system, called “two’s complement”, the bit pattern for 65535 is equal to “–1”, 65534 = “-2” and so on. This means that the rolling over of your controller’s variables from 0 to 65535 when subtracting or decrementing is already the correct behavior for signed 16 bit integers. Even though you cannot see negative numbers in the C-Max editor, you can still display them on the Leopard II’s screen by using a formatting option that instructs it to interpret it as a signed 16 bit value. See the chapter on Variable Formatting Options to learn how to do this. Although you can interpret and display a negative number on your Leopard screen or in an ASCII string, they are still positive-only in the C-Max instruction logic. This can cause a few surprises if you are not careful with “greater than/less than” type instructions. For example, if you are looking for a temperature as being between –10 and +10 deg F for a true condition, you will need to consider it logically as “IF < 11 OR > 65525”. You cannot use an AND because you are looking for a number that is possibly at either end of the positive number scale. If you want to enter a negative number in the editor, type it in by starting with the “-“ sign and the editor will automatically convert it to the signed equivalent (eg. Enter “-11” and you will see “65525”). Some instructions like IF Compare Bobcat Data expect the numbers to range from –100 to 155 and will display them directly as negative in the editor. 3C-Max Command ReferenceThis section of the manual explains the detailed options available for each type of C-Max command. These descriptions are current as of C-Max 2.00e and may evolve in subsequent versions to add new commands or modify/enhance existing ones. Make sure you read any release notes included with a new version to learn about the latest changes. C-Max commands are of two different types: test statements and action statements. The test statements evaluate the conditions specified in the command options and determine if the statement is true or false. A test statement will be prefixed by one of: IF, AND, or OR; depending on the interaction desired with other test statements before and after it. See the section on Programming the Leopard II to learn how test statements interact to create complex logic. Action statements instruct the controller to do something, like send I/O commands, set variables and timers, display information of the Leopard II screen, etc. . Action statements are prefixed with either THEN or ELSE. A THEN statement will execute if the test conditions prior to it are true, while an ELSE statement looks for the conditions to be false. The END statement is a standalone action statement that executes in all cases (ie: whether the test condition is true or false). The following pages describe each statement type along with the options available. First the test statements will be described, each one listed in the order that they appear (from the top, down) in the C-Max Control Wizard. Following that are the action statements, also arranged by Control Wizard order. For brevity, only IF and THEN will be shown as the prefixes for the commands although the syntax remains the same if the other prefixes are used. The description section describes the various options and behavior of the command. A short example of each command usage is shown. The timing paragraph describes what timing considerations apply to this command, important for predictable operation. The work variable paragraph (test statements only) describes what data will be captured if a Load Data to Variable command follows the test command being described. Finally you will see notes, explaining any special considerations pertaining to this command. IF Module / Point Module#, I/O point, I/O Status Description: Tests the status of an expansion module I/O point. 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. Module inputs and outputs are determined to be either on or off by the module’s internal logic (see module documentation). The Leopard II maintains an internal status table for each possible I/O point. The IF Module / Point command consults this table to see if the I/O point is currently on or off (Is OFF, Is ON) or if the transition from one state to the other has just occurred (Turns OFF, Turns ON). This latter option simplifies the creating of a single triggering action when only detecting the change is important. Example: 0001 - IF Module #1 -SECU16 Input #0 Turns ON // If switch on input 0 closes 0002 - THEN X-10 House J / Unit 1, Turn ON // turn on light at J/1 Timing: The controller’s bus routine interrogates the modules continuously, independently from the running C-Max program. Whenever a transition from on to off (or vice versa) occurs, the “Turns” action will be true for one complete pass through the program, at the beginning of the pass following the one during which the change actually occurred. Work Variable: None. Always 0. 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 status options. See the manual section on Projects to learn how to create/maintain the System Map. IF Module / Param Module#, Parameter#, Comparison, Data Description: Compares the value of an analog input (module) or a slave variable (slave controller) against the specified data; either a constant or the contents of a variable. Analog module inputs such as the ones available on the SECU16, SECU16I or some Bobcat modules return a value ranging from 0 to 255. Consult the module’s documentation to see the available values and corresponding parameter numbers. When the specified module# is a slave controller, this command will obtain the contents of the slave’s variable that corresponds to the parameter number, and the returned value can range from 0 to 65535. The requested slave parameter# can range from 0 to 51. Example: 0001 - IF Module #1 -Slave Leopard Variable #4 is = 55 // If slave's var. 4 = 55 0002 - THEN Load Data to: Variable #7 // capture value in local var. 7 Timing: The controller’s bus routine interrogates the modules continuously, independently from the running C-Max program. The latest value for a module/parameter pair is always cached in the controller’s memory so that the program line can be executed immediately. This means that depending on the length of the program and the number of expansion modules, the program may make one or more passes through the code before a new version of the analog value is obtained. Whenever a new, updated parameter value does become available, it will be presented at the beginning of the next pass through the program. This allows for predictable “becomes” behavior whereby the lower numbered program lines always see a value change first. Work Variable: Captures the analog value of the parameter being tested in the work variable. Notes: Your expansion module or slave controller must be defined in the System Map or else the Control Wizard will not show you the parameter, comparison, and data options. See the manual section on Projects to learn how to create/maintain the System Map. The large potential number of modules and number of parameters per module means that the master cannot track all of them; too much time would elapse between updates. Instead, the controller establishes a table of module #’s and parameter #’s to keep track of. The table is built up during the first pass following the starting up of the program and any IF Module/Param commands get their module and parameter number added to the parameter tracking list. This list has a maximum of 40 entries (as of C-Max 2.00e). This means that if you have more then 40 such commands in your program code, the 41st and any subsequent such lines will be ignored. Each IF Module/Param command adds an entry to the list, even if the same module and parameter number are already entered from a previous line. This means that if you will be making several comparisons against the same module/parameter pair, it might be worthwhile to use one IF Module/Param early in your program and capture the value in a local variable (using the work variable). You can then make your multiple comparisons against the local variable instead. Master and slave controllers have internal parameters that are set using C-Max to configure such things as their Adnet address and other options. Reading a slave parameter with the IF Module/Param will not read these values, but will instead return the slave’s corresponding variable number as described above. IF Receive Single X10 House code, Unit or Command code Description: Looks for the reception of 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. To look for X10 command pairs, see IF X10 Status/Cmnd Pair. Example: 0001 - IF Receive X10, B - 6 // If module at B/6 is being addressed 0002 - THEN Timer #3 = 1 // Then start timer 3 0003 - IF Receive X10, B - Status Request (31) // If Status Request is received 0004 - AND Timer #3 is > 0 // and timer is running 0005 - THEN Transmit X10, B - Status ON (29) // reply with Status ON 0006 - THEN Timer #3 = 0 // and stop the timer 0007 - IF Timer #3 becomes > 4 // if timer exceeds 3 seconds 0008 - THEN Timer #3 = 0 // then just stop the timer 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. The command is packed in a way that allows a complete X10 command pair to be held in a 16-bit variable. This is because the X10 input buffer is also used by the IF X10 Status/Cmnd Pair command, which can look for a command pair. You can parse the 16-bit variable into two individual 8-bit fields using the divide and modulo math operators. The fields break down as follows (values are shown in hexadecimal): Highest 8 bits = House code. Lowest 8 bits = Command/Unit Code: 00 = House code A 00 = unit code 1 01 = House code B 01 = unit code 2 … …
0F = House code P 0F = unit code 16 10= All Units OFF 11 = All Lights ON 14 = Dim
15 = Bright 16 = All Lights OFF 17 = Extended Code 18 = Hail Req. 19 = Hail Ack. 1A = Preset Dim 0 1B = Ext. Data 1C = Status ON 1D = Status OFF 1E = Status REQUEST 1F = Preset Dim 1 40 = unit 1 OFF 41 = unit 2 OFF … 4F = unit 16 OFF 80 = unit 1 ON 81 = unit 2 ON … 8F = unit 16 OFF When there are no X10 commands in the input buffer, the value returned is 6363 hex. Note that all the values listed above are in hex. The variables normally display in decimal so be sure to make the appropriate conversion. Notes: This command is useful when you’re looking for raw X10 or for some of the more unusual 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 IF X10 Status/Cmnd Pair command is more useful to look for those. Since this command is usually used in more unusual circumstances, System Map names are not used either, 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. You will notice that there are no standalone ON or OFF commands in the work variable table. This is because receiving a command pair such as B/6, B/ON will actually return (in the packed variable) 0105 hex (B/6) followed by 0185 hex (B/6 ON). In other words, the previously addressed unit code is retained and encoded along with the subsequent B/ON command to put the entire B/6 ON command pair in the input buffer location. This is what allows the IF X10 Status/Cmnd Pair command to look for a command pair while needing only one input buffer value. The program example above shows one use for this instruction. Requesting X10 status is a command pair operation whereby you send the house code/unit code followed by the house code/Status Request command. Since C-Max doesn’t have a “Status Request command pair” option under the IF X10 Status/Cmnd Pair command, you can make your own equivalent by looking for the unit being addressed (line 1). If it is, start a timer that will give the program 3 seconds to receive the B/Status Request command. Lines 3 to 6 look for the B/Status Request command to be received while the timer is running. If it is, it returns the ON status and stops the timer. If the B/Status Request command is not received within 3 seconds, lines 7 and 8 cause the waiting period to simply time out. 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. IF Compare Bobcat Data Module#, ,Comparison, Data Description: Compares the analog value of a Bobcat against the specified data; either a constant or the contents of a variable. Bobcat modules return a value ranging from -100 to 155 (see the chapter earlier in this section on C-Max and negative numbers to learn how to process them in program code). The Bobcat’s documentation will explain the meaning of the values returned, and this varies by Bobcat type. Example: 0001 - IF Module #1 -BOBCAT-T becomes < 32 // If temperature goes below freezing 0002 - THEN X-10 House E / Unit 8, Turn ON // turn on the heat. 0003 - IF Module #1 -BOBCAT-T becomes > 34 // If temp. is now 3 degrees above freezing 0004 - THEN X-10 House E / Unit 8, Turn OFF // turn off the heat Timing: The controller’s bus routine interrogates the modules continuously, independently from the running C-Max program. The latest value for Bobcat is always cached in the controller’s memory so that the program line can be executed immediately. This means that depending on the length of the program and the number of expansion modules, the program may make one or more passes through the code before a new version of the analog value is obtained. Whenever a new, updated Bobcat value does become available, it will be presented at the beginning of the next pass through the program. This allows for predictable “becomes” behavior whereby the lower numbered program lines always see a value change first. Work Variable: Captures the analog value of the parameter being tested in the work variable. Notes: Your Bobcat must be defined in the System Map or else the Control Wizard will not show you the comparison and data options. See the manual section on Projects to learn how to create/maintain the System Map. Capturing the Bobcat value with the work variable can be useful if your intention is not just to compare the value but actually capture it in a variable for logging it or displaying it on the Leopard II screen. IF Timer (seconds), Timer#, Comparison, Data Description: Compares the current value of a Timer against 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 by program code or if it counts up to 65535 after which it rolls over to 0 and stops by itself. Example: 0001 - IF Timer #0 becomes > 10 // If timer becomes equal to 11 or more 0002 - THEN Timer #0 = 0 // then stop the timer 0003 - THEN Leopard, Zone 0 IR# 45 // and transmit IR code # 45 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. Work Variable: Captures the current value of the Timer in the work variable. 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. IF Variable, Variable#, Comparison, Data Description: Compares the current value of a Variable against the specified data; either a constant or the contents of another Variable. Example: 0001 - IF Variable #3 becomes = 1 // If variable becomes = 1 0002 - THEN Send Module #1 -SPEAK-EZ Audio Message #4 // then say message #4 Timing: Variables are set by program code immediately and will stay at that value until modified again by another instruction later during program execution. If the Leopard II is connected to an external computer or device that sets variables using the serial protocol, the change can occur between any two program lines, as soon as the serial protocol command is received. When a variable’s value changes, a “becomes” test for it will correctly see that change for an entire loop through the program. This means that if line # 75 changes Variable #3 from 0 to 1; a line looking for variable #3 becoming = 1 will test true whether that line is after line# 75 during the same pass or if the line is before line #75 during the following pass. This allows for predictable “becomes” behavior regardless of relative line position. The “becomes” behavior is accomplished in the following manner: At every pass, the specified logic test is done and a one bit flag is saved in memory indicating if the test was true or not. On subsequent passes, the logic test is done again and the true or false result is compared against the status of the saved one bit flag. If the current logic test is true but the one bit flag indicates that in the previous pass the logic test was false, then it is determined that the test has “become” true and the statement itself is deemed to be true. If the logic test is true but the flag indicates that it was also true in the previous pass, then the statement will be deemed false since the logic test hasn’t just “become” true, but already was. Work Variable: Captures the current value of the Variable in the work variable. Notes: 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 tested, 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. |