gcode-lib — a stdlib-only Python library for G-code parsing, transforms, and analysis
None of the existing g-code libraries I discovered did what I need, are vendor specific or have been abandoned. So, I've been working on a Python library for manipulating G-code files and just published v1.2.1 on GitHub and PyPi. It covers everything from basic parsing to full post-processing pipelines for FDM printing. Later I'll be adding PrusaLink support. I've looked into PrusaConnect and it's currently "too hard".
What it does:
- Loads and saves both plain-text .gcode and Prusa binary .bgcode — format is auto-detected, saves are atomic (temp-file + rename)
- Parses every line into structured GCodeLine objects with commands, axis words, and comments
- Tracks modal state (G90/G91, M82/M83, G90.1/G91.1) line-by-line with advance_state and iter_with_state
- Arc linearization — converts G2/G3 to G1 segments with configurable chord length and sweep angle
- XY transforms — translate, skew, scale, rotate, or apply any arbitrary fn(x, y) → (x′, y′); also a translate_xy_allow_arcs that shifts without needing to linearize first
- G91 handling — to_absolute_xy() converts relative XY segments so any transform can safely operate on mixed-mode files
- Bed placement — find_oob_moves / max_oob_distance for boundary checking against any polygon; recenter_to_bed to center or scale-fit a print onto the bed in one call
- Layer iteration — iter_layers groups lines by Z height; apply_xy_transform_by_layer applies a transform only within a Z range
- Statistics and bounds — move/arc/travel/extrude/retract counts, total extrusion, unique Z heights and feedrates, XY/Z bounding box
- Transform analysis — analyze_xy_transform does a dry run and reports max displacement without touching the file
- Template rendering — substitutes {variables} in start/end G-code scripts while leaving PrusaSlicer conditionals ({if …}, {endif}) untouched
- Thumbnail encoding — generates PrusaSlicer-compatible thumbnail comment blocks from PNG bytes
- BGCode bytes API — read_bgcode / write_bgcode for in-memory/streaming workflows
- PrusaSlicer CLI helpers — discover the executable, probe capabilities, slice single models or batch-slice a folder of STLs in parallel
- Built-in presets for Prusa printers (COREONE, MK4, MK3S, MINI, XL) and common filaments (PLA, PETG, ASA, TPU, ABS)
A quick example:
pip install gcode-lib
import gcode_lib as gl
gf = gl.load("benchy.gcode")
stats = gl.compute_stats(gf.lines)
print(f"{stats.layer_count} layers, {stats.bounds.width:.1f}×{stats.bounds.height:.1f} mm")
# Shift the print 10 mm right — arc commands preserved, no linearization needed
gf.lines = gl.translate_xy_allow_arcs(gf.lines, dx=10.0, dy=0.0)
gl.save(gf, "benchy_shifted.gcode")
GitHub Source: https://github.com/hyiger/gcode-lib
PiPy Deployment: https://pypi.org/project/gcode-lib/
RE: gcode-lib — a stdlib-only Python library for G-code parsing, transforms, and analysis
Thanks, Claude 😁
See my GitHub and printables.com for some 3d stuff that you may like.
RE:
Thanks, Claude 😁
Meh... that or I would spend 2-3 months on it and lose interest (instead of 1 day)
RE: gcode-lib — a stdlib-only Python library for G-code parsing, transforms, and analysis
Thanks, Claude 😁
Meh... that or I would spend 2-3 months on it and lose interest (instead of 1 day)
All good as long as it's reasonably well-tested! 👍
With interpreted languages I am always somewhat nervous (whether it was myself or AI doing the coding). Besides the test cases, do you use some validator tool to check for inconsistencies, uninitialized variables and such?
RE: gcode-lib — a stdlib-only Python library for G-code parsing, transforms, and analysis
Thanks, Claude 😁
Meh... that or I would spend 2-3 months on it and lose interest (instead of 1 day)
All good as long as it's reasonably well-tested! 👍
With interpreted languages I am always somewhat nervous (whether it was myself or AI doing the coding). Besides the test cases, do you use some validator tool to check for inconsistencies, uninitialized variables and such?
There are 370 unit tests covering 100% of the code including edge cases. There is also a set integration tests that run on real data (rather than mocked). I've also done smoke tests with a variety of different test objects.
I had reservations about doing this with an AI. At first I only used it to generate tests and documents but then it would have taken me months to hand-tool bug free code at this level.
Also learned a lot in the process about how Prusa's undocumented binary g-code works.
RE: gcode-lib — a stdlib-only Python library for G-code parsing, transforms, and analysis
> All good as long as it's reasonably well-tested
Well, not always, the most important things are good prompts and inputs for the model. Anything else cna be generated nowadays. Either way I suggest reviewing the generated code.
At least the license does not allow to include it in any product except the SaaS 😋
See my GitHub and printables.com for some 3d stuff that you may like.
RE: gcode-lib — a stdlib-only Python library for G-code parsing, transforms, and analysis
My day job is Java/C++/Python/Matlab so I know something about coding and proper testing. Just don't have the spare time to do it the "old-fashioned" way anymore. The code has been thoroughly tested. It's not AI slop.
RE: gcode-lib — a stdlib-only Python library for G-code parsing, transforms, and analysis
Yeah, I noticed 🙂
See my GitHub and printables.com for some 3d stuff that you may like.
RE: gcode-lib — a stdlib-only Python library for G-code parsing, transforms, and analysis
There are 370 unit tests covering 100% of the code including edge cases. There is also a set integration tests that run on real data (rather than mocked). I've also done smoke tests with a variety of different test objects.
I assume the unit tests and integration tests were written by Claude as well? How is your experience (also beyond this specific project) with this approach -- does the AI sometimes overlook the same thing when writing the test cases as it had when writing the code? That same concern applies to human programmers as well, of course...
Not questioning your approach, just trying to get a better view to what extent I can and should trust AI here!
RE: gcode-lib — a stdlib-only Python library for G-code parsing, transforms, and analysis
AI is much better at writing unit tests than a human. At work, > 50% of the tests are garbage since writing tests is considered janitorial duty. Most human written tests are there just to get around automated code coverage requirements.
I reviewed the tests. Claude came up with edge cases I would have never (initially) considered. AI’s though won’t generate tests unless you specifically ask. And most non-developers probably would not have considered instructing the AI to create a comprehensive test suite. Or to run the tests before committing every code change.
I can see this though driving down wages since it will be propping up mediocre developers.