Announcement

Collapse
No announcement yet.

Closed Loop Temp Control for spa/pool

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Closed Loop Temp Control for spa/pool

    Hey, i'm using mcstemperature plug-in. i have 1-wire temperature probe in the water line for the spa, read by webcontrol, xap, homeseer, etc., working great. i have "registered" this sensor with mcstemperature. i am trying to turn heater on, simple bang-bang control, with 100.0 as lower limit and 100.3 as upper limit. i have an event (Water Temp Control) that is triggered by a Virtual Device (Pool Heater Control Mode) having status "Set On". The action is a mcstemperature action, conditional for when pool pump is on (checkbox at bottom left checked...)the action is to turn heater device on when water temp below lower limit (100.0) and turn heater off when water temp above upper limit (100.3). so very little deadband needed for this system due to thermal properties of system. the problem is that the closed loop control i describe above using mcstemperature action works about 80-90% of the cycles. occasionally, the heater will either stay on (well above 100.3 and continue to go up), or stay off (well below 100.0). i know this is long-winded but perhaps i can send a screenshot of the trigger/action settings if needed?

  • #2
    I believe the DS18B20 has accuacy of 0.5C and resolution of 0.125C. This means you are trying to control within the uncertainty of the sensor. The general debug contains output that shows the control actions being taken and this output is what is needed to describe behaviors. Such a tight band does seem problematic.

    Comment


    • #3
      I understand the problem, but I don't see a question.

      What I see happening here is this.
      - The temperature goes below 100.0 then,
      The heat is turned on, but the system is still cooling until the heater overcomes the loss.
      - At any time 100.3 degrees is attained, the heat is turned off but the system has not quite reached equilibrium and isn't stable (the whole system may not be at the upper limit), so another cycle could very well start leading to the overshoot.

      Obviously, the best solution is PID control (Proportional, Integral, Derivative) which would take all of this into account and more closely control the system temperature.
      You can simulate part of this algorithm (the Derivative) by introducing a delay. ie. Temperature is at or exceeds the upper/lower limit for X seconds before taking action. The two delays would be independant of one another and would be determined experimentally. Naturally, these would be dependant on the surrounding temperature, further complicating the calculations.

      Bottom line: If you need to control your temperatue that closely, it would be best to get hold of a hardware PID controller which could accept the setpoint from Homeseer via a serial interface. The RedLion model TCU (http://www.redlion.net/Products/Proc...unted/TCU.html)would be ideal and is relatively cheap.

      (All of this comes from 30 years of industrial temperature control experience).
      Real courage is not securing your Wi-Fi network.

      Comment


      • #4
        understood on sensor accuracy, but it's acting smooth and repeatable, not jumping around by more than .1 or .2 deg (which makes sense given resolution you cite). i don't *think* that's problem. bottom line is if temperature is at 104 and the heater is still on, then there is a problem. never should get that high without the heater turning off. that tells me the "action" has ended, loop no longer "closed". conversely, if the temperature is below 100 (and falls to 99 for instance...), the heater should come on. for some reason the event is ending, only way to start it again is by cycling the trigger off and on (my Virtual Device, Water Temp Control). don't think i need PID either...overkill for this system...if the heater turns off at the right time...it only overshoots by .7 deg max, not a big deal at all. heating up the spa is VERY quick compared to cooling down. for instance, it will heat up at least 10 times faster than cool down due to the thermodynamic properties of the system. overshooting is not the problem...losing closed loop control is the problem. and it only happens some of the time, just seems to "jump" out. I've also noticed there seems to be some built in delay before the "Turn device" is turned on or off, that may be by design. i have a feeling this is a real simple one related to user error as usual but it's certainly acting strange the way i have it configured. I'll check the general debug box and try again tomorrow. getting lots of hot tub time at least...lol.

        Comment


        • #5
          closed loop control ran for 4 hours flawless after debug turned on. go figure. however, when i ran a script and turned off the heater and the Virtual Heater Control Device (the trigger device for mcstemperature event), the heater still came back on when the temp went below setpoint. so in this case i WANTED it to stop closed loop control and it didn't...i guess one problem at a time....what is the proper way to stop a mcstemperature event? i have it set for "when device is manually turned on/off" and i use a script to turn off the heater (not manual enough maybe...?)...

          i probably need to take a breath, start over and say: this is all so overcomplicated for what i need which makes it frustrating. If there was a built in conditional in Homeseer or plug-in to turn a device on when temp is above a value, and turn it back off when it gets below (the same) value my problem would be solved for this application. don't really need upper and lower limits for this because the overshoot is enough, and cooldown period long enough to give a "natural" bandwidth.

          So my pseudo-code would be:

          when virtual device "temp control mode" on:

          if temp over setpoint, turn off heater (or make sure it's off),

          else, turn on heater (or make sure it's on).

          when virtual device "temp control mode" is off

          ensure heater is off, and stop.

          that would work great...i just don't know how to implement in this configuration. sigh.

          Comment


          • #6
            Xapmcs1wire creates a switch device for each temp sensor and the limit or upper/lower limit entered for the calibration field. The switch device then turns on/off based upon the temperature. I do not recall if mcsTemperature does this or not. Another simple technique is with periodic event that runs script where you put control logic of interest. Two events trigger on device value over / under a limit with action to control relay/device should also work.

            Comment


            • #7
              thanks, i ended up using two events, triggered by device value change which i had not realized allows you to compare device value using "greater than" or "less than". rounds up to integer and control not as tight but will do for now until i figure out something better.

              Comment


              • #8
                after conquering on/off control, i've now actually gone overkill (couldn't resist) and implemented type C PID controller. webcontrol board has PLC programming capability, i just turn the controller on using output from another board. works like a charm, needs a little tuning. it basically will turn on heater certain number of seconds out of 4 minutes (or whatever i set timing interval to) based on temp, error, change in temp, etc. per type C equation.

                Comment


                • #9
                  This is a perfect application for WebControl. The xAP connector (xapmcsWebControl) I developed provided a UI for thermostat control where the user did not need to do any programming. This was only for the BRE version. The BRE is not able to support things like derivative control. The problem I typically run into with the components we are using is the resolution of the sensor from which the rate of temperature change is measured. By the time the rate is sufficiently filtered its response is so slow that it become useless in the PD/PID controller. In your case your temperature change may be sufficiently slow that you can make effective use of the derivative term.
                  Last edited by Michael McSharry; February 11th, 2012, 03:40 PM.

                  Comment


                  • #10
                    i've got P and I tuned pretty good now, haven't even messed with D yet. it ramped right up to setpoint, overshot by only .5, then settled in right at setpoint plus or minus resolution of sensor (~.2). i'll tweak some more later and may or may not add D. this system will be hard to make "perfect" because of the differences in response when approaching setpoint from below and above. heat gain from heater is much higher than heat loss to the air... but main shocking thing i just found out is that the PLC code is wiped out when power is lost to my board...i may have to transfer the algorithm to an HS script. i find this hard to believe, i know i have old firmware version and i've got newer one on the way, hopefully it stores PLC code in EEPROM. i've also had to do some math tricks to get around the 16 bit integer limitation for this version. but it's working.

                    Comment


                    • #11
                      here is link to graph showing it working. finally.

                      https://picasaweb.google.com/lh/phot...eat=directlink

                      Comment


                      • #12
                        Maybe there is a commit mode to transfer the PLC to EPROM rather than a shadow RAM. I have never worked with the PLC unit at that level to know.

                        The only reason you want the derivative is to anticipate and avoid overshoot. A good chance that if your rise time is sufficiently slow that overshoot will not be a problem and similarly it is not unstable so oscillation will not be an issue. If your heater is oversided for the amount of water being heated then the rise time will be fast and the derivative may be of value. Like I indicated before you will likely introduce more error in the control trying to get a good derivative signal than not using it.

                        Comment


                        • #13
                          it's definitely not supposed to lose PLC code according to manual, but maybe i have such an old board that it does. or maybe just unexplained anomaly that will not happen again...

                          Comment


                          • #14
                            new board came in and it's the latest 2.2.2 hardware version with latest firmware (3.2.11). installed and works great.

                            as far as setting setpoint is concerned, i have yet to be able to figure out how to use a mcstemperature-created thermostat device in an event to trigger script...right now, i'm trying to trigger on device state change...i've also looked at value change....should one of these work? basically i just want to allow user to change thermostate device, take the value via script and send to webcontrol VAR4 variable using the api http command. any ideas?

                            Comment


                            • #15
                              The mcsTemperature thermostat device constains an enumerated set of device value pairs. The values will be 1, 2, 3 etc. depending upon the resolution requested when the device was setup. If you set the device to the lowest temperature I would expect HS to report a device value change with the value of 0. If you set it to the next lowest setting then the value would change to 1. I could be off if the set starts with 0 or 1, but it is incremental for each click of the thermostat dial. I am not positive if HS makes the text associated with the value pair visible to the user other than on the Device Status Page selector. You will need to play with it to see what capabilty HS provides.

                              Comment

                              Working...
                              X