rob.rho.org.uk

A year ago, I got a 3D printer. A year later, is it gathering dust, or am I still using it?

I’m happy to report, while it’s not quite as busy as it was for the first few weeks, it is still in regular use. While I’ve made quite a few posts over the year (collected at the end of this one), I thought it might be interesting to look back and see what kinds of things I’ve been using it for.

One obvious category (indeed, the thing the printer is doing as I type this) is toys. This was the original impetus for pushing the button on a 3D printer. Specifically, articulated dragons — our youngest in particular loves these. While they’re cool in their way, if this was all the girls were using the printer for I’d be disappointed. However, they’ve been substantially more creative, in particular with doll’s furniture and accessories. The eldest has got very into TinkerCad, and has custom designed numerous pieces, the most ambitious being a working wheelchair for a doll with a broken leg. HeroForge is also proving a hit.

Another cliché is that the main use of 3D printers is to print accessories for 3D printers, and I’ve done my fair share of that. Along with the usual scrapers and buckets, I’ve printed out quite a few mounts for hygrometers¹, and most recently a Y-splitter to allow me to keep the external spool connected at the same time as the AMS. Printing things to better print things is a bit circular, but a nice fringe benefit.

I’ve also found it surprisingly useful for things around the house. Sometimes I find myself printing out things that are better and cheaper mass-produced, like curtain hooks. The benefit of using the printer is that you can get one or two rather than buying an entire pack, and you can get it in ten minutes rather than making a trip to the shops. More often, though, I’m printing something that I couldn’t buy, as it’s custom designed to meet a specific need. An example would be the wall mount for our kitchen scales — we have something that exactly fits the scales we have, and the location where we want to put it. I’ve picked up enough basic CAD skills (OpenSCAD and FreeCAD) that I can create pieces to solve particular problems without too much effort, and doing so is immensely satisfying.

I recently got a Skadis pegboard to display some of my retro computing bits and pieces. 3D printing is the ideal way to get mounting hooks and other attachment to support things of all shapes and sizes, either designed from scratch, downloaded from communities like Thingiverse and Makerworld (where Skadis accessories are a thriving subgenre), or a custom combination of the two. I can see retro computing being another area where the ability to make custom 3D printed parts will be handy; I’ve only done one project in this vein so far, but I can see more on the horizon.

One thing that I’ve not used the printer for much, at least yet, is making parts for keyboards. I’ve made keycaps, but I’ve just not been able devote the time needed for a bigger project. Hopefully, I will soon.

Overall, I’m glad that our 3D printer has continued to prove its worth. It’s not in action every day, or even every week, but it’s great to have on hand, and I certainly don’t regret taking the plunge.

3D printing posts this year:

• 17 Nov 2024: Adventures in the Third Dimension
• 23 Nov 2024: Multicolour Waste
• 29 Nov 2024: First Functional Print
• 22 Dec 2024: The Cat is Lying To You
• 24 Dec 2024: Deck the Halls
• 4 Jan 2025: Keyboard Tray and FreeCAD
• 12 Jan 2025: You Wouldn't Steal a Boat
• 31 Jan 2025: Three Shots
• 18 Jul 2025: Coffee Cup Sleeve
• 10 Aug 2025: Miniature, Maxiature
• 3 Sep 2025: A Customisable Cable Clip
• 19 Oct 2025: A New Material

I have a bit of a confession to make. I don’t get Forth. It’s a language I’ve admired from afar, and its approach is genuinely novel and intuitively appealing. However, every time I try to dig deeper, I just… don’t get it.

It’s not that I don’t like different languages; on the contrary, I’m fascinated by them. You’re unlikely to come across Forth these days if you’re not. Nor is my experience limited to mainstream C-alikes; I’m familiar with Lisp and Scheme, ML and Haskell, assembler and SQL. I’ve played with SmallTalk and Prolog and TeX and Scratch. My last job revolved around Verilog and TCL.

I mention that to emphasise the fact that I come to Forth with an open mind. More than that, I come with eager anticipation, as there are a lot of aspects that look good. I like the lack of extraneous syntax — I don’t think I’ve seen a language with less boilerplate and ceremony than Forth — and the use of the stack takes this further by making the flow of data largely implicit. It reminds me of the point-free style in Haskell, putting the focus on what you’re trying to achieve rather than the mechanism by which you’re achieving it. I’m also a fan of the way it erases the barrier between runtime and compile time, and offers an interactive, malleable environment without the overhead that usually entails.

