Pygdk Python G-code Development Kit


was mentioned at:


Wow, I didn’t expect it to include simulation as part of the workflow. That’s neat.

CAMotics is used for the simulation, but you could use any other G-code simulator you might wish.

Hey folks – let me know if you have thoughts or improvements for pygdk. My machines are sadly in storage at the moment, so I’m not driving a lot of my own features, but I’m happy to poke at it if others find it useful.

1 Like

Thanks, @cilynx! At work I have access to a couple of Haas VF2 machines, each with a 4th axis, a TL1, and a couple of Okuma mills from the 80s. They each have their own quirks about how they interpret g-code and the pygdk’s README mentions eventually having machine profiles. Is that something that’s high on the to-do list or a maybe, someday feature?

Machine profiles and controller flavors are implemented to some extent today. Right now machine profiles support mainly safety limits and accessory info and are documented here:

Controller flavors are a bit messier and are currently hard coded near the bottom of:

I have support for Buildbotics and OctoPrint today. In my world, controller flavor is mostly about how to send the g-code over the network – API endpoints, auth, etc. To add a new controller flavor, I’ll need to know how to talk to it over the network.

If you cut an issue on GitHub with a link to some relevant docs, I’m happy to put together a branch you can test on your machines.

I don’t currently support multiple g-code dialects, but it shouldn’t be too hard to implement and it should be a core feature. I’ve run into it a couple times myself as my mill and lathe expect GRBL while my printers expect RepRap.

I may poke at this this weekend for my limited use case as it’s easy to verify success looking at the g-code output. If you cut an issue with your machines’ dialects / quirks, I can look into getting them added as well. There are a few different ways this could be implemented, but I’ll push as much out to the config files as possible as I really don’t like having this sort of stuff hard coded.

I don’t know how long you’ve been using the name but you may want to prevent some confusion with GDK (The Gnome Developers Kit). I don’t know if it is still around but I used pygdk (python bindings to GDK) back in the day to write a simple video player. :slight_smile:


I had the same thought when I was originally pondering names, but so far as I can tell, folks are leaning much more towards “gtk” and “gobject” branding these days for widely used libraries with gdk itself being relegated to a low-level middleware that very few devs interact with.

That said, if my pygdk project ever gets popular enough that its name matters, I’ll happily hold a branding competition to come up with something more unique.