PID response-
I have used PID controllers on three different machines so far and I really prefer them to the pressurestat.
Most machines have led lights to show when the boiler is on and off. I also insulate my boilers, to lower the frequency of the heat needed. Looking at the light during an idle cruise period, the description would be less than 10% of on, and then almost 3 seconds of off. In other words, a quick blip of the element, then a period of rest.
At start up, the light and element remain on up until the boiler reaches close to the set point. Its a matter of parameters that are adjustable, as to whether the PID overshoots the set point, and how accurately and quickly it can get to the steady state and hold it there. One has to balance the advantage of quick heating times, versus overshoot, and then balance again the advantage of quick recovery after a shot, or steaming session, and the accuracy of the return to the set point.
Autotuning functions help, but in the end, a custom setting can help do what you want it to do.

I've seen three years of use without a hint of issue from all three different PID setups. They are nearly silent in action.

sprint jinx wrote:I have used PID controllers on three different machines so far and I really prefer them to the pressurestat.

Thanks Sprint for the excellent clarification. I would concur entirely with everything that you say and I would add a couple of comments. Firstly, in terms of efficiency, wrapping the boiler is _the_ way to go. The SSR's power consumption is likely negligible in comparison with the energy been consumed to keep the boiler hot. Slowing the heat loss with insulation will result in significant gains. However, there may be an upside to having a lower boiler temperature more quickly. When a shot is pulled, the group temperature climbs rapidly. The more shots are pulled, the hotter the group gets. As a result, brew water at a significantly lower temperature is required to compensate. Perhaps someone has some data on this.

Secondly, as far as setpoint overshoot is concerned, the big problem is getting there from a cold start or from a significantly lower temperature as a result of steaming or pulling successive shots. Both of these situations can be compensated for by adding logic to the control algorithm. I came across code for the Bare Bones Coffee Controller which places a limit on the Integral factor to deal with cold starts. Intelligent behaviour for the other situations likely requires data about the brew water temperature (minimally) and (ideally) also the group temperature. Though it may be possible that these situations could be "detected" by characterisation of the boiler behaviour during use.

I, too, have used PIDs on several machines and concur with the other comments.

I'll add one additional item. There are PID controllers that have additional capabilities to handle startup differently than steady state. The most common feature is "ramp-soak" which lets the user control several different control algorithms for different phases of operation. There is typically a "ramp" that handles heat-up to near steady state then the "soak" which is controlled by standard PID control. There may be several different phases and they can be configured to be triggered by time, a sensor set point, other inputs, etc.

The reason these aren't talked about much on coffee boards is that they cost more and are typically larger than the small, inexpensive PID units people use for espresso machines. I used a ramp-soak PID for one machine but I have found that the heat-up and overshoot isn't a problem because I keep my machines on a timer and it has settled down to steady state by the time I start pulling shots.

Hi,

Superb realization, BRAVO !

Thank you Dynamos!

pizzaman383 wrote: There is typically a "ramp" that handles heat-up to near steady state then the "soak" which is controlled by standard PID control.

Thanks for the input Curtis. Indeed, the code that I am starting with is from a reflow oven and the "ramp" and "soak" phases were implemented (along with a number of others). The state machine diagram that I put up a few days ago has a state called "warmup" which is the equivalent of "ramp". This state uses the same PID algorithm (possibly with slightly different settings), but aims for a lower set point and has a minimum time that must elapse before it will move on to the "ready" state. The implementation of PID on an Arduino is well documented and fairly straightforward. It is actually the "dealing with humans" part that is complicated: creating user-modifiable inputs and an interface to allow such inputs to be viewed and edited...

The temperature and auto-fill controller code is done. I put a little extra logic to allow for calibration of the thermocouple sensor. For now, the screen shows the current state at the top left, time elapsed, bottom left, two temperature readings (upper is current reading from thermocouple, lower is the set point) and three bits of data: A is the alarm state, H is the heating element and F is the solenoid. The reading in ice-water was a few degrees above what it should be.



A second data point is taken using boiling water.



Then, the corrected temperature can be calculated using the formula:

CorrectedValue = (((RawValue - RawLow) * ReferenceRange) / RawRange) + ReferenceLow

where ReferenceLow is 0.01 for ice water and ReferenceRange is the boiling point at your elevation minus the ReferenceLow.