Forth has a reputation of offering both low-level performance and high-level structure, and this is where I run into problems. It certainly has the former, but the more I dig into the details the less convinced I am of the latter. Perhaps this was true when it was conceived. It’s certainly more structured than assembler or BASIC (at least the basic versions), and less rigid that earlier languages like FORTRAN and COBOL. However, even at the time of Forth’s inception in late 60s these weren’t the only options. Its near-contemporary C offers a similar combination of flexibility and performance, with somewhat different tradeoffs, and Lisp was hitting many of the same bullet points almost a decade earlier.

Both of those languages were both useful at the time of their invention, but their core concepts were solid and flexible enough to grow and spawn entire families of progeny and imitators, going far beyond their original scope. Forth, in contrast, seems to have stayed largely in its lane of writing efficient, close-to-the-metal code on a small scale. From what I’ve seen so far, as you move to more complex applications — in particular, more dynamic ones that operate on less uniform data — it feels like Forth’s flexibility and minimalism are working against it.

I’m not giving up, though — enough smart people have extolled the virtues of Forth that I remain convinced that there’s something there. I’m just not getting it. To try and get into the mindset of its heydey, I’ve been exploring Acornsoft FORTH on the Electron, aided by Richard De Grandis-Harrison’s extensive book FORTH on the BBC Microcomputer. Maybe it will click, and even if it doesn’t it’s definitely something different.

As mentioned in my last post, I recently purchased an eSun eBox Lite filament drier. All was good at first, and it performed well drying out a roll of PETG, but the next time I came to use it I noticed that the fan wasn’t running. It was still within the return window, but as it’s both pretty bulky and pretty cheap, I decided to have a go at fixing the problem instead. This proved straightforward, and so I’d still recommend this as a low-cost and effective drier.

I came across this Reddit post describing a similar problem. It pointed me in the right direction, but the thread is a few years old and doesn’t include any pictures, so I thought it worth writing a quick post to illustrate the process of taking the box apart.

Doing so is pretty straightforward:

• Open the drier and remove the two small screws in the heating plate with a Phillips 0 screwdriver (left hand photo).
• Close the drier and put it on its side, with the bottom facing you.
• Remove the four rubber feet at the corners (right hand photo; you don’t need to remove the middle one), and remove the screws underneath these with a Phillips 1 screwdriver.
• Gently slide the bottom of the drier out. Be careful of the wires connecting to the circuit board to the heating element, the control panel and the fan. The panel and the fan can be removed from the upper housing; these just slot into the plastic.

Once the device is open, it’s easy to check the connectors for the various components on the circuit board, which it seems have a tendency to work lose if it’s moved around too much. Sure enough, I reseated the fan connecter and everything was back to working as normal. It’s safe to (briefly) power it up to test it while disassembled, and when you’re happy reassembly is just matter of reversing the above steps.

Since getting a 3D printer almost a year ago, I’ve stuck to PLA. This is the default material for FDM printers, and for good reason. It’s produced from starch rather than petrochemicals, it prints at low temperatures, and it has decent aesthetic and mechanical properties. It’s a great all-rounder. But it’s not all there is.

My Bambu A1 isn’t enclosed, which rules out higher temperature filaments such as ASA and Nylon. However, there are still a few options. I decided to try PETG, which is similar to PLA but less sensitive to UV and temperature fluctuations, and thus better suited to outdoor applications.

The main downside of PETG is that it’s much more hygroscopic: it absorbs moisture from the environment. Keeping PLA dry is advisable, but with PETG it’s essential. Knowing this, I invested in a basic filament drier (the eSun eBox which also allows you to print with the spool in the box) and some desiccant beads. After a full eight hours of drying, I printed out the traditional test.

The results are shown above; the PETG is the black one, next to one I printed a while ago in red Bambu PLA Basic. I’m pretty happy. First off, the drying seems to have been worth it; I had none of the stringing or popping problems that often come with PETG. The quality is up there with the best I’ve had with PLA, without needing to tweak settings. I also like the glossy finish (but couldn’t manage to get a good photo that showed that off).

So, successful test. Next I’ll try some practical prints; one of my car charger holders is looking a little worse for wear, so a replacement for that is likely to be first on the list. I imagine I’ll still be using PLA for most things, but it’s good to have other tools in the toolbox.

