GPU-native CAM
Fully automated.

A new CAM kernel designed for 3+2 milling, with as little per-part clicking as we can manage.

Our test setup is intended to represent the median machine and tooling library available. Paths are evaluated on a Haas VF2SS in aluminum, with the following defaults:

• Twist drills 0.030" - 0.500"
• 142 degree spot-drill 0.5"
• 90 degree edge-break 0.375"
• Solid carbide square end mills 0.125", 0.250", 0.500"
• Kurt DX6 Vise with 0.1875" parallels

We skipped larger end-mills from the default load-out as the cost-per-tool goes up, although the system works just fine with larger tools and the user can add them. We also skipped "shell mill" insert facing cutters from the defaults although we may expose them back to the user.

This is a beta: users should be very careful. You should look at EVERY path in our simulator, and run your own independent simulation if you have one.

We run on a relatively large test corpus, and produce reasonable parts the large majority of the time. But there's a reason we're in beta and parts with out-of-scope features are likely to surface bugs and issues.

At a technical level, our path generation pipeline has three distinct layers of geometry protection intended to provide a high ceiling for machine protection eventually. Those layers are: correct-by-construction regions from the GPU, material-aware linking, and a final-path simulator.

Our simulator runs both headless in our cloud and in-browser using WebGPU compute shaders. The simulator uses an entirely independent and extremely simple calculation strategy: the path is sampled, and each voxel gets marked by the first sample to remove it, all on the GPU. This is designed to be essentially impossible for a pathing system to "cheat on" and is designed to catch all classes of errors, particularly useful for cases we haven't thought about.

System validation is a complicated topic and a long road. Our near-term goal is to make it impossible to use our system and "click wrong" in a way that induces a machine crash like current CAM systems allow you to do. Our long-term goal is to eliminate the CAM step entirely, build machines that are validated at the factory once, accept 3D models and stock, and never commit spindle-suicide on a random Tuesday by running NullCAM as a kernel inside the machine.

We have a physical test program that validates our paths on median hardware (described above, Haas VF2SS), and results have been good on samples. Our general development philosophy is that our paths have to look perfect in simulation before we run them, as they are not going to magically improve on the machine. Our anecdotal experience from our test program is that a commodity milling machine like a VF2 is rigid enough that what we would consider "major problems" are eaten by the rigidity and power and produce "pretty good" parts. Without any "tricks" we have been regularly emitting 0.002" bilateral-class parts, and with simple cutter compensation we have done better. Although it is very likely we have overfit to our sample parts.

The future of manufacturing machined parts has been pretty clear since the 1970s: data in, part out. The current state of the world with email, CAM systems, machine controllers with keyboards, human-in-the-loop validation, out-of-process QA, is a local minimum.

Mass production of high-end machining is already largely lights-out. Systems like NullCAM are intended to make mass-production automation possible for one-off jobs. With 100% planning automation it enables new classes of machine which load stock, start cutting, inspect, and ship parts within minutes of ordering.

The dream of 3D printing was that an engineer presses a button, robots produce the part with lead times on the order of minutes, delivered at a price that is within 10% of the material cost. 3D printing is a niche process due to speed and material properties: but we think that workflow is near-term achievable for many classes of machining.

It's also pretty clear that "partial automation" and "full automation" are different problems. We think "automate a little bit of the flow in an existing CAM system" is a dead end.

The toolpathing (f(model) -> part), suitability (i.e. "is this part a potato"), fidelity ("does our path produce the part"), accuracy ("did we cut a clean superset of the part"), and safety ("did the sampled path cut cleanly with no collision") computations are all classical geometry implemented on a GPU in relatively principled ways. These were done by hand before the advent of working AI, although edge cases have been massively refined by our test corpus mapping simulation errors on parts to agents. CAD/CAM is essentially all edge cases, and doing this even to the current beta state without an agent-loop would have taken us hundreds of lifetimes.

NullCAM is not using a transformer architecture internally in the live analysis. We think it's important to only use them in stages that classical algorithms haven't solved. Particularly of interest are the operation pruning, free surface roughing, and probe-offset loops.

A lot of "AI CAM" out there is what we would call "setup heuristics": i.e. which operations are needed to make a part, which is a relatively small part of the overall problem.

No. We do not use any licensed technology, and we contribute heavily to open source projects in the space. Our pipeline is entirely new technology built on an open source core. A common solution for this type of system is a backend that is a "Solidworks plugin running in the closet with a REST server," licensed Parasolid, or as a plugin that requires a heavyweight parent program to do the actual work of generating paths and handling geometry inputs.

Our feeling is that it's quite important to treat this as an end-to-end problem with full control of the geometry and path logic, and "helpers" for manual CAM are not the best way to approach it.

We hope to keep it indefinitely, but we can't reasonably promise anything.

Cloudflare and Tailscale both have generous free tiers because they built efficient systems from first principles that are not exorbitantly expensive to run. That quality of engineering doesn't really exist in the CAD/CAM space, which is often a triple-licensed soup of Parasolid, loose Windows virtual machines, etc. We don't license technology, and we spent a long time staring at profilers to get pathing on our target geometries under a second.

Our intention is to keep a fixed size free tier instance pool. This should cover a lot of use given that decent hardware can easily process hundreds of thousands of files per day, and the Google Cloud Platform GPU instances we use for market reasons can process maybe 20% of that. Free tier already runs at the lowest queue priority, and if it's a problem we can run free jobs at a lower resolution and lower runtime cap to reduce our cost to deliver.

