Espresso Machine Powered by Tcl/Tk | Hacker News Reader

Espresso Machine Powered by Tcl/Tk

groups.google.com

136 pointsblacksqr43 comments

I have used Tk (through Python's tkinter) for several touch-based "kiosk" applications. It is surprisingly useful and productive for that. What you need is small (~100 lines) custom ttk style which adds larger padings to buttons and such and maybe makes it look "modern", flat and colorful and that's it. It certainly makes more sense than making such things web-based.

That's me on the video. I'm a long-timer Hacker News reader, and happy to have a geeky chat here about what I'm up to. -john

I'm curious about your measured pressure drop between the pressure at the pump, and the pressure at the group head. Since coffee machines are low flow and travel through a short distance of presumably stainless steel pipe, my quick calculations indicate a minimal pressure drop compared to the expected 9 bar of pressure used to pull a shot.

Temperature is another kettle of fish as you have demonstrated.

The problem is that your mental model of how a boiler based espresso machine works is not how they are actually wired.

Here is how they actually work: 9 bar of pressure are generated between the pump and a flow constrictor which is placed before the boiler, pumping cold water into the boiler. This cold water then displaces the water in the boiler, which then gets pushed to the espresso.

Thus, the final pressure depends on the compressibility of the steam (or airspace) in the boiler. In practice, you get about half a bar less at the espresso than the pump got behind the boiler. But, the real numbers depends on lots of factors, many of which are invisible.

Hey love the machine! So curious about it.

I've built a couple cocktail mixer machines for personal usage in the past and always wanted to build an espresso machine. My main fear was dealing with almost boiling water and pressure, that kinda scared me a bit. Do you have any tips, links or just fun stories about developing machines like that that you could share? :D

There are lots of people who have "Arduinoed" their coffee machines, especially the Rancilio Silvia, which is an ugly-but-good-value machine, which can be PIDed and hotwired. That's a good place to start.

Big fan of yours dude. I'm waiting to replace our Rocket Giotto, hooked in to a tmd-56 w/ Artisan (that I use for thermal profiling into Artisan), with one of your machines. Keep up the awesome work!

The price ($2,500+) seemed very high. I was wondering if there are specific technical issues that required the bump up in pricing.

Stupid question but I didn't see it asked or answered:

Does your rig make good tasting espresso!

While tastes are subjective, and there are a lot of variables involved, the Decent espresso does pull a solid shot. The reviews so far are pretty positive.

How does this design compare to a Synesso?

Tcl/Tk is one of the cooler tools out there, though I wish it were not so... string-based.

Much like Clojure took a bunch of neat stuff from recent programnming languages (first class hash maps! immutable data structures!), I'd love to see a Tcl variant that takes some inspiration from recent trends.

> Tcl/Tk is one of the cooler tools out there, though I wish it were not so... string-based.

The "string based" part lies at the very heart of Tcl and plays a big role in what makes Tcl Tcl. However, modern Tcl has moved away from "everything is a string" to "everything is also a string". The difference is that in the normal execution path native types are manipulated for speed, but the string representation is always available should one need more dynamism.

Tcl/Tk pioneered the notion of a scripting language as a library. It got threading right. You can run multiple independent Tcl interpreters in the address space of your process and they can exchange messages. No need for GIL, no need for serialization/deserialization (pickle/unpickle) ... just within process memory copy (or no copies in case data is immutable). Its virtual file system was another great innovation.

Lua has taken the crown for small embeddable/extendable language but I still have a soft corner for the playful vibe of Tcl. I would hesitate to use it in a project where I have to interact with folks with whom I have not programmed before (things like 'upvar' and 'uplevel' ups the amount of trust you need). But when its play time, breaking out Tcl is one of those guilty pleasures. Getting rarer these days, playtime that is.

Tcl had a reputation for being slow. But those were different times when the standards for 'fast' was much more demanding. Now I doubt it would be any slower than Ruby, it would likely be faster.

Ideas about where Tcl went wrong:

https://utcc.utoronto.ca/~cks/space/blog/programming/WhereTC...

https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...

... and discussion of the page immediately above:

https://news.ycombinator.com/item?id=3579088

Tcl does have a strange syntax. It tries to be "Lisp but with strings" and strings aren't even as easy to work with as what Lisp gives you, which are singly-linked lists of tokens and other singly-linked lists. And doing Lisp with other representations isn't that new: XSL is "Lisp but with XML", for example.

I think the second link is a great read and I agree with most points. If Tk had been moved to GTK or QT (probably GTK due to licensing) early on, it could have maintained its role for making portable GUIs a bit clearer. Though, in my eyes, Tcl/Tk still is the easiest tool to use portable UIs. Especially with Tclkits, you can make single-file executables, which are very convenient to deplay, I have had great sucesses with that.

Today, Python has grabbed a lot of attention from Tcl - for "programming" it might be the more elegant language, but for "scripting" Tcl is hard to beat. But it is ironic that Python still ships Tkinter as the default GUI solution. If any language, Python should have standardized on GTK support, it had good support for GTK, but never standardized it.

The Tcl syntax is a bit rough, but is built on extremely simple rules. This has two benefits. First of all, it is - that was what it was designed for - a great language to control tools, that is, script complex programs. Thanks to the syntax, every function immediately becomes a command a user can type, no complex syntax for the input required. In that sense, like shell scripting, Tcl sacrifices a bit of syntax suger for the developer for a nice interactive input syntax. It is vastly nicer to program in compared to the shell languages :) The second benefit ist the ability to extend the language by the users - it doesn't even need a macro system for that like Lisp. Tcl is one of the few homoiconic languages.