Although there is a bit of swing in the readings, the corrected output for boiling point looks pretty good. I would say that this thermocouple setup is accurate to +/- 0.5C - which is certainly good enough for boiler control. Without better reference tools, I will just have to assume for now that the rest of the range (i.e. above 100 C) is similarly accurate.

I can't tell from the picture, but it's important in boiling water that the probe not touch the pot or the reading might be slightly high and unstable.

Ira

Quite right Ira! I should have mentioned that. The pot will be significantly hotter than the water.

Chert wrote: is the AF a separate gicar box? And is the PID a separate PWM controller?

All the functionality shown in the state diagram will be built into the programming of the microcontroller (an Arduino at least for now as it is so convenient). The extreme democratisation of microcontrollers just makes having discrete industrial controllers a non-starter. I could purchase Arduinos and just hand solder a rat's nest of components for less than the cost of a single Gicar, never mind the $300+ PID and $100 pressurestat. Once the electronic design is finished, a custom PCB will reduce the cost even further (if one neglects the not insignificant work that will go into it .

Someone requested an explanation of the autofill circuit. What is required is essentially a comparator - a circuit that checks to see if a voltage level is above or below a certain threshold. The essence of the circuit is a switch that is grounded by the water when it touches the probe.



The switch in the diagram is analogous to the probe touching the water or not (and assumes that the boiler is physically connected to the same ground as the microcontroller). When the switch is open, the analog pin on the Arduino "sees" the full 5 volts. When the switch is closed, the value "seen" by the pin drops to (close to) zero. In reality, as a result of the resistance of the water, the boiler, the probe etc., this value is not zero; thus the need for a comparator. But this is easy to implement on the microcontroller:

autoFillProbeValue = analogRead(autoFillProbePin);
if (autoFillProbeValue < 500) {
digitalWrite(autofillSolenoidPin, HIGH);
}
else {
digitalWrite(autofillSolenoidPin, LOW);
}

The Arduino is an 8-bit device and the logic level is 5v, so values between 0 and 5v are mapped by the analog to digital convertor to values between 0 and 1023 (2 to the 8th power values). So anything lower than 500 will open the solenoid. By putting in a timer which counts while the pin is high, it is possible to trigger an alarm when the tap has been on for too long. When that alarm is triggered, the state machine switches off the solenoid and the heater and waits for a reset signal before it will do anything else.

As the probe is sitting in water in close proximity to a heating element that is powered by a 15amp 120v circuit, I also added a diode rated for the voltage in the line to the probe. I will have to consult a higher power to see if there are any other safety precautions that should be taken.

Over the last six weeks I have been making some progress plugging away at the firmware for the controller. As anticipated, the code for the human interface is both more complicated and voluminous than the code required to control the actual machine itself. I've got proof of concepts done for both halves of the code (i.e. the menu system and the state machine) and now I'm working on putting them together.

I'm also waiting to get the first batch of sheet metal in. I went through about ten suppliers before I found one that had the required tooling, was willing to do the prototyping and make a small run. I should have some pictures in a few days. I finished up the package of cad drawings during a trip to Italy where I had some great (and some not so great) coffee. The best was, of all places, in terminal 3 at Rome Airport at a generic chain café. That is one of the things I love about Italy - the last time I was there the best coffee I had was in a gas station by the side of the highway - great coffee is normal. While I was in Rome, I made the trip to Caffè Sant Eustachio.



This place is great. They have a two-page(!) menu of bizarre coffee drinks any one of which would be enough to draw the crowds. Their signature is Il Gran Caffè (speciale). They make it behind a privacy screen to stop you seeing how they do it (nor will they tell you if you ask ). I believe the technique comes from Naples where they take the crema from the start of the pull and whip it up with sugar before putting it back on the rest of the espresso. The result is an inch of sweet, creamy crema mouse on top of a great espresso. That, along with a pastry from the counter opposite the bar and you are totally set for sugar for the day.

The star at the bar, however, is the "Shakerato" which is made in what has to be the most hilarious machine I've seen in a while:



Iced coffee and milk go in a cocktail shaker that sits in the stainless steel receiver. Then the machine shakes the crap out of it for two or three minutes. And it's orange. What can I say? I want one!