Here is an example for a two stage heat, two stage cool rooftop unit.
1 Like
Inputs:
We’ll use the on board temperature sensor of the Tstat10 for the room temperature feedback, this shows up as input9 on the Tstat10. Click at Tab1 to select the type of sensor and the engineering units, the sensor is hardwired on the PCB itself so the only choice here which makes sense at Tab2 is the Type2 10k thermistor. You also specify DegC or F at Tab3, we’ll use DegC for this example.
Give each IO in the system a user friendly 20 character name at Tab4 and a short name at Tab5. The long names are used in the graphics displays while the short name is used mainly in the programming. These names should be unique in the system so assuming there’s many Tstat10 in the building we’ll use ‘101’ to preface everything on this particular thermostat.
We could also use an external temperature sensor wired to any of the eight UIs on the backplate. In this example we configure a 10k thermistor wired to input1, similar to input9. Notice the unique name at Tab6 to differentiate it from input9 at Tab5.
We’ll explain later in the PID section how to make use of one or the other of these two sensors. Maybe we’ll use both and take an average of the two, more on that later as well.
1 Like
Outputs:
Type in the name of all the outputs as shown at Tab7. Again they should all have a unique name at Tab9. Select the OFF-ON range at Tab10. Any output can be picked for heating or cooling, the function is determined entirely by our naming here and the programming later.
Variables
Next up is the variables, we’ll use these to store the setpoints and various modes of the equipment. Notice the short labels show up on the Tstat10 display at Tab12, the first three VARS of the Tstat10 are tied in firmware to what the user will see on the LCD so the naming is important. Since the current system only supports three characters here we pick simple names like SET for the setpoint on the two line of the LCD. Next comes FAN for the second line and SYS for the third. This lets the thermostat mimick the modes users are used to seeing on a conventional thermostat.
The FAN and SYS variables use what we call "Multi State Variables’ or MSVs for short. These are like a normal analog variable but they only hold a few discrete states like ON,OFF and AUTO as shown at Tab14 and 15.
Variable number 2 will mimic the ‘fan’ mode that users are accustomed to seeing on their stats, they can set the fan to manually on or off, or they can let it run in auto mode where it’ll be on only during heating or cooling. A variation on this would be to delete the “ON” row and only use OFF and AUTO to let the program take care of the fan for the most part. If the fan had multiple speeds you could let the user select LOW, MED, HIGH here as well.
Variable three is the usual OFF-HEAT-COOL-AUTO which the user is used to seeing on the usual thermstats as well. Adjust this as you like to match your equipment, if there’s cooling only for example just get rid of the row for heat.
SETPOINTS
These are variables as well but we’ll use a separate section to describe them.
The current setpoint for the system will be displayed on the LCD and there’s only one ‘setpoint’ which the user will be in charge of at the keypad so we need to work out a way to do heating and cooling off of this single setpoint. Additionally there’s the occupied and unoccupied setpoints, these will all need separate variables and some logic to make them work together.
I have borrowed a screen shot here from the user interface of the Tstat8 which has all these parameters hard coded into the firmware. This hardcoding makes things quick & easy with the Tstat8 but its not so flexible when setting up any sort of custom logic as we will see with the programmable Tstat10.
Looking at this diagram we’ll need a heat and cool setpoint for the day time / occupied period and the same for the night mode or unoccupied period. We’ll create a variable to hold the current heating and cooling setpoint, this will evolve but for now here’s the preview of the variables related to the setpoints.
SCHEDULE
Here’s how to set up the occupied schedule, first give the schedule a long and short name at Tab18 which will be used in the programming. Next hit the “Ins” insert key or click at Tab19 to enter the detailed dialog shown. Enter the times on Monday and then use the copy button at Tab20 to speed up the data entry. Since this is a residential application we’ll ignore the Holdays at Tab21. When setting up a commercial building you can define special schedules here for days like Christmas when the building would be unoccupied.
PID For Heating and Cooling Modes
We could use normal deadband logic to bring on heating and cooling but we may as well use the PIDs since we have them. A system without PID will sit near the setpoint for a long time without kicking on the heat or cool whereas a system using PID will nudge the system along and be a little more responsive.
At Tab22 is the feedback from the system, we’ll use the on board temperature sensor for this example but it could also be the external temperature sensor wired to input1 or other complex scenario with multiple sensors and logic tied to a variable.
At Tab23 is the setpoint, we’re using a separate variable for heating and another for cooling so as to have some deadband between heating and cooling modes. At Tab4 we set the action to ‘+’ for cooling which means as the sensor goes over the setpoint the feedback increases. Heating is the opposite and if you forget a popup will remind you every time you change it.
The P terms are both set to 1 which means the system will respond by 100% when the temperature is 1 DegC over or under setpoint. Regardless of whether you are in DegF or C you can start with 1 Deg and tune it up later. The I term is set to zero to get started, this is the integral term which will add up the temperature error over time and nudge the system along as alluded to above, set it to zero to keep things simple during inital debugging.
So this is all set to go, PID1 is for the cooling action and PID2 is for the heating action. Now we need a small program to connect the outputs to these PIDS.
PROGRAMMING
I have broken this up into three separate programs as I was having trouble with sending larger programs over the subnetwork. (Working on fixing that now). This first section of code is super simple, if we’re in the occupied mode then the cooling and heating setpoints will follow the ‘occupied setpoints’ previously set up. If we’re in the unoccupied period the setpoints follow the ‘unoccupied setpoints’. Note that there’s a separate heating and cooling setpoint with a small deadband in between. The user has only one setpoint on the LCD display so we have to work out a way to coordinate this one setpoint with our four separate heating, cooling & occupied (or not) setpoints. More on that later as we first work through the basics.
Next up are the actual outputs, these are programmed to kick in as the PIDs increase and decrease in value. If PID1 hits 50% which is at a half degree over setpoint then the first stage cooling will come on. If it hits 80% then the second stage will also be enabled. The stages are disabled with a small deadband at lines 30 and 50, its rather arbitrary these numbers but we do need that gap between stage 1 going on and stage 2 going off or we could get some strange cycling happening.
The variable called 101HM is the heat mode, if its not enabled we will lock out the heating outputs in lines 60 and 70. There’s some logic in the next section for the heat mode and cool mode, the logic can get complex so we keep it as a variable separate from the programming for the outputs themselves. Heatmode will let us do a changeover delay and user keypad actions that will tell the system when heating is OK. There’s also a Coolmode variable locking out cooling in lines 130 and 140.
General Notes
Lines further down in the program will override lines further up, this lets us keep the program lines simple with one or two functions at most taken care of per line.
There are no GOTOS in this program which makes it easy to follow. The system will run through all the logic and at the end of the program it will update the outputs with the calculated output state. There’s no need to restart the program with a goto up to the first line, the system will take care of that automatically.
10 REM ******HEATING OUTPUTS *********
20 IF PID1 > 50 THEN START 101HT1
30 IF PID1 > 80 THEN START 101HT2
40 IF PID1 < 30 THEN STOP 101HT1
50 IF PID1 < 60 THEN STOP 101HT2
60 IF NOT 101HM THEN STOP 101HT1
70 IF NOT 101HM THEN STOP 101HT2
80 REM ******COOLING OUTPUTS *********
90 IF PID2 > 50 THEN START 101CL1
100 IF PID2 > 80 THEN START 101CL2
110 IF PID2 < 30 THEN STOP 101CL1
120 IF PID2 < 60 THEN STOP 101CL2
130 IF NOT 101CM THEN STOP 101CL1
140 IF NOT 101CM THEN STOP 101CL2
150 REM ***** FAN ******
160 IF 101CL1 OR 101HT1 THEN START 101FAN ELSE STOP 101FAN
TOBEDONE: More coming soon.
4 Likes