jonr Senior Member Joined: 25 Jun 2013 Posts: 329 Location: Americas Expertise: I love coffee
Posted Sat Jul 20, 2013, 9:54pm Subject: Re: Next Mod: PID my Gaggia Classic
Good stuff, thanks. Would you be willing to recap the heating algorithm just before and during brewing? I believe you are adding some extra heat before brew starts but I didn't follow the rest. I'm also looking for a % power vs time graph.
My guess is that there should be 100% power applied to the heater for x seconds before the brew and then this should drop down (to avoid overshoot) and then rise to around 70% at the end of 25 seconds. I wouldn't want to guess at the exact shape of the curve.
I think that a fixed power vs time curve output will give good results without having to use an "in the boiler" temperature probe and then always being behind with all the delays.
Posted Mon Jul 22, 2013, 2:51am Subject: Re: Next Mod: PID my Gaggia Classic
Hey Jon, You almost understand my process for my situation-aware PID heating system. I'll recap the process and then explain why.
First, let it be known that although my base system is not uncommon, a Gaggia Classic, which probably millions of people have, but each DIY/hacker will have a different perspective as well as budget in how they want to implement their preferred method of thermal control.
In my case, I have a stock boiler/heating element (for now), but I have in internal probe, plus larger piping for my steam system (just what I could muster up from parts I have, some McMaster parts and some Home Depot parts) which all affect the variables in my algorithm.
I have a versatile PID library running in my system which keeps the water level fairly stable when nothing is happening, i.e. pulling shots, so we assume the starting temperature is at 200F (my default).
When the 'timed-brew" button is pressed, no matter where the heaters are at, the auto-tune is turned off, then the heaters are turned on 100% for 10 seconds (also my default).
After the 10-second pre-heat sequence has completed, the heater is then turned off (0%), but the system is still monitoring the temperature and the auto-tune kicks in if it sees a dramatic drop in temperature. otherwise, the 10-second pre-heat is usually enough to sustain a 24-second shot (also my default).
After the 24-second shot sequence is completed, the pump is stopped and the 3-way relieves PF pressure.
My description above under (1.) assumes the temperature to be stable at 200F. No matter how good your hardware or algorithm is, the temperature curve will never be flat. The graph will always resemble a sine wave to some degree, or for the most part, always up and down, crossing zero (or 200F, or whatever your target temperature is). Because of this, an intelligent or auto-tuning process is best and a set percentage of power would change things, even as simple as a different time of year. I have already tried a set power % and it simply doesn't work. You may find a % that SEEMS to work, but after, maybe 30 minutes or so, you'll see either the temp starts climbing or drops. I had a very good algorithm that ramped the temp, decreasing % as I got close to 200F, then trickled power every 5-50ms or so. This kept the temp stable for about 3 days, then it started to drift. So there isn't any set % or power I could recommend. Stick with a PID process.
My system is very different than many others, since my temperature sensor is in the water. My numbers are as close to actual temperature, without any guessing or offsetting. Temperature readings are real-time, with major sources of error being calibration value (which I calibrate before installation), heat transfer-time from water to sensor (sensor body, ceramic/alumina compounds and absolute response-time of the thermocouple element, of all are very small), as well as how busy the Arduino is between samples. I use preemptive multitasking in my system so each object functions independently, and temperature as well as current-situation status is always available without each object having to "go find out" (less programming). The heat driver is not a matter of percentage of power. I only use that to help you follow along, since you mentioned %. I use the PWM functionality of the Arduino so the correct representation is duty-cycle, instead of % of power. 100% power is always sent to the heating elements. Let it be known that using PWM with AC power is also not ideal, nor does it provide true-100% power. Actual power is based on the timing of the AC cycle and when the SSR is switched on, plus a whole lot of calculus which is probably WAY more technical and mathematical than anyone would want to get into... especially for espresso. Anyone who disagrees with that last statement... I stand corrected. So for all practical purposes, power is always 100% at a duty cycle determined by the PWM value calculated by the PID. The 10 seconds I have set are based on trial and error. The stock Gaggia Classic worked, based on a ~2-3 second "heat-on" at low-temp, which was enough to bring the water (realistically, boiler temp) to upper-temp. I had a datalogger on it know qualify this. So the 10 second pre-heat time pumps enough energy into the boiler to prevent the water temp from falling below ~195F during a pull. A technical caveat of this is also related to (1.) which is the brew button should be pressed on the falling-temp towards 200F, not the rising edge towards 200F. On the falling-edge, the PWM is 0% duty. On the rising-edge, PWM could be anything but most likely a positive number and some heat is already being pumped and the likelihood of overshooting towards of the end of the pull is very likely. So I always wait for the falling-edge before I start my pull.
You mentioned to me a while back that based on your calculations, 80% power (I'm sure this is 80% total joules, and not 80% voltage, current, or duty cycle) is ideal to keep the temp stable at ~200F (?) with the flow-rate you mentioned, starting at 70F. I don't remember the actual figures. I haven't had a change to try this out but it would take some time to rewrite some of the code. I'll give it a go at some point. 24 seconds seems ideal for my situation. I had it set to 28 seconds at one point to accommodate the filling of my steam plumbing, which has huge volume in comparison to the stock system, so I accounted for plumbing-fill. I reverted to 24 seconds, since it seemed to only mattered when I pulled shots, purged and steamed milk, and back for another shot. If I went back-to-back shots, the extra 3-4 seconds was unnecessary.
Stopping the pump and relieving pressure is all standard stuff and I don't think we need explanation on that.
Regarding the graph, I don't have a graph, but I have replaced the stock thermostat with a thermocouple, so I have internal as well as external temps. I watch both of these numbers all the time. For the most part, these two values are not offset of each other. They can be described more like the head and tail of a dragon. One goes up, the other follows... with a delay. I don't know if anyone has seen this yet, but although the heating element is on the outside of the boiler, I've seen internal temps higher than external temps, mostly when the pump is pushing cool water into the boiler. The cool water is cold enough to affect boiler temps while upper water temps are still hot. There is usually a varying difference in internal and external temps and they do cross and swap, so taking temps and offsetting seems very unreliable.
Anyway, everyone's setup is different as well as their preferred method of thermal control. What I've written is based on my method and hardware. I hope this helped clarify some questions. Please let me know otherwise.
Posted Thu Oct 31, 2013, 3:23am Subject: Re: Next Mod: PID my Gaggia Classic
Alright, I've been working with more advanced microcontrollers the last month or so. I've hit the performance ceiling with the Arduinos, namely the Atmel ATmega328 chip. This chip runs at 16MHz, or if you implement the raw MCU, there are 20MHz versions. However, there are still the limitation of few GPIO available. For example, my PIDuino v1.5 uses an Arduino Nano with some... 18 GPIO pins, but I still ran out and had to sacrifice the third TC amplifier, some button LED, RTC select, and a few other features. If you guys have seen the videos of my GC sporting the PIDuino, it may seem fully featured, but to me, it's terribly lacking. The Arduino Mini would have been more appropriate with maybe 5-10 more GPIO available.
So, I've been thinking about designing and building a new PIDuino, v2.0, with either an Atmel Cortex-M3 or M4, which would make is software compatible with the Arduinos - mostly, or a STM ST32F which would make it more compatible with Maple Leaf, still somewhat compatible with Arduino with some modifications.
Features of the PIDuino v1.5: - Arduino Nano (ATmega328 8-bit AVR running 16MHz) - Dual TC amplifier, plus a ghosted-third - 20x4 I2C LCD display - RTC (Real-time clock, not connected) - SD Reader (not connected) - 2x SSR driver ports - 5-button switch board
New feature ideas of the PIDuino v2.0: - Possible Atmel Cortex-M3 (32-bit ARM at 85MHz), Cortex-M4 (32-bit ARM at 100MHz), or STM Cortex-M3 (32-bit ARM at 75MHz) - External EEPROM, since none of the Cortex MCU have it, which is needed for the menu system and configuration - External Flash, possibly for easy firmware upgrades as well as graphics data - External bootloader sub-processor for easier programing of the main MCU, more on this later - 3 total TC amplifiers - 320x240 graphics display - Touchscreen, to eliminate physical buttons - WiFi for simple things like firmware updates and/or Internet time-keeping, most likely connected to the sub-processor and not the actual PID MCU (no need) - Mostly built onto a custom PCB, since it was quite expensive in both money and real-estate building by breakout-modules
Current Status: I have a Maple Leaf Mini clone on my desk at work with an I2C LCD display connected. I was able to port the Arduino libraries and got it working today. The Maple is currently reading a digital scale, destined for a CNC lathe retro kit. I will hopefully get the SPI communications figured out sometime this week or next week to interface the TC amplifiers, RTC, and SD reader.
I have a 2.5" 320x240 LCD with touchscreen, but I purchased it before the 3.5" SPI version was available. This is 16-bit parallel and will be crazy to hook up as well as requiring a ton of GPIO. But at least it's something to experiment on, until I get a 3.5" SPI version.
Anyway, I was wondering if anyone would be interested in a PIDuino v2.0 of their own? The only reason why I ask is the PC boards won't be cheap and I'd have to make a minimum of abut 5-10 boards to get them out of the SUPER-OUTRAGEOUS price range. And what would I do with 5-10 PIDuino boards? I only have one espresso machine. Just to put it into perspective, I just sent out a custom Cortex-M3 (compatible with Cortex-M4) to DIP breakout board for prototyping. These costed me roughly $40 each (5 total) plus tooling and shipping.
This is not a group-buy or anything, just to get an idea of how many people would be interested and how much this project will actually cost. It'll cost me the most because I'll be engineering it and buying components for R&D. Worst case, the PIDuino v2.0 will cost me about $500 for one unit, not including engineering time. :( If anyone is interested, please don't ask how much it will cost you, since I don't have that information at this point. The project is still conceptual with bits in prototyping. Just a simple, "I'm interested" would suffice at the time being. If no one is interested, that's cool too. I'll probably have to resort to building it in-house.
I'm sure some of you are thinking, "scale back". Well, it's the PCB that I have to outsource so the PCB will probably be the most expensive part, so there's really not much to scale back on.
Posted Thu Oct 31, 2013, 3:45am Subject: Re: Next Mod: PID my Gaggia Classic
Here is a standard breakout board with a 144-pin LQFP Atmel Cortex-M3. It is much bigger but the core is the same. It just has a ton more GPIO. The Cortex version I would probably use is somewhere in between. There is a 64 or 68-pin and 100-pin versions available. I'll most likely be using the 64/68-pin version.
In case anyone is wondering, yes, I did solder the chip on the board myself. I checked under a microscope and every pin is 100%. ;) If you look closely, there are some solder bridges, but those have been taken care of.
jonr Senior Member Joined: 25 Jun 2013 Posts: 329 Location: Americas Expertise: I love coffee
Posted Thu Oct 31, 2013, 7:11am Subject: Re: Next Mod: PID my Gaggia Classic
Nice work. I agree that ARM is the way to go. What are your thoughts regarding thermocouples vs RTDs? While I have a SPI touch screen, I haven't done anything with it yet. Wifi or Bluetooth would be nice too, although primarily for data logging to a PC (I currently use USB, which means laptop in the kitchen).
Posted Thu Oct 31, 2013, 11:10am Subject: Re: Next Mod: PID my Gaggia Classic
I think we had a short discussion about TC vs RTD a while back.
But to be honest, I don't know too much about RTD's, but from what I understand about them, they do take a bit more support electronics to implement, but your results will be "similar" and I use the term loosely. This is because, like everything else in this world, there is no perfect solution. Each one has its advantages and disadvantages.
I think more people, here maybe, have a decision to make, go with a TC or a RTD for their off-the-shelf PID controllers, since the "brick PID controllers" support both. Then, the average consumer may ask, which is cheaper, if the PID supports both? I think at $3 or so, you can get a low-end TC from China that is "good enough". Just hurry up and wait for it. Or you could get a RTD with US stock for $20+S/H.
I'm sure you already know this, but for anyone reading who doesn't know the difference between TC and RTD, here's a quick compare and contrast. It's all I know about them, and I'm sure there is a lot more to it, but I can only speak on what I know.
A TC is basically two wire of different materials, welded at a single point. They must be isolated from touching each other, otherwise there will be an electrical "reaction" at that point. So a high quality TC will be isolated, probably with resin, all the way to the weld point, then individually sleeved, back to the connector ends. The cheap Chinese variety usually consists of two bare wires, of different materials, sleeved, then twisted at the ends before the weld point. This causes some fluctuation in the electrical voltage that is generated. This voltage is VERY small, and I can't emphasize VERY enough, but it still can be measured, in the uV (micro volts). This uV is what the PID will read. More accurately, the TC amplifier will read, then passed onto the PID.
A RTD is somewhat similar in that it's junction generates a resistance. Again, it is a resistance so small that you wouldn't be able to measure it with your common household DMM. I did try to measure it with my DMM and it read as a wire, so for all practical purposes, it's a wire. However, again, the value can still be measured in the uOhm range. Our DMMs normally have a "200" ohm range with a 0.1 ohm accuracy. Not anywhere near accurate enough to measure a RTD. Now, I have not "cooked" an RTD to see how much the resistance varies, but at room temperature, it basically reads "0" ohms.
An Arduino or any other device that has a A/D (Analog-to-Digital) converter, the ADC is normally 10-bits, which equates to 1024 steps. Arduinos, like any other 5V device uses a 5V reference. If you divide 5V (more like 4.85V or so) by 1024, each step is equal to ~0.005V. One uV is equivalent to 0.000001V. So, it is impossible to connect a TC directly to an average ADC and get anything useful.
On the other hand, a RTD is essentially a resistor, a VERY small resistor. The first thought that comes to mind is connect it between 5V and the ADC input. Well, the resistance is so small that the ADC will read a constant 5V because the RTD is basically a wire and the changes in resistance is so small, the ADC wouldn't even pick up the changes. Then you can work up a voltage divider to bring your resistor network into range. The problem is now finding a resistor that is close to the same resistance of the RTD. The last time I checked, the smallest resistor available is 500uOhm, which... is getting close, but still doesn't get you very far, as far as an average ADC. At 500uOhm, you would loose a lot of precision because it isn't close enough to the RTD (I would suspect). You would also have to measure the RTD at operating temperature, not room temperature, and I haven't done that level of testing yet.
So, with either solution, you would need an amplifier to make either one of these work, or get any kind of useful information. I have looked high and low and found Maxim makes the best amplifiers for these. (Note, I don't work for Maxim or advocate for them. I own and run my own design/engineering/manufacturing company). Maxim has the MAX31855 cold junction thermocouple amplifier, which I enjoy a lot. They also have the MAX31865 RTD-to-digital converter. I have no experience with the MAX31865, but I know of it while doing my search for a thermal dynamics solution for my PIDuino.
Again, I can't speak for the MAX31865, but the MAX31855 is also not a perfect solution. The data can be extracted directly from the chip in a decoded form. Once the value is extracted, I've found that the maximum precision is roughly 0.025F, 0.25F or something, I forget. It's been a while. I wouldn't expect the MAX31865 to be any different.
What it boils down, for me, and everyone's situation will vary, is ease of implementation. Either way, you'll need an amplifier to sit between your sensor and the controller. Given the Maxim amplifiers are my choice devices, the TC amplifier is a much more straight forward implementation. At the very minimum, you need the MAX31855 and a thermocouple. That's it. Of course, it's a little more complicated than that, but that's all you need to get it to work. You would need some capacitors to filter noise, but that's with any type of electronics. If you look at the MAX31865 datasheet, at a minimum, you need a few more components to support the RTD. I haven't looked at it in a while, but you need a resistor/capacitor network to generate a reference, then another resistor to form a voltage divider, etc. Too much complication for me when the end result you're looking for is a digital representation of a temperature.
That was probably more than you were asking, but those are my thoughts on TC vs RTD.
Posted Thu Oct 31, 2013, 11:41am Subject: Re: Next Mod: PID my Gaggia Classic
While I have a SPI touch screen, I haven't done anything with it yet. Wifi or Bluetooth would be nice too, although primarily for data logging to a PC (I currently use USB, which means laptop in the kitchen).
SPI is the way to go. I don't know why no one has designed a SPI 16x2 or 20x4 LCD display. I guess no one thinks that's much data to be sent over an I2C bus. The fact is this, I2C is VERY easy to use and requires only 2 wires for up to 127 devices, where SPI also uses 2 wires for communication, but needs an additional wire for CS (chip select, or maybe device select is more meaningful these days) for each device. However, although it really isn't that much data, I2C is a very slow protocol, running up to a maximum of 400KHz. That is "UP TO", not practically. I have a logic analyzer that I hook up when I'm doing troubleshooting or monitoring and the I2C data line is just congested! On the other hand, SPI can work UP TO 18MHz! That's faster than the maximum speed of the Arduino! So SPI would be the choice of displays with the PIDuino v2.0, this is of course to free up the MCU for actual PID functions.
As far as a wireless feature, wireless data logging is nice to have. Not that it is out of reach or not practical, the problem I have with wireless datalogging is a consistent quality data stream. This of course affects precision. What this means is data traveling through the air is not as reliable as data traveling through a wire. With any high quality wireless solutions, there are CRC, or data/error checking. This creates more back and forth data, eating up bandwidth. Wireless speeds are so fast now, it may not be an issue, however, if the radio is not very powerful or there is no "direct line of sight", this also degrades the wireless signal. If you're looking for extreme precision, with all the data checking or dropped packets, you'll loose samples. An option is to broadcast with no error checking, but then your data will be iffy already.
This is why I would rather do datalogging on a SD than over USB, serial, or wireless. Either way, you will end up with a laptop in the kitchen. I couldn't see datalogging a shot from upstairs, then running down to prep the next shot. LOL
My thoughts on wireless feature on the v2.0 is to do wireless firmware updates and allow the RTC to keep time-sync with Internet time servers.
However, I'll think about wireless datalogging as a feature. Once a wireless module is implemented, the PIDuino will be capable of wireless datalogging, even if the feature is not implemented. It's all in the software anyway. Also, with the 320x240 graphical display, I could do on-the-fly temp graphing to visually see what is happening with the temps in real-time.
My thought is, I'd probably opt for WiFi over Bluetooth anyway. Wifi is a lot more versatile than Bluetooth. You would have to pair the espresso machine to, say your laptop or your smartphone and you'd be the only one who could get data from it. It would not be able to get firmware updates or Internet time over it's BT connection, which is really the "original" point. How about WiFi AND BT? Well, that's more electronics and brings the cost up.
Symbols: = New Posts since your last visit = No New Posts since last visit = Newest post
Forum Rules: No profanity, illegal acts or personal attacks will be tolerated in these discussion boards. No commercial posting of any nature will be tolerated; only private sales by private individuals, in the "Buy and Sell" forum. No SEO style postings will be tolerated. SEO related posts will result in immediate ban from CoffeeGeek. No cross posting allowed - do not post your topic to more than one forum, nor repost a topic to the same forum. Who Can Read The Forum? Anyone can read posts in these discussion boards. Who Can Post New Topics? Any registered CoffeeGeek member can post new topics. Who Can Post Replies? Any registered CoffeeGeek member can post replies. Can Photos be posted? Anyone can post photos in their new topics or replies. Who can change or delete posts? Any CoffeeGeek member can edit their own posts. Only moderators can delete posts. Probationary Period: If you are a new signup for CoffeeGeek, you cannot promote, endorse, criticise or otherwise post an unsolicited endorsement for any company, product or service in your first five postings.