Temperature is another kettle of fish as you have demonstrated.
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.
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
Does your rig make good tasting espresso!
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.
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.
... and discussion of the page immediately above:
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.
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.
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.
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.
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 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.
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.
If those tablets were running something like Aicas Java runtime, it would be much different.
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.
On bigger devices (PC/SBC/...) with an OS, Tcl/Tk is a wonderfully effective programming tool!
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:
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.
1) Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
2) Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2
Especially amusing as I was thinking of adding SNMP support to my coffee machine, so the humorous RFC above might actually be relevent.
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.
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!