After other posts on my temperature controller it's got to the stage of complexity that someone suggested i look at a state machine.
However, despite looking at examples, i can't figure out how to apply the idea to my controller.
I want to maintain the temperature inside a fridge using the compressor and a heater.
So it needs a deadband to stop them fighting each other.
I don't want 'chatter' around either of the high or low points, so for example the fridge needs to come on at the set point plus the difference and stay on until the setpoint is reached and the heater needs to come on at the setpoint minus the difference and stay on until the setpoint is reached.
Can someone perhaps help me understand how to use a state machine in this instance, or perhaps give me some pseudocode to represent what i want?
Grab a piece of paper. Define each state that the equipment can be in. Define how to get from one state to another. Define when to transition from one state to another.
The states might be:
fridge too cold, heater on
fridge too cold, heater not on
fridge too warm, cooler on
fridge too warm, cooler not on
fridge just right
Transitioning from state 1 to state 2 is easy - turn the heater off. Transitioning from state 2 to state 1 is also easy (and the more normal transition) - turn the heater on.
Determining WHEN to transition is the more difficult part. Clearly, you need to know something about the temperature of the fridge to know what state you are currently in. Some transitions are beyond your control, such as the fridge getting too warm or tool cold. Others are within your control.
Some transitions should occur automatically (from "fridge just right" to "fridge too warm, cooler off"). Others require explicit actions (turning the cooler or heater on).
Some transitions should not occur automatically - you might want to wait just a bit to see if the state remains constant - opening the fridge door will result in a change in temperature, but the thermal mass of the contents might drop the temperature again when the door is closed, with no need to actually run the cooler).
For some states, you want to remain in that state until the conditions for change remain true for an extended period of time.
Once you know the states, and what conditions trigger a transition, it is easy to implement the state determination and transition changes as code on the Arduino.
If you need help, post the states you come up with, the transition steps you determine are necessary, and when the transitions should occur.
We can then help you with code to determine the current state or the code needed to transition.
The idea kinda reminds me of analog buttons "using multiple buttons on the same pin". Each button uses different voltage divider so that when pressed they can be read using analogRead. Next, the voltage reading determines which button is pressed. But, in your situation you would determine which state you controller needs to be in.
Using the Paul S. example for the states and assuming 0 - 1024 counts. Also assuming you are using an analog temp sensor.
The states might be:
Ok, so this is what i have so far, only 3 states and 5 transitions. Although i like the idea of waiting after a door open event, i don't think this is something i need to worry about initially.
Have i got the right idea?
state 1 - heater on
state 2 - all off
state 3 - fridge on
state 1 to state 2 - temp @ setpoint
state 2 to state 1 - temp @ setpoint - difference
state 2 to state 3 - temp @ setpoint + difference
state 3 to state 2 - temp at setpoint
Greenbeast:
Ok, so this is what i have so far, only 3 states and 5 transitions. Although i like the idea of waiting after a door open event, i don't think this is something i need to worry about initially.
Have i got the right idea?
state 1 - heater on
state 2 - all off
state 3 - fridge on
state 1 to state 2 - temp @ setpoint
state 2 to state 1 - temp @ setpoint - difference
state 2 to state 3 - temp @ setpoint + difference
state 3 to state 2 - temp at setpoint
While showing it as a state machine, in the process control world such a controller is often called a band-gap controller using a single adjustable set-point value and constant hysteresis value (what you are calling difference) to keep the controls from over cycling around the set-point value. Some call it a bang/bang controller (in that output(s) are either fully on or fully off at any given instant in time) to differentiate from continuous proportional control like the PID algorithm. This kind of control is simpler and cheaper then PID, and can work well for things where the process variable being controlled (here it's temperature) is slow responding and therefore has a high process time lag, and where you aren't requiring or needing a 'tight' temperature control, as in +/- 1 degree control objective. You could not do effective speed control on a motor using the band-gap method.
state 1 - heater on
state 2 - all off
state 3 - fridge on
state 4 - compressor delay
state 1 to state 2 - temp == setpoint
state 2 to state 1 - temp <= setpoint - difference
state 2 to state 3 - temp >= setpoint + difference
state 3 to state 2 - temp == setpoint
state 2 to state 4 - (temp >= setpoint + difference) AND (curent time - last fridge on time <5 minutes)
state 4 to state 3 - (temp >= setpoint + difference) AND (curent time - last fridge on time >=5 minutes)
retrolefty:
While showing it as a state machine, in the process control world such a controller is often called a band-gap controller using a single adjustable set-point value and constant hysteresis value (what you are calling difference) to keep the controls from over cycling around the set-point value. Some call it a bang/bang controller (in that output(s) are either fully on or fully off at any given instant in time) to differentiate from continuous proportional control like the PID algorithm.
I've heard the term band-gap controller before i think.
yes i probably should use the term hysteresis rather than 'difference'.
It's the "do something when the temperature exactly equals the set-point" transition that will cause (is causing) you the most grief. In general, thermostats allow the temperature to drift a little under the set-point (don't turn on until the temp drops to 69 with a 70 set-point) or over the set-point (don't turn off until the temp gets to 71 with a 70 set-point).
but if hitting the setpoint is only the exit transition from state 1 and 2 and not the entry transition then it shouldn't misbehave should it?
The entry transition for either will be at the low/high points (setpoint +/-difference)
Is that not right?
Or am i still misunderstanding a little?
I did say to consider eliminating it, not to eliminate it unilaterally. Whether you need that transition, or not, depends on what new state you end up in when that transition occurs, and what exactly happens in that state.
Since state2 means that everything is off, you get to that state when the heater is turned off, but that doesn't happen at the set-point (it happens when temp gets slightly above setpoint), or when the cooler is turned off, but that doesn't happen at set-point, either (it happens when temp gets slightly below set-point).
Generally, after defining all the states, one determines what actions are required during a transition, and what conditions must be true to trigger the transition. Any state that does not have transitions away from that state, with actions associated with the transition, is eliminated.
In your case, state2 (nothing on) does not have any transitions away from that state. So, is it really needed?
State4 (Compressor delay) looks unnecessary - you can check to see whether enough time has elapsed as part of deciding to transition from all off to fridge on. Also, this way, the controller still has the option to turn the heat on if it becomes necessary, which would not be the case if it was sitting in the delay state.
Don't test for equality in your tests, you may miss it having that value, or your sensor may never report the exact temperature you want. Stop the heater if temp >= setpoint.
PaulS:
I did say to consider eliminating it, not to eliminate it unilaterally. Whether you need that transition, or not, depends on what new state you end up in when that transition occurs, and what exactly happens in that state.
Since state2 means that everything is off, you get to that state when the heater is turned off, but that doesn't happen at the set-point (it happens when temp gets slightly above setpoint), or when the cooler is turned off, but that doesn't happen at set-point, either (it happens when temp gets slightly below set-point).
Generally, after defining all the states, one determines what actions are required during a transition, and what conditions must be true to trigger the transition. Any state that does not have transitions away from that state, with actions associated with the transition, is eliminated.
In your case, state2 (nothing on) does not have any transitions away from that state. So, is it really needed?
Can i not use different conditions to enter and exit a state?
So to enter state 2 the temp has to be at setpoint but to exit state 2 it needs to be setpoint + difference (or setpoint - difference)?
perhaps i'm misunderstanding
wildbill:
State4 (Compressor delay) looks unnecessary - you can check to see whether enough time has elapsed as part of deciding to transition from all off to fridge on. Also, this way, the controller still has the option to turn the heat on if it becomes necessary, which would not be the case if it was sitting in the delay state.
Don't test for equality in your tests, you may miss it having that value, or your sensor may never report the exact temperature you want. Stop the heater if temp >= setpoint.
Can i not use different conditions to enter and exit a state?
So to enter state 2 the temp has to be at setpoint but to exit state 2 it needs to be setpoint + difference (or setpoint - difference)?
Yes you are free to define the 'gap' value(s) to use for your switching decisions. The key is that switch decisions are not just, if (=> setpoint), or if (=< setpoint), as using a single value decision point is where constant output chattering can result. You have to get to know what you normal temperature measurement variation is (how much does the measurement change when the temperature is held constant due to A/D conversion variation, circuit noise, etc), only then can you determine what size 'gap' value you need to use as it has to be larger then the measurement variation plus the 'gap' value you want to use. The down side of gap control is that the process temperature control variation will never be better then the difference (or addition) between the setpoint valve and gap value used. If the gap is 5 degrees then you process temperture is free to vary up to 5 degrees at any given time, instead of the control objective of keeping process temperature held constant at the setpoint value.
it looks like i can have different conditions to move into and out of states
If that is the case then as i asked before, can the entry condition for State 1 (fridge on) be temp< (setpoint -diff) but exit condition to state 2 (all off) be temp >= setpoint?
it looks like i can have different conditions to move into and out of states
Of course you can. The transition defines how to get from one state to another. That the transition from state n to state m is not the same as the transition from state m to state n is common/expected/normal.
