Basic arduino questions.
- Thread starter Eighty2Fifty1
- Start date
Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:
OP
OP
Eighty2Fifty1
Well-Known Member
Actually, both of your replies were extremely helpful. I think I'm at the step where I need to get the program to recognize the DS18B20's output as a setpoint. I plan on using 2 IF statements for the program, one for heating and one for cooling, rather than a PID. Just so you guys know, I have zero experience with any type of programming. I'm pretty comfortable working with the wiring side of the project, as my background is as an aviation electrician.
Great! The programming is easy then.
The DS18B20 is not your setpoint, though. The setpoint is the number that you pick arbitrarily as the temperature you want your machine to hold steady at. The number the DS18B20 gives you is your measured value. The whole point of your program is to make your measured value stay very close to your setpoint.
So, from the looks of it, you've already got your temperature probe working, which is good. The 1-wire protocol is far and away more complicated than anything else you'll need to code. Take a look at the following code and see if you can follow it. If not, let us know what's not clear:
PHP:
// declare which pins you're using to hook up your relays
// right now, i've set heating to pin 2 and cooling to pin 3
// but you can change these to whatever is convenient
const int heaterPin = 2;
const int coolerPin = 3;
// declare your target temperature
// at some point, you'll want to have the ability to change
// this without recompiling the program. but for now we'll
// hardcode it in
float tempSetpoint = 68.0;
void setup() {
Serial.begin(9600)
pinMode(heaterPin, OUTPUT);
pinMode(coolerPin, OUTPUT);
//******DS18B20 setup stuff**********
}
void loop() {
float tempReading = //**get your DS18B20 reading**
if (tempReading > tempSetpoint) {
digitalWrite(heaterPin, LOW);
digitalWrite(coolerPin, HIGH);
}
else if (tempSetpoint > tempReading) {
digitalWrite(coolerPin, LOW);
digitalWrite(heaterPin, HIGH);
}
}First, don't actually use this code, as you need some code to prevent your system from switching on and off quickly as it hovers right around the setpoint. I'll help you with that once you're clear on this simpler code.
But, conceptually, does it make sense? Can you follow the programming?
carlisle_bob
Well-Known Member
Hi
You actually need two IF statements. One to turn on the heater at 72 (say) degrees and the other to turn it off at 76 degrees. That way it comes on when things cool down to 72. It stays on until the gizmo warms up a bit.
With a single set point, the heater comes on and then likely turns off very quickly. The result is a heater that cycles a lot and a system that probably wears out quickly. There are also some issues with gain and phase margin, but that's getting a bit far into control theory.
Bob
You actually need two IF statements. One to turn on the heater at 72 (say) degrees and the other to turn it off at 76 degrees. That way it comes on when things cool down to 72. It stays on until the gizmo warms up a bit.
With a single set point, the heater comes on and then likely turns off very quickly. The result is a heater that cycles a lot and a system that probably wears out quickly. There are also some issues with gain and phase margin, but that's getting a bit far into control theory.
Bob
OP
OP
Eighty2Fifty1
Well-Known Member
Okay, so I was able to add in your code to the one I had copied and pasted to read the sensor, but I guess I need to add something so that it recognizes the tempReading and tempSetpoint commands. Here's what I've got so far.
PHP:
#include <OneWire.h>
#include <DallasTemperature.h>
// Data wire is plugged into pin 2 on the Arduino
#define ONE_WIRE_BUS 2
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
DeviceAddress insideThermometer = { 0x28, 0x7D, 0x7E, 0x11, 0x04, 0x00, 0x00, 0x2A }; //I got the address of my sensor from another program I found online
const int heaterPin = 8; // I have LED's plugged in instead of my relays
const int coolerPin = 10;
float setpoint = 28.0;//I'm not sure what this
void setup(void)
{
// start serial port
Serial.begin(9600);
pinMode(heaterPin, OUTPUT);
pinMode(coolerPin, OUTPUT);
sensors.begin();
sensors.setResolution(insideThermometer, 10);
}
void printTemperature(DeviceAddress deviceAddress)
{
float tempC = sensors.getTempC(deviceAddress);
if (tempC == -127.00) {
Serial.print("Error getting temperature");
} else {
Serial.print("C: ");
Serial.print(tempC);
Serial.print(" F: ");
Serial.print(DallasTemperature::toFahrenheit(tempC));
}
}
void loop(void)
{
if (tempReading > tempSetpoint) {//I added this IF statement from your suggestion
digitalWrite (heaterPin, LOW);
digitalWrite (coolerPin, HIGH);
}
else if (tempReading < tempSetpoint) {
digitalWrite (heaterPin, HIGH);
digitalWrite (coolerPin, LOW);
}
delay(2000);
Serial.print("Getting temperatures...\n\r");
sensors.requestTemperatures();
Serial.print("Inside temperature is: ");
printTemperature(insideThermometer);
Serial.print("\n\r\n\r");
}tempReading and tempSetpoint aren't commands, they're variables.
You need the line "float tempSetpoint = 68.0" at the beginning of your program (replace "float setpoint = 28.0"). The 68 is meant to be your target temperature. You can replace that with whatever you want.
Then, you need to get a reading from your temp sensors at some point. You could add the following two lines:
float tempC = sensors.getTempC(deviceAddress);
tempReading = DallasTemperature::toFahrenheit(tempC);
at the beginning of your loop to accomplish that.
here's the arduino PID library if you want to play around with it. It's actually rather user friendly only hard part really comes in when deciding on the control constants, but that it kinda fun to play around with.
http://arduino.cc/playground/Code/PIDLibrary
Edit: Oh and a thread on using the autotune library as well
https://www.homebrewtalk.com/f235/pid-settings-arduino-based-hlt-328239
http://arduino.cc/playground/Code/PIDLibrary
Edit: Oh and a thread on using the autotune library as well
https://www.homebrewtalk.com/f235/pid-settings-arduino-based-hlt-328239
It's a nice library, and I use it on several different projects. I never got the autotune to give me values that I was happy with, but it can be good for getting into the right ballpark.
Just to clarify, though...PID control will work for the light bulb heating, but not for any compressor-based cooling like a fridge.
carlisle_bob
Well-Known Member
Hi
In general PID works better for static loads than for dynamic ones. If you run 1 gallon in a pot now and 30 gallons later, your coefecients are going to be a compromise (as in not so great) fit for one or the other.
Better to get the basics worked out with a setpoint controller.
Bob
I've been thinking about fancy ways to do the fridge thing with PID. My current thoughts are to toss temp data into an array that covers a fixed time period (say 5 minutes with samples every 30s) and run a moving window on it for stats, and calculate my own I and D terms off that.
Then for the control, since duty cycles on a compressor should have a window size of about 1 minutes or so as it won't be able to take rapid PWM type cycles. We can spit out an PID output as a # between 10 and 60, and have that be the # of seconds every minute that the compressor should be working.
carlisle_bob
Well-Known Member
Hi
Scale that all up by a bit....
The compressor in a normal freezer should stay off for at least 15 minutes, and more commonly 30 to 45 minutes. A typical rep rate for PWM on a freezer compressor system is an hour. At that point, the PWM PID really doesn't do you a lot of good. Your local environment changes to fast. With a fridge cycles are maybe half those numbers, but still slow enough to make PWM problematic.
If you really want to go crazy, there are indeed refrigeration systems that will do short cycles. The compressor never turns off at all. They simply valve gas here and there to do the control. Tenny Jr enviromental chambers are one example, there are others.
Bob
Scale that all up by a bit....
The compressor in a normal freezer should stay off for at least 15 minutes, and more commonly 30 to 45 minutes. A typical rep rate for PWM on a freezer compressor system is an hour. At that point, the PWM PID really doesn't do you a lot of good. Your local environment changes to fast. With a fridge cycles are maybe half those numbers, but still slow enough to make PWM problematic.
If you really want to go crazy, there are indeed refrigeration systems that will do short cycles. The compressor never turns off at all. They simply valve gas here and there to do the control. Tenny Jr enviromental chambers are one example, there are others.
Bob
OP
OP
Eighty2Fifty1
Well-Known Member
OK, I made a few more modifications to the code, based on MalFet's suggestions. It still is giving me an error when I click Verify
The error is "expected primary-expression before ')' token". I'm sure it's something simple, but I'm starting to understand how this stuff works a bit. You guys' help is awesome, by the way.
PHP:
#include <OneWire.h>
#include <DallasTemperature.h>
// Data wire is plugged into pin 2 on the Arduino
#define ONE_WIRE_BUS 2
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
DeviceAddress insideThermometer = { 0x28, 0x7D, 0x7E, 0x11, 0x04, 0x00, 0x00, 0x2A }; //I got the address of my sensor from another program I found online
const int heaterPin = 8; // I have LED's plugged in instead of my relays
const int coolerPin = 10;
float tempSetpoint = 68.0;//Will this differentiate between deg F and C?
void setup(void)
{
// start serial port
Serial.begin(9600);
pinMode(heaterPin, OUTPUT);
pinMode(coolerPin, OUTPUT);
sensors.begin();
sensors.setResolution(insideThermometer, 10);
}
void printTemperature(DeviceAddress deviceAddress)
{
float tempC = sensors.getTempC(deviceAddress);
if (tempC == -127.00) {
Serial.print("Error getting temperature");
} else {
Serial.print("C: ");
Serial.print(tempC);
Serial.print(" F: ");
Serial.print(DallasTemperature::toFahrenheit(tempC));
}
}
float tempC = sensors.getTempC(DeviceAddress);// I get the error here. I added this from the suggestions, but is
//tempC already defined above, or is that only valid for the 'void printTemperature' bit?
float tempReading = DallasTemperature::toFahrenheit(tempC); //I added the 'float' as well. Am I right in thinking that tempReading needs to be recognized as a variable?
void loop(void)
{
if (tempReading > tempSetpoint) {//I added this IF statement from your suggestion
digitalWrite (heaterPin, LOW);
digitalWrite (coolerPin, HIGH);
}
else if (tempReading < tempSetpoint) {
digitalWrite (heaterPin, HIGH);
digitalWrite (coolerPin, LOW);
}
delay(2000);
Serial.print("Getting temperatures...\n\r");
sensors.requestTemperatures();
Serial.print("Inside temperature is: ");
printTemperature(insideThermometer);
Serial.print("\n\r\n\r");
}float tempC = sensors.getTempC(DeviceAddress);
should be
float tempC = sensor.getTempC(insideThermometer);
also, these lines:
need to be inside the loop function (shift them down to be immediately below "void loop(void) {".
Does that help?
should be
float tempC = sensor.getTempC(insideThermometer);
also, these lines:
PHP:
float tempC = sensor.getTempC(insideThermometer);
float tempReading = DallasTemperature::toFahrenheit(tempC);Does that help?
OP
OP
Eighty2Fifty1
Well-Known Member
It works! So excited, now I just have to fine tune it. So I'm guessing if I use Bob's suggestions, I'll use 4 IF statements. 2 for heating and 2 for cooling? That should prevent the overcycling I would think.
Great!
The two major approaches to prevent short cycling would be to either use some kind of a dead band (which is what Bob suggested) or a timer.
I'm not sure exactly what you're envisioning with 4 if statements, but if you post something here I'll be happy to look at it.
OP
OP
Eighty2Fifty1
Well-Known Member
I think I'll do a dead band. I'm gonna try an ice chamber with computer fan for cooling and two 100 watt bulbs for heating. I still have to do testing to see how well it can actually cool it, but the control seems to be coming along.
So we'll assume my nominal temp is 68 deg F. The way the weather is right now, I'll probably be cooling more than heating. I'll have the fan turn on at 69 and turn off at 67. I think I'll also try to use multiple sensors, maybe average them together
So we'll assume my nominal temp is 68 deg F. The way the weather is right now, I'll probably be cooling more than heating. I'll have the fan turn on at 69 and turn off at 67. I think I'll also try to use multiple sensors, maybe average them together
Hey, I'm late to the conversation and without reading all of the posts, have you guys seen this:
http://www.elcojacobs.com/uberfridge/
From the first post, this looks like exactly what you are trying to do and what I'm trying to get done in my spare time
It has been mentioned on here before, but I can't find the link just yet.
I've only got a Arduino single-stage temp controller using a powertail from SparkFun for my mini-fridge lagering chest, but I just bought another fridge last night so I can have two going at one time. I need to quickly build up the other controller so I can be ready for the dual Oktoberfest brew this weekend. Ultimately, I want to have one master controller with the submersed temp probes and predictive control like the UberFridge.
http://www.elcojacobs.com/uberfridge/
From the first post, this looks like exactly what you are trying to do and what I'm trying to get done in my spare time
It has been mentioned on here before, but I can't find the link just yet.
I've only got a Arduino single-stage temp controller using a powertail from SparkFun for my mini-fridge lagering chest, but I just bought another fridge last night so I can have two going at one time. I need to quickly build up the other controller so I can be ready for the dual Oktoberfest brew this weekend. Ultimately, I want to have one master controller with the submersed temp probes and predictive control like the UberFridge.
OP
OP
Eighty2Fifty1
Well-Known Member
hausofstrauss said:Hey, I'm late to the conversation and without reading all of the posts, have you guys seen this:
http://www.elcojacobs.com/uberfridge/
From the first post, this looks like exactly what you are trying to do and what I'm trying to get done in my spare time
It has been mentioned on here before, but I can't find the link just yet.
I've only got a Arduino single-stage temp controller using a powertail from SparkFun for my mini-fridge lagering chest, but I just bought another fridge last night so I can have two going at one time. I need to quickly build up the other controller so I can be ready for the dual Oktoberfest brew this weekend. Ultimately, I want to have one master controller with the submersed temp probes and predictive control like the UberFridge.
Very cool. I'd like mine to do that eventually, maybe with a webcam so I can watch my beer ferment. My conical has a port that would be perfect for a thermowell, so I'll be able to monitor the actual liquid temp too. I'll have to decide whether I use the air temp or liquid temp for the actual setpoint
carlisle_bob
Well-Known Member
Hi
If you decide to control to liquid temp, be very careful of how you do it. The lag / phase margin / damping factor (how every you want to describe it) is going to be a problem with a tight control spec. Since the liquid does not change temperature very fast, a multi loop control likely is your best approach. That's getting a bit down the road from a basic control loop.
Not at all saying it's a bad idea, just that it's a bit harder than it looks.
Bob
OP
OP
Eighty2Fifty1
Well-Known Member
Yeah, plus I'll have multiple fermenters in the chamber. I definitely want to track the liquid temp, but I think I'll use the air temp to set it. Maybe an average of 5 sensors in different areas of the chamber.
Tracking the liquid temp will only let you see exactly why your beer tastes like ass because it rose 10+F over your air temp during the active phase. Using air as an input would only be effective as a supplemental input in a multi-input loop, which would be too much work to create/tune anyway.
Using the liquid temp as the input the to control loop is much easier. Just set your ferm temp and a differential (~.5 - 1F) that keeps compressor cycling within reason. For a fan and reservoir based system, you can set it even tighter. For a compressor based system, having a timer that prevents hot starts for at least 10 min is mandatory. Additional mass helps (prechilled to ferm temp before ferm start), as does a small fan. Surprisingly, placing the probe on the vessel wall underneath some (or a lot) of insulation provides better control than a thermowell when using air in a chamber.
You will not be able to effectively use a single chamber for multiple simultaneous fermentations without using heat wraps for each fermenter and a much colder than setpoint chamber temp. It is much easier to use multiple chest freezers or fridges.
Using liquid temp presents no problems as long as you don't want to control to an exact temp with no variation whatsoever, which is nearly impossible anyway, especially with an active fermentation over the complete ferment.
The slow response of the liquid allows for very small temp differential settings. It would only be a problem if your heat input (neg or pos) is not much larger than the ferming beer's needs. Most fridges/freezers have more than enough power to control a ferment- by a factor of 10 (~40W-400W). The main issue is compressor cycling and hot start protection (ASD).
Additional thermal mass at ferm temp provides even better control. There is the possibility of the thermal mass causing undershoot (too cold) for later phases if it got too cold during the active phase, but it is rare in my experience. If it really bothered you, it is easily solved with a dual stage controller to kick on a heater for the end of ferment. Usually unnecessary, though.
If you read a lot about the UberFridge, what he did was have temperature measurement of the liquid and the air. He then wrote some logic into the PLC that did predictive control. Essentially working out the thermal response of each batch. He's got all sorts of graphs showing the validation of his design. It was a really well laid out project and I'm grateful for him sharing it all.
Is overswing a big problem for people? My fridge must have really low thermal mass, or something. I just stick a probe on the side with a bit of insulation and do a .5 degree deadband. An elaborate formula has just never been necessary for me.
OP
OP
Eighty2Fifty1
Well-Known Member
So to add a dead band, I was going to add this statement for the meat of my program. Can I link IF statement like that or is there something else I should use?
PHP:
if (tempReading > 69) {
digitalWrite (heaterPin, LOW);
digitalWrite (coolerPin, HIGH);
}
else if (67.5 < tempReading < 68.5) {
digitalWrite (heaterPin, LOW);
digitalWrite (coolerPin, LOW);
}
else if (tempReading < 67) {
digitalWrite (heaterPin, HIGH);
digitalWrite (coolerPin, LOW);carlisle_bob
Well-Known Member
Hi
Since most people are controlling something other than a fermenter, it's not a very good example of what they are trying to do.
It is actually quite easy to do reasonably tight control (0.1F) of a normal keg sitting in a keggerator. There is a very large body of theory that lets you set it up. It can be done without unduly cycling compressors *or* wearing them out by running too long on each cycle.
Bob
That will prevent short cycling, though your system will bounce between 68.5 and 69 or 67 and 67.5. In other words, it will never actually sit at 68.
A different approach would keep you between 67.5 and 68.5:
PHP:
const float setpoint = 68.0;
const float deadband = 0.5;
void loop() {
if (tempReading > setpoint) {
digitalWrite(heaterPin, LOW);
}
else if (tempReading < setpoint) {
digitalWrite(coolerPin, LOW);
}
if (tempReading > (setpoint + deadband)) {
digitalWrite(coolerPin, HIGH);
}
else if (tempReading < (setpoint - deadband)) {
digitalWrite(heaterPin, HIGH);
}
}As Bob mentioned, you might in theory need to watch out for overswing with something like this, but I've never had any trouble. 5 gallons of beer has a lot of thermal mass.
OP
OP
Eighty2Fifty1
Well-Known Member
Okay, I set up your code into the original and it works fine. I take it that later I could set up a way to change the setpoint and deadband variables with buttons or something, so I don't have to rewrite the code every time. Now I need figure out how to set up a multiple sensor network, and a way to log everything.
Yep, though you probably won't need to change the deadband much. Basically, you want as tight a tolerance as your system can handle, and that's not going to change too much from batch to batch.
Multiple sensors with 1-wire is quite easy. You just need to wire them up in series and then poll the right addresses.
carlisle_bob
Well-Known Member
Hi
As you network them up, be sure to include some "what if the network is down" protection in the code. It's easy to put that off as a do it later task. Usually later turns into never or it's a major re-write when you do get around to it. Much better to include at lest some basic checks and protection right from the start.
Bob
OP
OP
Eighty2Fifty1
Well-Known Member
carlisle_bob said:
Like if something gets disconnected or a sensor fails? I think the code that I started with had something that would send an error message to the serial port if the sensor returned -127 deg C or something like that. I take it to mean that a failed sensor will return that value? So I'm guessing that the way the code sits now, I'd get the error message, but it would keep the heat on. Sounds like a potential fire hazard. Maybe I could hardwire a thermal fuse in there to cut power if a temp gets above a set value, say 80 deg F. Is that what you mean or is there something else?
Overshoot isn't a problem for most things like a keezer or a ferm chamber made from a fridge/freezer. Like you say, the 'thermal interia' (for lack of a better term), of the freon continuing to cool after shutoff is very small compared to the mass of a typical batch. In fact, when the probe is taped to the side of the vessel under some insulation, there is some predictive input from the air temp which causes an early shutoff prior to the vessel temp reaching the setpoint. Same goes for activation, but causes early turn on. That is why 'probe taped to the side of the vessel' has been crowned king.
Because these guys seem to be interested in sub 0.00001F temperature control, I had mentioned adding a lot of thermal mass pre-chillled to ferm temp. There is a chance that during the active phase the passive mass's temp could be lowered enough to cause overshoot when the ferm slows down. Not an issue for most people.
Same as you, the physical improvements available- mass, fans, probe placement, etc.- to me, seem much simpler and effective than trying to dial in some control equation.
I read his stuff about a year ago, but haven't checked what his latest incarnation looks like. He seemed single mindedly focused on trying to do everything with the control equation/logic. He also had to hand tune every batch- not exactly a generalized control system. Adding simple physical improvements like I mentioned earlier could improve his system even further. Also, like I mentioned previously, taping to the side of the vessel under some insulation mimics what his control system does- predictive input. The only difference is you can do it with a $25 ebay temp controller and some foam, and just need to change the insulating factor to vary the predictive input.
I used the fermenter example because it is the more general/difficult case, and also because fermenting was specifically mentioned in the post immediately preceeding my post, as well as being the subject of the last few pages..
If you are (again) talking about controlling by placing the probe on freezer's wall as a secondary indicator for the controller input, please include your complete process, not just stating that 'a large body of theory' says it is possible.
Most people do not want to go to the lengths required to tune that type of system, especially when the temp variation can be limited to 1F quite easily by just placing the probe on/in the keg, or a facsimile, and setting the temp on the controller. No complicated hunting for a temp offset, or the proper differential- just set them directly on the controller.
Here is a link to my psuedo-code of your 'probe on coil/wall' approach and the 'probe on vessel' method.
https://www.homebrewtalk.com/f35/keezer-temp-probe-341764/#post4266918
Please feel free to add detail or submit your own version of the 'probe on coil' process, since the only information you have provided is regarding the method is - place the probe about halfway to somewhere, talk about theories, add magic, then... perfect temp control.
I am a big fan of overkill. There is a difference, though, between state of the art, and making the best out of what you have.
Multi-input loops using fixed speed compressors became old school once variable speed compressors using either DC or VFDs became economical enough. Last I checked, the uber fridge guy still had to model every different batch and hand tune his loop. External ambient changes introduced even more tuning.
carlisle_bob
Well-Known Member
Hi
Sensor failure is something that's also worth thinking about.
With a network, the issues are usually with data buffering. If it goes into the buffer, but doesn't go out... there's only so much ram. The same sort of thing thing applies on the input side, gizmo looks for command input, waits , repeats. No network = a lot of repeats and waits. There are only so many CPU cycles.
Bob
OP
OP
Eighty2Fifty1
Well-Known Member
carlisle_bob said:
So I'd want something that would take a faulty sensor out of the equation? Like if it returns an obviously wrong value, it stops using that sensor to cycle the heater and cooler?
What to do when a sensor goes out depends heavily on what the sensor was reading.
You mentioned previously using multiple sensors at various locations, averaging them, then using that value to determine the set point to keep your ferment vessel at the correct temp? Is that still your plan?
You also mentioned the desire to control multiple active batches within one chamber space. Is that still the goal?
OP
OP
Eighty2Fifty1
Well-Known Member
My current plans involve 5 sensors in the chamber to run the controls, plus a sensor in my ice chamber and one on the outside of the entire chamber for data logging. I don't have the parts I need for a thermowell, and I'll be filling my conical tomorrow, so that'll have to wait for a few weeks until the IPA is done dry hopping
