Leopard II manual Table of Contents

5.3A Sample C-Max Application, Heat/Cool Thermostat

Also note the “object #” displayed when the pointer is positioned over the buttons you just created, these become the button numbers used when programming. For this example, the “-“ button is object #1 and the “+” button is object #2. Create the two text fields that will display the setpoint and the actual temperature by using the “Large Numbers Only” font setting when adding these text fields. The “%3d” caption allows for displaying up to 3 digits. Also be sure to link the setpoint to the right Variables by clicking “Variable Data in Text” in the field properties. In this example, the setpoint will be in Variable #0 and the actual temperature in Variable #1. Finally, create the text labels to properly identify the temperatures. Feel free to position the various buttons and text fields to your liking; this is what a programmable controller is all about! Below is a picture of the screen created for this example (fig. 94):

Fig. 94

That will work and could be left this way without any further changes, but there is a better way to do this with C-Max. The controller maintains an internal status table of all 256 X-10 addresses and of all module (ie:SECU16) outputs. This means that if it turns on an X-10 module or “sees” and external command coming from any X-10 transmitter to turn a module on or off, it will update its table with the appropriate status. Since our own program is turning the heater on or off, we can consult the status table to see if the unit is already on or off instead of using a Variable to “remember” if this was done. Rewritten to use this, our control logic becomes (fig. 98):

Now, not only is the program easier to understand, but we have “saved” a Variable and also eliminated the two “Then” statements used to update the Variable.

Heat “+“ button is object #2

Cool “-“ button is object #8

Cool “+“ button is object #9

Cool setpoint display is linked to Variable #1

Room temperature display is linked to Variable #4
Heat status light is linked to X-10 status for N/1

Aux Heat status light is linked to X-10 status for N/3

C
ool status light is linked to X-10 status for N/2
Fig. 100
Program Logic

For this application, the entire program will be shown first, and we will then analyze the various program segments, explaining each one by referring to line numbers. This will allow you to see each function in its logical context and make the whole program easier to understand. Here is the program listing (fig. 101):

Line 9 might seem a bit odd at first. This is just a way of having the following five “Thens” executed on every pass. Line 12 is a good example of the usage of extended variables. These variables refer to the module number of a bobcat + 128. In our case, the Leopard is module #0 and the temperature bobcat is module #1 (as you can deduce from looking at line 45). This allows you to copy the bobcat’s temperature reading into a variable, instead of just comparing against it like in line 45. We need to do this because we want to do some math manipulation on it before displaying it (and you cannot link a Leopard screen object to a variable greater than 127 anyway). Also note that this copies the bobcat’s raw data value, which is 100 higher than the temperature in degrees F. (this is to allow reading temperatures below zero without running into negative numbers, which are not implemented as such in C-Max). Be careful with this distinction if you mix bobcat compares and extended variables in your program, like in this application. The final calculated temperature is placed in Variable #4 for screen display.

The four routines for turning the heat on or off, or the cooling on or off are all quite similar and also illustrate a very important point about steady state and single triggering events. First of all, you’ll notice that each of those program sections have two sets of test statements for doing the same thing (if we had parenthesis, these could have been coded as IF (line 45 AND line 46 AND line 47) OR (line 50 AND line 51 AND line 52) THEN lines 48 and 49... this is equivalent here). The reason for the two sets of tests is that to turn on the heat (to use that one as an example), either: 1-The temperature drops below the setpoint due to the room getting colder, with the setpoint timer not running because the setpoint has been set a while ago (lines 45 and 46) or : 2- the temperature was fine, but the user has decided to raise the setpoint, which means the room temperature might have been below the new setpoint for some time, but now we have to wait for the setpoint timer to expire before turning on the heat ( lines 50 and 51). The lesson here is that you will want one and only one single triggering event to cause a single shot action like sending an X-10 command. If you were to look for Timer# 0 becoming 0 AND the setpoint becoming less than Variable #0, these two single triggering events would have to occur during the same pass through the program for the segment to test true, which is almost impossible. Conversely, to look for both conditions simply being true, you would be sending X-10 commands continuously as long as the setpoint is not yet exceeded by the heating in the room. You want to look for a single triggering event plus any other required conditions being already true. Two possible single triggering events thus means two sets of test conditions. This is the reason for all those “becomes” versions of the IF statements. Without them, prgramming would be a nightmare, with the need once again to use variables as flags to accomplish what we can do here with a lot less code. Make sure you understand this concept thoroughly and you will find your programs much easier to design. You must “think through” all the possible conditions and code them appropriately.