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.
reply`M98` allows for essentially function calls (nested or not.)
replyIf 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)
_If_ one is using a firmware which supports that.
replyGrbl, which many of the 3D printer firmwares are based on, does not (and no variables, or loops, or branching).
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.
replySo suppose I attached an extruder to a Haas mill or something...
It's fascinating how revered people are who talk in metaphor and implication like this about relatively simple things, when far more complicated things are happening all the time inside their devices.
replyIronically, I don't know if you are referring to the article, the comment you are responding to, or the world in general.
replyG-code by itself only describes the series of motor movements over time, though I think it would be practically feasible to have a book contain an executable script, which would generate the same g-code as the one used to print the book. It would be really interesting to see how large the resulting book is.
reply"This prompt, when fed to a sufficiently capable LLM, will generate the G-code to produce a 3D printed model of a book containing this quote, verbatim, in raised letters."
reply"Some percentage of the time."
replyCompression could be interesting
reply