Chronicle 1 - AI CNC

By Basil Buwalda | Equiavia

TL;DR;

Here at EQUIAVIA we enjoy making things. We already have a 3D printer, and recently bought a CNC machine to explore what we could make with it. It is mostly for R&D purposes, to see what solutions we can deliver to hobbyists as potential products.

I started by asking Claude to help design something for our first cut. Less than two days later, we had a working prototype connecting that conversation to a physical machine, including a small application Claude had written to communicate with the CNC over USB.

During cutting, I described what I could hear and see. Claude used that feedback to adjust the machining programme. It also retained information about the cutter and type of cut to inform future machining profiles.

I had expected help learning the software. I had not expected the interaction with the machine to feel so seamless, Claude to be so capable.

I am blown away by what we achieved... however, I am concerned and excited at the same time about what his means for us in the next few years.

Getting from an idea to a machining plan

The first step was straightforward. I described what I wanted to make, supplied the specifications and asked Claude for a sketch.

I checked the sketch before asking it to create a 3D model. Claude did that through FreeCAD, using Python to work with the application.

The next step was computer-aided manufacturing, or CAM: deciding how the cutter should move through the material to produce the shape.

That required more context. Claude did not initially know which machine I had or which router bits were available. We spent a couple of hours working through the machine specifications, feed rates and tooling. I captured the bits I owned, and Claude asked questions about the setup.

I learned a lot during that exchange. Some of the work was explaining my equipment to Claude. Some was Claude explaining machining terminology and choices to me.

That context mattered. A 3D model describes the shape you want. A machining plan must also account for the equipment and tools available to make it.

Once we had worked through those details, Claude generated the CAM profile and a run sheet for the job.

The point where the workflow became the problem

Getting the design ready was only part of the job. Running it introduced another set of difficulties.

We initially used Candle, with Claude operating its interface through computer use. It was cumbersome, and I could see we were consuming a lot of tokens navigating the application.

I asked Claude to investigate alternatives. CNCjs became one option. Claude also suggested building a small application specifically for our needs.

I was sceptical. Writing another application should not automatically be the answer when established software already exists.

I pushed it to examine the CNCjs repository, understand how it worked and look for security issues. We eventually chose to try a smaller application tailored to this experiment. That was a decision about our particular workflow, rather than a conclusion that CNCjs was unsuitable more generally.

Claude spent about an hour and a half building the application. We then moved on to dry runs with the machine.

When the machine started moving

With the computer connected to the CNC over USB, Claude could issue commands through the application we had built.

It asked me to verify what was happening. I was its eyes and ears at the machine.

We worked through adjustments, then started cutting. When something sounded or felt wrong, I described it. Claude used that information to change the programme as we worked.

The interaction sometimes felt like having an experienced machinist beside me, asking questions and responding to what was happening. That describes the experience, rather than a claim that the system had a machinist’s expertise.

Its understanding of the physical situation depended on what I reported. It could not hear the chatter or see the cut for itself.

That dependency became one of the most interesting parts of the experiment. I was contributing information the software did not have, and that information influenced its next action.

Carrying experience into the next job

The feedback was also retained for future use.

The system keeps context about which cutter is being used, the type of cut and my observations about chatter or noise. When it generates subsequent CAM profiles, it uses that information.

That gives it a way to carry experience from one job into the next. I do not have to explain the same observation from the beginning each time.

I describe this as learning from operator feedback. Establishing how much it improves the machining will require more than seeing a different set of parameters in the next profile. I will need to compare the results of subsequent cuts.

There is a useful distinction here. Remembering an observation and acting on it is a capability we have built into the workflow. Demonstrating that those changes consistently produce better results is the next test.

What two days actually demonstrated

I could present this as replacing expensive software in a weekend, but that would overstate what happened.

We used existing capabilities, including FreeCAD and the machine’s controller. The custom application addressed a narrow need. We have not reproduced the breadth, testing or support of an established commercial product.

Nor do I have a measured comparison showing how long the same work would have taken without generative AI.

What I can describe is the sequence I experienced. In less than two days, I went from learning how to prepare a first CNC job to using a connected workflow that helped with design, generated machining instructions and communicated with the machine. When the workflow became awkward, we could change the software supporting it.

For a hands-on developer learning a new area, that shortened the distance between a question and something I could try. It also let me spend more of the experiment working through the actual machining problem.

Giving the system more information

The next experiment is to explore cameras and a microphone, potentially using a Raspberry Pi to replace the laptop.

At present, I interpret what I see and hear and explain it to Claude. I want to investigate whether direct visual and audio input could help the system identify conditions such as chatter and support better decisions about cutting parameters.

Recognising an unusual sound is different from reliably diagnosing its cause, and both are different from deciding that an automatic adjustment is safe.

What I am taking back to my professional work

This started as a project for our workshop and a bit of an R&D exercise, but it connects closely to the work I do at EQUIAVIA.

The useful progress depended on context. Claude needed information about the machine and tooling. It needed feedback from someone who could observe the physical result. I needed to question its recommendations and decide what evidence would justify the next step. It needed to understand what it can't do, and I needed to decide what I would allow it to do. 

I see a similar requirement when organisations introduce AI into their own workflows. Giving an agent access to a tool is only part of the work. It also needs relevant information, a defined scope of action and a way for people to assess the outcome. It also needs guardrails.

This experiment made that tangible for me. AI helped me learn a new process and build the software needed to work through it. My experience as a developer helped me question the implementation, while being new to CNC machining kept the gaps in my knowledge visible.

I now have a working prototype and a clearer set of things to test. The next measure of progress is whether the experience we capture produces better, repeatable results.