Finally, while Tcl isn't as activelely maintained and especially extended as other "modern" languages are, this cuts in two directions. The implementation is extremely robust and many features are very efficient. Of course the basic execution speed of Tcl code is one of the slower scripting languages, but the libraries it uses are excellent. It had high performing event handling many years before Node.js made that populer.

>Tcl is one of the few homoiconic languages.

I've been diving back into Scheme and one thing I found out was that in Scheme, procedures don't normally have an "external representation." I.e., once a procedure has been defined, I don't think there's a way to get that definition back out.

Tcl is really interesting in this aspect since procedure definitions (names, argument lists and bodies) can be viewed using the "info" command.

With that in mind, I'd say it's actually more homoiconic than Scheme.

> I think the second link is a great read

Thanks!

Tcl does have a strange syntax.

It seems strange until you internalise the 12 rules, then it flows very naturally. There are none of the weird quirks you get in Ruby or Perl.

https://www.tcl.tk/man/tcl/TclCmd/Tcl.htm

It's funny, I hear people talk and talk and talk about simplicity in programming, and see post after post about it on HN, and everybody seems to think it's a great idea, until it's staring them in the face.

I think the issue is that what Tcl people think of as simplicity is for most people an uncomfortably-radical minimalism.

Thus conscience does make cowards of us all, and thus the native hue of resolution is sicklied o'er with the pale cast of thought.

Tcl hasn't been string based since 8.0 added dual ported objects 20 years ago. Meanwhile the latest JavaScript is burdened with keeping full source strings hanging around in memory so that comments and whitespace can be preserved.

Though to be fair, full source strings are kept around in memory for lazy compilation anyway (and other lazy computation).

Tcl added first-class hash maps in the form of dictionaries several years ago.

Tcl also added coroutines and a native object system in the past decade.

Tcl has variable trace hooks which can be called whenever an attempt is made to change a variable's value, the hook can block the change, making any so-traced variable effectively immutable. (see: https://rosettacode.org/wiki/Enforced_immutability#Tcl )

> Tcl/Tk is one of the cooler tools out there, though I wish it were not so... string-based.

Tcl was designed in a different time when memory was scarce.

The point of being so "stringy" is that you could parse it in place in the same amount of RAM as the original "string program" took up.

I really would love something with similar constraints as the old Tcl for microcontrollers. BASIC used to run in 4K RAM with 4K ROM--I really wish we had a modern equivalent that I could connect to with a UART.

