Kudos to Bryan!


 
Steve_M

Steve_M

TVWBB Guru
After spending way too many hours working on my own Arduino based PID controller, I have a much deeper appreciation for everything the HeaterMeter does.

I'm actually using the HM board right now for my prototype since it's already got a microcontroller and TC amp on it and with a raspberry pi attached to it, I can remotely flash the controller running on my bench in the basement, while I sit on my couch on the main floor!

Here's the HM v4.2 board controlling a solid state relay in an espresso machine I just finished refurbishing for a project. My original plan was to use another HM v4.2 board with only the minimal components connected to allow reading of the TC, and controlling the SSR, but the HM board has the I2C ports in use and the PCB is just a tad too large, so I'm going to end up using an Arduino Nano + Adafruit AD8495 board.

Df6jD9t.jpg


Code for the controller is here https://github.com/shmick/PID-Controller
 
The espresso machine made me curious.... why do you need the HM for this purpose, doesnt the temp control on the unit work?
 
Espresso is a finicky process, with the ideal brewing temp at 95C. High end machines come with a PID controlled boiler to keep the water temps stable. This machine, and many like it, use a cheap bimetallic thermostat that control the power to the boiler, which can fluctuate the water temps in the +/- 7C range. Replacing the cheap thermostat with an external thermometer and modulating the power to the boiler with a solid state relay, controlled by a PID loop, really makes a big difference.

You can buy these cheap PID controllers, but then you end up with an ugly looking box attached to the side of the machine.

I want to keep everything inside the machine and I also liked the idea of working on an arduino project that directly benefits me, so this is the route I took. The entire machine has been a project in itself as it's a machine from the late 90s and was not maintained well at all. I cleaned, repaired, replaced worn seals, painted, etc the whole thing and now it's running like a dream!

Here's a pic of the thermocouple threaded into the boiler, where the old thermostat would normally be. It's a K type thermocouple with m4 threads. Apparently a common 3D printer part!

7Bvw0Wi.jpg


Here's a graph of the PID data from this morning. Need to tweak the PID values a little. Actually, I'm only running in PI mode right now. The dip in temps about mid graph is when I pulled a shot of espresso. The hot water in the boiler was being replaced with room temp water from the reservoir.

XrKzYOJ.png
 
Last edited:
Thanks for the explanation, I asked because I have been using one of these espresso machines for about 20 years now...
432e7274fce0bc1db74d79ca7650e28f.jpg

It's been a very reliable unit, though I have bought a broken unit for parts and have repaired mine once (not bad for 20 years service!). Having repaired my unit I am pretty intimate with the design, very similar to what you are working with (I guess most are).

One of the things that has frustrated me over the years is how the unit goes to ready state and clicks off the heat, then when I am brewing it doesn't maintain temperature as consistently as I would like. Maybe the rig you are working on would improve performance of my machine.

Please post updates if possible, I may experiment with something like this myself. Thanks for the inspiration!

PS if you are looking for low profile HM the 4.2 is not the way to go. Get the 4.3 main board only kit, it's cheap and very small.... 4" X 1.85" without the display board or rPi. With a rPi Zero-w it is 4" X 2.65"
 
Last edited:
A PID controller on the boiler would help for sure, otherwise you have to "temp surf" which means watching for the ready state and timing the shot exactly.

This is what I'll be using. It's an arduino nano, adafruit ad8495 thermocouple amp ( same on that the HM uses ) and a logic level shifter to hookup a raspi to the serial pins. The logic level shifter may or may not remain. I also need to add a header to power the 5v regulator and a header for the OLED display

Still figuring out component placement. All of the A-W rows are connected underneath, like a breadboard would be, but with solderable pads.

824QdB4l.jpg
 
Last edited:
It's a little taller, but narrower compared to the v4.3 board.

The HM board also had the I2C pins in use and the adafruit TC amp has a precision reference voltage, whereas the HM reference is ground.

Sq2a67fl.jpg
 
Last edited:
Here's the PID chart from the espresso I made this morning.

The PID output is now based on 0-100% rather than a fraction of the total PWM window. The PWM window was set to 0.5 seconds and I was seeing some odd behaviour where the SSR cycle time didn't seem to change over a wide range of PID output. This is when I learned more about how these SSRs work. They can only change state during zero crossing of the AC sine wave. With 60Hz AC, there are 120 zero crosses per second, or 8.333 milliseconds between each zero cross. The PWM routine was previously trying to send pulses of less than 8.333 milliseconds, which wasn't working properly.

The PWM window is now set to 4167 milliseconds (a multiple of 8.333 ) and with a PID output of of 0-100%, each output percent should be 41.67 milliseconds, which is 5 zero crossings.

PID values are P = 6, I = 0.02, D = 0

In an effort to speed up the initial heating process, I bypass the PID routine, keeping the boiler fully powered until it reaches 90% of target temp and then the PID controller kicks in.

FQYRDm7.png
 
Last edited:
Got v1 of the board wired up today. The Arduino, 5v regular and TC amp board are connected via pin headers, so not fully soldered in.

Still need to attach connectors to drive the OLED display ( 4 pins ) as well as a pair of pins to trigger a higher setpoint for steam mode plus come up with a way to properly mount it all inside of the case.

After some tweaking, it seems like the ideal PWM window is about 3.5 seconds

mCiDWmDl.jpg
 
Last edited:
The OLED display came today. It's pretty tiny, but with a 128x32 pixel density, it's very readable, even at a distance.

rDFpi1kl.jpg
 
Got the OLED working with the system now.

