fullcontrol: designing the print path in Python instead of slicing it

The slice step is the thing it replaces

The README describes the conventional way of generating gcode as a chain: create a CAD model, export an STL, slice it into layers, create paths for each layer, and output the path as gcode. FullControl offers a different approach in which the print path is explicitly designed.

The analogy the README uses is a hotmelt glue gun and being told to move it around to print layers resulting in a 30 mm cube. There are many different paths that would produce that cube, and the point of the library is that you choose the path, not a slicer.

That is the whole difference in one sentence, and it has consequences in both directions. You lose the convenience of the model-and-slice workflow, and the model no longer exists as an intermediate artefact. You gain the ability to do things a slicer has no concept of, because a slicer starts from a solid and a layer decomposition, and anything that is not a per-layer path of a solid is outside its vocabulary.

The library describes itself as allowing you to control 3D printers, or other CNC systems, in ways that are not possible using conventional software, and it lets you design everything about the print path and the print settings. The first release is focused on extrusion 3D printers instructed by gcode, but the README is explicit that things could be anything: laser cutters, assembly lines, or non-physical things such as a 3D visualisation.

State is the unit of design

The conceptual core of the library is the idea of state. The README says the overall printing procedure may be considered to be predominantly a stream of points, with a few extra things sprinkled in occasionally, such as changes to speed, temperature and fans. All of those things together, the points and the extras, are referred to as state, and state is basically any property of interest that can change.

This is a better mental model than a toolpath file, and it is worth spelling out why. A gcode file is a sequence of commands, and the state at any point is implicit in the history of those commands. Design a path in that model and you are constantly reasoning about what the machine's state happens to be at line 400, and a change to the design invalidates the reasoning. Design a state stream instead and the state is explicit at every step, which makes a path like a spiral or a variable-width extrusion expressible rather than something you have to fake with layer tricks.

The library allows designs to be created that control changes in the state of things, where things are anything with state. That generalisation is why the same code could drive a laser cutter or a visualisation, and it is the reason to read the library as a state machine rather than as a slicer replacement.

Three generations, from an Excel interface to notebooks

The README tells the project's history in three steps, and the progression explains the current design better than any feature list.

The FullControl gcode designer of 2020 had users generate gcode by directly designing geometric features and custom gcode features. The user interface was Microsoft Excel, the algorithms were written in Visual Basic, and the gcode was previewed in other software such as Repetier Host. It targeted researchers and people experimenting with printers and other gcode-based hardware who needed to explicitly design print paths with full control.

The www.fullcontrol.xyz site of 2022 went the other way. Users generated and downloaded gcode parametrically for pre-created designs directly from a website, with no need for experience of printing, gcode, CAD, toolpath design or Python. The demo models were created with the Python implementation of FullControl, which is this repository.

FullControl as it stands, from 2023, is that repository: users design, preview and export gcode for custom print paths for extrusion 3D printing, all in a Python environment, and designs are Python scripts or Jupyter notebooks. The initial release in March 2023 was a gcode-focused implementation of the broader FullControl concept of designing changes in the state of things.

So the project has been through a spreadsheet, a website and now a library, and the current form is the one aimed at people who are comfortable writing Python, which is a much smaller audience than the website served.

Getting started in Colab, or installing from git

The README leads with the option that requires no installation at all. Go through the interactive tutorial notebooks in Colab, then use the design template, and the tutorials are also browsable in the repository, with a one-minute demo among them.

The advice for people new to Python is blunt: don't install, just use the Colab design template and get designing straight away online. For a local setup the instruction is to install miniconda, anaconda or Python along with git, and if installation problems appear, update the versions of Python, git and pip.

The install itself is a pip install from the git repository:

pip install git+https://github.com/FullControlXYZ/fullcontrol

or you can clone the repository and run pip install . from the repo directory. Using the package is a single import:

import fullcontrol as fc