Quite often my constraint on a microcontroller is waking up and waiting for a sensor, transmitter, etc. -- I have forever to run interpreted code. A small language would be really nice.

Ironically, because Tcl was made to run GUIs on very limited hardware (old Unix machines, 30 years ago) it runs really nicely on slow Android tablets.

Its focus on asynchronous programming, rather than relying on threads, really helps, as does the small memory footprint (105mb of RAM used for my app).

Java-based apps on the same tablet that I supply with the espresso machine run at a crawl, whereas my Tcl app feels normal.

Yes, my experience also always was, that while the pure Tcl code performance isn't great, most Tcl programs perform very well, due to the low resource consumption and overhead.

It doesn't help that Google did a pretty lousy job with Dalvik.

If those tablets were running something like Aicas Java runtime, it would be much different.

"Androwish", which is Tcl/Tk ported to Android, runs mostly on the C layer sitting on top of Linux. As such, it's way more "performant" than Java.

Not quite 4k, but MicroPython runs on 16K of RAM.

As I understand it, that's a very cut back version and doesn't include the compiler/interpreter so you can't just hook up to a UART and start reprogramming. I could be wrong, so please feel free to correct my statement if it's completely off the wall.

What I want is something that I can hook up to the UART serial port, and start typing interactive commands into it to debug why my system is hung/stuck/etc. It needs to live in about 4K of RAM (and I can trade quite a bit of flash to do that).

16K of RAM is too much. Something like a Nordic nRF52811 only has 24K of RAM, and a lot of that gets used for the Bluetooth stack.

Sounds like you might want to explore Forth a bit. Punyforth on the ESP8266 is a convenient way to try get started hands-on, Jonesforth if you want to learn how you could go about implementing one.

On bigger devices (PC/SBC/...) with an OS, Tcl/Tk is a wonderfully effective programming tool!

...While checking the nRF52811 product specification to learn more about this chip, I found out that it contains a Cortex M4 CPU. You can research some of the existing Forths for these processors (myself I find a tethered Forth convenient to work on CPUs like this).

Very nice!

We at our university chair also wanted to have a touch-pad kiosk for our drinks (coffees etc). So far it is just used to do the accounting, i.e. count which user drinks how much, and whether he has paid.

I decided to use Kivy instead of Tcl/Tk, because I thought I can have some nicer animations, and it would feel more modern. I was quite happy with the result. Here with screenshot: https://github.com/rwth-i6/drink-kiosk

The next step which we planned was to actually wire this app with our coffee machine, and allow drinks only via the kiosk app. But we never got to that so far, unfortunately.

Historic precedent http://www.tldp.org/HOWTO/Coffee.html

Two very fun coffee RFCs:

1) Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) https://www.ietf.org/rfc/rfc2324.txt

2) Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2 https://tools.ietf.org/html/rfc2325

--- Especially amusing as I was thinking of adding SNMP support to my coffee machine, so the humorous RFC above might actually be relevent.

Extremely interesting YouTube talk also. You learn a lot about making good coffee.

My first job was working on a product called qacafe cdrouter, which is an entire product written in Tcl. (but not tk.)

It is amazing what you can build if you rely on organization and convention. I had nothing to do with creating it, but I really learned a lot from some really amazing people the years I spent there -- how designing a thing is generally the first requirement for scaling a thing.

Very timely... I recently picked up an old Miele fully automatic espresso machine (grinds, tamps then expells) that's controlled via an 8Mhz 6502 like CPU.

I'm in the process of overriding the cpu with my own controller and adding my own GUI to control/tweak the process.

I enjoyed John's talk and can relate!

Google groups now require a login.

I just tried viewing the link in Private Browsing and it seemed to work. Not sure why you would be getting kicked to login.

Google Groups has a weird state, if it detects some account cookies, it forces you to login, but it works fine if not. It's been around for years.

Shows that Tcl/Tk is still relevant in various contexts. Impressive work!

Reply on news.ycombinator.com