PID Output % on the left, TC Temp on the right.

I'm using the Adafruit SSD1306 library and 2 fonts from the GNU FreeFont project. The added libraries are a major impact on the code size. I went from a 7.5KB flash to about 23.5KB being used and there's only 32KB of flash on these ATMEGA328's. This once again proves how optimized the HeaterMeter code is. There is WAY more functionality in the HM code and it all fits inside of 32KB.

bFfvK7Sl.jpg
 
Last edited:
Working on the more permanent board that will live inside the machine.

I had a blank HM v4.2.4 TC board and while I could have re-jigged some things around to make it work, I felt that the easiest thing to do was to transplant the TC from that board to the new board.

MLM9LNwl.jpg


Laying things out on the new board. Nothing is soldered in yet. Still waiting for some PCB screw terminal connectors to arrive.

XcLu55p.jpg
 
ha HA, this is fantastic! I go away for on business for a couple of weeks and I come back to the whole build log. The OLED display is a nice touch too, and yeah fonts are a real program space killer. The bignum font/renderer in HeaterMeter is at least a couple kB and to do that it breaks the numbers down into shapes. Have you had a chance to taste the espresso it makes yet?
 
I pushed it to prod (moved it to the kitchen) last Saturday and have been using it daily. The espresso is really great from it. Much better than from the Breville machine I was previously using.

I've found 2 other graphics libraries I may try out if flash space becomes too tight. The u8g2 library, which handles a whole range of screens, not just these SSD1306 OLED displays. Also the SSD1306Ascii library which, as you might be able to infer from the name, is an ascii only library, which is fine for this project as I'm not doing any animated graphics.
 
Haha pushed to prod. I hope your users were made aware of the possible downtime conditions surrounding the upgrade!

I love it when I compile in an off-the-shelf library and my code triples in size, but how many more features do you have left to implement? Might not be worth the time to optimize for size if you're almost done checking off the requirements. You probably need some sort of alarm to let you know it is up to temperature and probably a neopixel ring graph of something.

Meanwhile I have had building a battery powered ultrasonic range parking sensor with 7-segment distance display on my project list for like 3 or 4 years now, just sitting there because I didn't want to use off the shelf parts like the *so expensive* I2C 7-segment displays. I did write a really awesome multiplexer for driving the segments though. I might just throw it together on a breadboard today with those expensive parts and no OSH Park order. You've inspired me!
 
Is the parking range sensor for the garage so you know when you're in far enough (a digital tennis ball on a string) or is it going to be attached to the car so you know you're close to other vehicles when parking?

There's not much more functionality to be added, but I'm sure I can add some scope creep to this!

Features to add in order of priority:

  • Create multiple pages for the OLED display and cycle through them
  • Read the status of the steam switch ( middle rocker switch ) to crank up the boiler setpoint for the steam wand.
  • Either add an analog pressure gauge to the front of the machine or use a pressure transducer and use the MCU and OLED to display it
  • Read the status of the brew switch so that the OLED displays a second timer to time the shots
  • Add a second SSR to PWM control the water pump to add a pre-infusion stage
The machine already has a visual indicator to let you know it's up to temperate and it's really quite a neat design. The far right rocker switch is the brew switch. It has a small neon bulb in it that turns on when there is no current running through the boiler. This particular feature of the machine really had me scratching my head as there is no electronic circuity in this machine. So how in the world does a light turn on when power is removed from the boiler, yet turns off when power is added from the boiler? Prior to adding the MCU, power to the boiler was controlled by a bimetallic thermostat.

As it turns out, they are exploiting a known feature of a neon lamp where the lamp is wired in series with a load. When the load has power going to it, it basically shorts out the lamp and it turns off.

Click here to see the incredibly simple, yet well thought out electrical diagram for this machine.

Even without the OLED output showing me the TC temp, I could determine that the unit was ready by watching the flickering of the brew light. Once temps were stable and the PID loop was simply maintaining the temps, it would flicker in a pretty predictable pattern.

QFIjOQMl.jpg
 
Last edited:
The franken-couple works! It's reporting about 1c below ambient compared to my Thermapen, which is decent enough.

vBidWEJl.jpg
 
Pretty good pretty good! I'll have you know you're also responsible for this little project on Sunday


Yeah it is just a digital tennis ball but I thought it would be fun to see the display light up and count down the distance (in cm) to the car. I already have a weight hanging on a string to indicate where to park but when you have this sort of technology you can't just have some analog method that works, you gotta make it overly complicated! I have gotten a bit spoiled by being able to upload HeaterMeter firmwares through the network (and to all my ESP8266 devices) so it is a bit disappointing that I have to carry a laptop out there if I want to try a new firmware. I spent most of the time on the filtering algorithms and switching from high power mode to low power sleep because I was going to run it on batteries. Unfortunately, it doesn't seem to work very well past 90cm so it isn't nearly as cool as I had imagined and probably will just be returned to the breadboard box once the blue tape falls off.
 
Spiffy! I thought those ultrasonic sensors were good for 300-400cm of range. The sensor looks pretty high compared to the front bumper of the car.
 
It is actually just below the hood level. It would be better at bumper level but I didn't want to have to make a longer wire harness to get it to where it should be. I might not be using the NewPing library right although it seems pretty straight-forward. The real problem though is that it doesn't look cool enough, just some boring numbers. Maybe I need to add a RaspberryPi hooked up to an old LCD monitor with some sort of sci-fi animation so I can feel like I am docking at a space station!
 
You must log in or register to reply here.

 

Back
Top