The alias is the house style, and the tutorials and models all use it, so recognising fc in an example tells you what you are looking at. Note the version requirement in the project metadata, which is Python 3.10 or newer, and the dependency set, which is plotly, pydantic and numpy, a small and unremarkable list that a notebook environment will already have.

The lab package and the route from gist to core

The repository is organised so that the stable package, the experimental package and the examples are separate. The fullcontrol directory is the Python package itself, models holds example models that use FullControl, lab is the FullControl lab package for experimental features, tutorials holds the Jupyter notebooks that describe and demonstrate the library, and bin holds scripts for development activities.

The workflow for new content is written down and is worth copying, because it explains the split. The anticipated path is to demonstrate new ideas with GitHub gists, quick and dirty, then have the gists inform additions to the FullControl lab, a little more polished, and then have the lab inform additions to the main fullcontrol package or the models subdirectory. So anything experimental starts outside the package and graduates through the lab, and the lab is where the boundaries of the stable API are tested.

The packaging reflects that. The wheel target includes both the fullcontrol and lab packages, and the project metadata points to the fullcontrol.xyz site, the repository, the documentation directory, the tutorials and the issue tracker. There is also a tests/ directory, a docs/ directory, a roadmap.md, an llm_ref.md, which suggests some machine-readable reference for language models, and a SECURITY.md.

Where FullControl is the wrong tool

The first wrong-tool case is the ordinary case. If you have a CAD model and you want a printed part, a slicer is the right tool, and FullControl means reimplementing the layer generation, the path planning and the machine handling that a slicer already does for you. The library assumes you want to design paths a slicer cannot express, and if that is not your situation, it is a lot of work for nothing.

The second is a production or team workflow. A design here is a Python script or a notebook, which is excellent for exploration and for a researcher who wants to publish the exact path they used. It is less good for a pipeline where a hundred parts are produced from parameterised models, since there is no productisation story in the README, no service, and no queue. The 2022 website was the answer to that need and it is a different artefact from this library.

The third is a project that needs a stable API to build on. The version is 0.1.2 and the release history is slow, with 0.1.0 in June 2023, 0.1.1 in February 2024 and 0.1.2 in September 2025. The library is pre-1.0 and its API is evidently still moving, and a company writing a production pipeline on top of it is taking on that risk.

GPL-3.0, version 0.1.2 and an active but unhurried repository

The package is licensed GPL-3.0, with the licence file at the repository root and the classifier in the project metadata naming the GNU General Public License v3. For a tool whose users write their own designs on top of it, that is worth understanding: the library carries copyleft obligations, while the scripts and notebooks you write are your own work.

The version history tells the story of a small project with a long leash. v0.1.0 was released on 2023-06-08, v0.1.1 on 2024-02-27 and v0.1.2 on 2025-09-11. The repository is not archived, and the last push was on 2026-10-09, so work continues between releases, and the presence of a roadmap.md and of the lab package suggests that the development continues in the open.

The people behind it are named in the package metadata, Andy Gleadall and Dirk Leas, with fullcontrol.xyz as the project homepage, and the README notes that the demo models on that site were created with this Python implementation. The library also carries a plotly dependency, which fits the preview story, since the point of designing a path is to look at it before committing it to a printer, and the README describes designs as being previewed as well as exported.

Editorial conclusion

Adopt fullcontrol if you are the kind of user who wants to decide exactly what the machine does, for example to print with an unusual geometry, to use a printer as a deposition tool for something other than a plastic part, or to experiment with a hybrid or non-planar path that a slicer cannot express. Do not adopt it if you want to turn a CAD model into a finished part, because you would be reimplementing the slicer, and do not adopt it if you need a maintained library with a stable API, since the version line is 0.1.x and the release history is slow. Before you install, start in Colab with the design template so that nothing is installed, read the tutorials in order, and check the GPL-3.0 licence in the repository, since the code you write with the library is your own but the library itself carries copyleft terms.

Frequently asked questions

Official sources

1. FullControlXYZ/fullcontrol on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases