There's probably a way to make an xz file that decompresses to g-code for itself. But plain g-code is not powerful enough because it's just a list of movements due the tool head to perform - no computation.

▲

serf 2 hours ago | parent [-]

`M98` allows for essentially function calls (nested or not.)

If you had a part of a machine that could save state (say.. turning on a coolant pump..) I wonder how much more of a turing machine you could wrastle into it.

(or you could just cheat and use one of the hundreds of gcode variants that have computational stuff stapled into them like the Fanuc equivalents, but that's sorta dishonest for the exercise)

▲

WillAdams an hour ago | parent [-]

_If_ one is using a firmware which supports that.

Grbl, which many of the 3D printer firmwares are based on, does not (and no variables, or loops, or branching).

	▲	myself248 an hour ago \| parent [-]
		And weirdly, neither does Klipper, despite having all the resources in the world to do so. Just not a priority since slicers don't produce code like that, and 99.999% of Klipper's job is to eat whatever a slicer sends it. So suppose I attached an extruder to a Haas mill or something...