9 Conclusion
9.1 What is Possible Now that Wasn’t Before?
In the current state-of-the-art, machine workflows are computationally feed-forward: we set parameters in CAM tools, they are compiled into GCodes, which the machine follows to the letter. Neither the CAM nor the machine have formalized knowledge of machine or process physics. This means that machine users must rely on tacit knowledge, intuition, or someone else’s pre-determined settings to successfully use machines.
In this thesis I modified these workflows by adding models of key machine components: their motors, their kinematics, and their processes. Using models, we can build workflows that are fundamentally different in the state-of-the-art. Rather than feeding parameters forwards directly at a low level, we can describe optimal outcomes for our tasks, apply heuristics at a high level, and use models and model-based control to mediate between real-time physics and our targets. This amounts — partially — to machine systems that “know what they are doing,” in that they use simulations of real world physics to choose their actions.
Models enable not just better machine control, but can help us to design machines by showing us hypothetical performance under different parameters. They can also help us to better design machine toolpaths by simulating those virtually before we test them in the real world.
Machines are heterogeneous: many types and models exist, and even individual instances of the same hardware will vary (and vary over time) in subtle ways. That is why a big focus in this thesis was to use the machines themselves to build models. This not only simplifies the alignment of controller expectations to reality, it also enables us to detect changes to machinery over time, watch for errors, and improve models over time.
None of this would have been possible with GCode based machine controllers. The work in Section 2.3, Section 2.4, and Section 2.5, each of which works to replace some aspect of the firmwares and controllers that run underneath GCode (and some layers above it) was a critical prerequisite. With those contributions, I also showed that we can develop this new family of controllers with a reusable set of hardware and software modules rather than re-writing firmware or re-designing circuits for each new process.
9.2 Feedback Systems Assembly
I want to return to an observation that I made in the introduction (1.1), which is that GCode based workflows are akin to compilers in computing; they rely on the regularization of the low levels of a system (and heuristics about those systems) to function, and they are fundamentally feed-forward. But the regularization of machine systems is an impossible task. There are many types of machines made of many different components. Those are built by a mixture of firms and individuals, each understands a part of the problem but not all of it.
If feed-forward doesn’t work, we need feed-back systems assembly; not just for the use of these systems, but for their assembly and integration. In Chapter 7 I explained how models can help here. They provide representations of heterogeneous hardware that can be programmed against; from a systems viewpoint (Section 7.2.1) and also a physical one (Section 7.2.2). In building these models with data from systems themselves, we can ensure that the views we have of our systems as we build applications are accurate. That can eliminate the need for heuristics; we don’t need to make assumptions about what will happen because we can inspect models to find out.
9.3 Closing Note: Imaginary Worlds
Like many people who are exposed to it, I always found digital fabrication exciting for the possibilities it opened up as a craftsperson and engineer. I fell down the rabbit hole when I started trying to build my own machines, which I did mostly because my time was free, I didn’t have any money, and I wanted to have machines of my own.
I started the research arc that led to this thesis because every time I tried to modify these machines (to repurpose 3D printer firmware to make a five axis milling machine, or to use a machine interactively), I was stymied by obscure systems with strange representations, running firmware whose core principles were not explained anywhere.
When I came to MIT I found that even here the nuts and bolts of what makes a machine tick are not very well understood by the people who use them. However, almost everyone who spends much time with them comes to see the same frustrations. As Ilan Moyer would say, they do not feel like tools, but it seems like the aught to.
At the dawn of the First Industrial Revolution in 1745 Piranesi etched his Imaginary Prisons, one of which is above in Figure 9.1, depicting a dark future where humans are indentured to machines and systems of our own making. The future for digital fabrication is not so dire, but we seem to have failed in building machine systems that work for humans: they should be teaching us, and should enable us to willfully modify them. In their current configurations, machines for digital fabrication require serious engagement with occult knowledge. There has been excellent progress on this front recently towards consumer-facing equipment (mostly 3D printers), but we have yet to make the development of new automation straightforward. This seems urgent at a time when our economic, demographic and environmental concerns will require us to build lots of tools very quickly.
In this thesis, I tried overall to contribute where I could to make machine operation and development make more sense, trying to transform these mysterious systems using common place tools: everyday programming design patterns and physics that we each have some lived intuition for.