John McCarthy is credited with two major contributions to Computer Science. The first is the term “Artificial Intelligence”, and the second is the programming language LISP. In part due to this entwined history, and in part due to its particular strength, LISP was long though of as the language of AI, but it’s more than that — it’s not an exaggeration to say that pretty much every programming language in use today borrows from LISP to a greater or lesser degree, and LISP itself is still in alive and well in various forms. There’s a lot of history to delve into, but recently I decided to try out something almost equidistant from today and LISP’s origin in 1960: LISP on the Acorn Electron.

This isn’t actually the first time I’ve used that particular implementation. As a child in the 80s, I remember being intrigued and picking up a copy on cassette from a market stall for a few pounds. Unfortunately, the experiment was short-lived, as the software didn’t come with any documentation. I fumbled around trying to get the enigmatic “Evaluate:” prompt to do something useful, but didn’t get anywhere, and soon moved on to less obtuse pursuits.

A few decades later, and I’m returning to it better prepared. Not only do I have both a reasonable grasp of the theoretical foundations and a degree of practical experience with a variety of LISPs, I also managed to find a decent second-hand copy of LISP on the BBC Microcomputer by Arthur Norman and Gillian Cattell, the very documentation I was missing the first time round. So, with the barriers out of the way, what is LISP on an 80s micro actually like?

To my surprise, pretty good. The Electron is a far cry from the Lisp Machines that were its contemporaries, or the mainframes and minicomputers that LISP grew up on. In particular, it has little RAM, and a CPU built around bytes rather than words. To fit inside these constraints, Acornsoft LISP is an interpreter rather than a compiler (as more fully-fledged LISPs tend to be), and it only includes the essentials — so no arbitrary-precision arithmetic, no macros, no conditions. What’s left, however, is a flexible and well-thought-through environment that captures the flavour of LISP, especially for learning and exploration.

This environment is both interactive and transparent, in the best traditions of the REPL¹. This provides the immediacy of BASIC with a far more structured and powerful underpinning. An upside of the interpreter approach is that it puts the equivalence of code and data, one of LISP’s strengths, front and centre. Functions are just lists starting with the symbol LAMBDA, and can be manipulated as such with no intermediaries.²

This transparency forms the basis of one of the more interesting aspects of the system: the interactive code editor. For most people familiar with LISP, “editor” immediately conjures up the image of Emacs and similar editors, but this isn’t that. It’s more akin to the long-obsolete concept of interactive line editors such as ed³ and ex⁴. Instead of moving a cursor around a visible display of the source code, you issue a series of commands to manipulate it, and then print out some or all of the modified text.

What makes the Acornsoft LISP editor different is that, unlike ed and ex, it’s a structured editor — instead of manipulating lines of text, the commands manipulate lists. As functions are, like pretty much everything else, just nested lists, this provides an immensely powerful way to both navigate and edit the code, with the added bonus that introducing syntax errors is impossible. It’s somewhat akin to block-based programming languages like Scratch, and while it takes a little getting used to it’s a great interface when it does click, so much so that I find myself wondering what a modern take would be.

The documentation is equally inspiring. Norman and Cattell start with a thorough and well-paced walk through the fundamentals, and then move on to some more substantial examples. The first, as is required by law in any book on LISP, is a LISP interpreter, followed by some other LISP-related facilities such as a pretty printer, a correct-but-slow implementation of arbitrary precision integer arithmetic, and the internals of the aforementioned structured editor. They then broaden out to more general parsing, evaluation and generation of machine code, demonstrating the suitability of LISP for building compilers (and the authors’ interest in that field). The chapter is rounded off with a bare-bones implementation of a text adventure. This is clear, general and extensible, and shows off the expressiveness and power of LISP.

So, after all that, is Acornsoft LISP a good choice for programming the Electron? If your aim is to produce something for others to use, probably not — aside from the fact that they’d also need to have the interpreter, the overhead is likely to be too much. With such limited resources, you usually want to squeeze as much performance out of the hardware as possible, and that’s not where LISP’s strength lies. However, if you’re programming a one-off solution for yourself, or exploring a problem interactively, it seems like an excellent choice. A modern analogue would be something like Jupyter notebooks. Not bad for a little computer from the early 80s, even if I didn’t realise it at the time. I’m glad I revisited it.

The original photograph behind the Distracted Boyfriend meme is by Antonio Guillem. The books pictured are LISP on the BBC Microcomputer by Arthur Norman and Gillian Cattell, referenced in the text, and Understanding Deep Learning by Simon J. D. Prince, a somewhat more recent take on AI.