I’ve been at the CBA for seven and one half years and it is time to scoot. I have learned very many things, met many exceptional people, and built many circuits, fimwares, machines, systems, etc.

A ‘thesis proposal’ is what you do when you think you have figured out what you will do to finish a PhD. Academia is weird because you are inventing new things, and so no-one (besides a collection of your peers / advisors) can decide if you have done “it” or not. The proposal is to say: I will do this thing, and that will be enough - if your committee agrees, you do the thing, and then you are done. A bit of a contract.

I am proposing to outline (and develop!) a systems architecture that could replace GCode. The thing is ostentatiously titled:

The End of GCode: Machine Architectures for Feedback Systems Assembly

I made the document into a website using an awesome tool called quarto that I would recommend to anyone who has to write papers and thinks that LaTeX is kind of insane. The website is here. There is also a pdf (auto generated) - but the website is vastly superior, and if you are intrigued by the idea you should read it and tell me what you think. The slides that I used for the presentation are here.

Most of the world’s 3D Printers and CNC Milling machines’ realtime controllers know very little about what they are doing, they simply consume and execute series’ of low-level instructions called GCodes. Those codes are generated in software that knows little about the machine (and has no way to verify what it does know).

GCode is known by many and loved by few (besides cases of trauma bonding). It is an archaic language script / layer / interface / bungled mess. It gets in between us (programmers, users, people) and machines, which are doing very cool physics but we would hardly know how to ask them about it.

A systems overview of the contributions made in this thesis. I refactor a mostly feed-forward workflow and replace parameter selection with online optimization. In this architecture, machines can continuously improve datasets and update models of their own physics, which they use in order to control their outputs.

The core contribution I am making is basically a system architecture that re-casts machines as networks where path planning, hardware control, and sensing are all bits of the same distributed system. Instead of GCode getting in the way anywhere, we can freely connect various software blocks into one another, running as they are on various pieces of hardware: motor controllers, sensors, ‘big-computers’ (aka PCs: things with lots of compute power), etc. This lets us easily move pieces of the controller around, recombine them, take them apart, inspect them, share them, etc.

Machines that can measure what they are doing: here, an FFF printer measuring nozzle pressure and filament flowrates during printing.

This seems kind of obvious (aren’t all machines already made of various blocks of compute?) but state-of-the-art controllers are strictly partitioned; parts of the control (CAM, path planning) happen ‘before’ the GCode, and the rest (motor control, acceleration control, etc) happen ‘after’ the GCode. The partitioning is largely, we think, due to historical mistakes, inter-firm boundaries, and limited embedded compute availability.

The partition has made machine controllers very difficult to modify, measure, and repurpose. It also poses a real problem for high-level planning algorithms (like CAM), whose fundamental constraints (how fast can I push an endmill through this material, how fast can I extrude this filament, and what temperature should I use?) are functions of the machine’s physics - but we can only measure those physics by interacting with the low-level devices!

I develop lots of new bits of tech for this: a very simple, flexible and decently performant networking scheme, some simple link layers and data presentation layers, and of course a new approach to motion control. The controller is composable (easy to edit and configure), and inspectable - it exposes lots of internal states to programmers.

Motion controllers’ internals are normally hidden from high-level programs (like CAM tools). However, low level motion states and optimizer outcomes are important for their performance. In this example, I show the results of rotating the infill in a 3D print so that it aligns with a machine’s anisotropic acceleration.

But why? Don’t machines work well enough? Well - have you ever tried printing a new filament on a printer that didn’t have a preset set of parameters for it, or tuning the motion system for a new machine you have built, or programming a toolpath on a CNC machine? Or re-purposing a 3D printer’s controller to do something silly or novel? These things are not easy, but they should be. They are difficult primarily because machines don’t know what they’re doing - they are just following very simple instructions very faithfully: once we have exported GCode, the smarts have left the system.

So! I then use my fancy systems architecture to develop (1) machines that can tell what they’re doing (sensors!) and then (2) a controller that can use that data to get smart, a model predictive controller for FFF printing.

Distributing controllers lets us more rapidly develop fancy controllers, like this model predictive controller for an FFF machine’s motion and flow systems, which are optimized together, online.

For more, visit the site, and give me about three or four more months to finish the project and get stamped… after which I will take on the project of trying to explain and share all of the goodies into the commons.