We know software post-AI is like sand on a beach. The value in a system like this is simulation time, validation, and physical testing. The goal behind the engineering is to work towards "first run is as safe as a proven program" which is the bare minimum requirement for automation, and what we intend the end of our beta to represent. We think cells and machines should be validated once, and running a new part should never represent danger. Our ideal deployment is inside a machine tool and the CAM with a user-interface is largely just a cosmetic demo for us.

Our target is 1 second end-to-end, which we largely achieve on median parts. Analysis complexity scales with the number of operations. Our long-tail is still mostly under 5s, although we're sure you can break that if you try. Algorithms are implemented in Rust and compute shaders, and work is prepared using Python as a DSL, much like pytorch (but not pytorch or cuda).

The default cloud instance runs with an Nvidia L4 which is not a frontier card by any means. We don't have a lot of flexibility in cloud instances as the major providers decide what to allocate. An RTX PRO 6000 Blackwell 96GB can do the same analysis in approximately a fourth the time at much higher resolution. As the GPU market stabilizes over the next few years we may be able to allocate better instances.

This is designed for pocket and hole parts cut from multiple discrete directions: N*2.5D.

We produce helix plunge trochoid paths with inwards-spiraling exteriors.

If pockets have square corners it will output rounded corners at the minimum radius. For free-form surfaces it will output a "near-net" program with quantized levels, i.e. "stepped" or "terraced," around the free-form surface. Chamfers and fillets in the model are not likely to do anything useful. If you want every sharp corner uniformly chamfered you can increase the edge_break setting which is the perpendicular distance it runs the 90 degree conical tool along sharp corners for deburring. The default distance is 0.002" but can be increased if you want to make everything chamfered.

Our output is designed to always be a superset of the final part so it can serve as a blanking operation even if we can't handle a particular feature.

If you don't configure anything, it uses our default load-out described above. It's also the best place to start for new machines. You can configure you machine with a tool library with specific sizes and parameter tables for square end mills, ball end mills (disabled by default), and drills. The backend will generate candidate operations for every tool, and then volumetrically cull the list to only include ones that remove material with a bias towards the largest tools.

The selection of tools is per-job and is a subset of the available ones. The G-code includes the stickout information as a comment, as well as the Z range a tool is expected to traverse in that particular file.

The pipeline currently uses a heuristic for generating clamped fixture solutions, and will collision-avoid the vise overlap estimated at the bottom in addition to the bottom plane representing the table. We're working on additional fixture solutions for different geometries that are less amenable to a vise.

Our paths are defined in an internal but not proprietary MillPlan format that contains all relevant information, and G-code is an export. Our exporter tries to use a simple, widely supported subset of codes. We can tune the exporter for various controllers, which may be necessary when we add more advanced behavior that requires logic execution, like probing.

If you change the material in the request, it will apply the values set in the machine table, which you can customize. You can also edit them in the simulator, which will recompute the acceleration-limited cycle time live to make it easy to review, and the export g-code from the simulator will apply the edits.

And failing all of that, in G-code exports they are all at the top of the file and you can just edit them with a text editor.

For a part, we produce candidate tool planes, and produce "operations" which consist of a tool plane, a tool, and settings. There are len(planes) * len(tools) candidate operations for every part. Most of these operations are subsumed by larger tools, or ill-fitted. Our volumetric pipeline runs once to see "does this operation actually cut anything," we then prune the useless ones, and then run the final volumetric analysis and toolpathing.

In short: maximal aggression produces 1 operation (the best one), minimal aggression does no pruning and outputs everything, and the default setting removes ones that mostly don't cut anything using a bag of signals (volume, normals, etc) produced on the GPU and decided by a heuristic that we tuned from our sample data to maximize fidelity and minimize cycle time.

Our pipeline uses collision geometry as a core part of the path construction. The tool is convolved against the part including collision geometry on GPU so that the regions it outputs exclude anything that would be in collision. That being said "collision free in simulation" is NOT the same as collision free, and you should always be careful.

The most likely source of error is that our default collision geometry is not conservative for your machine, although there are other classes of bugs as well. If you review the path in our simulator, look at where the segments lie for each operation plane and do a quick sanity check before running.

Parts of our pipeline operate in pixel and voxel space, which can bring to mind jagged aliasing. The short story is raster space is only used for roughing and we always stay more than a cell diagonal away from the surface.

The cutting curves we produce are continuous arc and line primitives that are positioned and sized by the discrete signed distance field, it isn't a naive raster solution.

Finish paths and drill operations are computed from the exact analytical surface so for simple cylinder-plane parts we should be outputting exactly correct finish results.

The main compromise with the raster signed distance field approach is that the smallest feature we can resolve is a function of this resolution. So if we have to turn down resolution for our free tier the main place you would see it is with small pockets going uncut, but we always "fail closed" i.e. we never remove material incorrectly — we just will not include a feature in our plan if that happens.

No. A VMC and a dream supports doing almost anything, but we are focused on fully end-to-end automating simple parts first and then moving up to advanced features.

No. The simulator is calculated at a much lower resolution than the generation and it is computed in the simplest way possible so as to reliably catch bugs in the path generation logic.

Toolpath generation is a two stage geometry problem: volume-removal (i.e. clearing or roughing), and surface-touching (i.e. finishing). Volume clearing is the much more difficult problem, and it's where the bulk of the analysis work is. The short story is roughing is computed at high resolution in 2.5D where the finish allowance is larger than one pixel. The finishing curves are computed directly from the analytical surface.

The simulator runs in-browser via WebAssembly and WebGPU, which requires a very modern browser. We do not support older browser rendering pipelines like WebGL as the simulator runs the simulation client-side in a compute shader which WebGL does not support. The simulator builds for desktop are roughly 50% more performant, which we may release at some point if it makes sense.