That’s interesting… there are no g-code simulators out there that can handle the stuff the Heidenhain controller from 1989 can do. CNC Machining is really behind on the open source software side. There’s so much more for 3D printing, but even there is so much more potential. I never understood how you would want to do NC programming by hand, but with those controllers it’s so much easier than with the stuff we have as opensource.
@dunkelstern Do you mean that gcode interpreters we use don't support instructions that that controller did, and that were useful for hand-writing gcode? If not, I'd appreciate a more verbose version.
@robryk there are some things like automatic chamfering (just define the contour and add G24 R<radius> after the edge) automatic rounding works similar. Furthermore there are commands for tangential circles, repetitions, user parameters and calculation on those parameters (for example for cutting in multiple passes) then canned cycles like peck drilling, tapping or clearing a contour in multiple passes, spiralling cuts, entering and exiting cuts on a circular path.
@dunkelstern I'm not surprised that's not supported TBH. If controllers support such high-level commands, you end up with multiple codebases (or multiple different implementations of floating point underneath) trying to do the same thing, so much more opportunity for translation bugs (esp. if the computation of position after a command was not trivial from the command's arguments).
Would you want controllers to have that support, or to have _a_ language that has all those higher-level constructs that can be compiled down to g-code?
@robryk i mean by any means today use a cam package (of which there are basically none open source) and use a controller that can handle the load of micro instructions adaptive clearing produces, but it’s really interesting what commercial tools from 30 years ago could do with that hardware. I do not think the thing even has floating point hardware. It runs on 64KB of Ram if I am not mistaken. Most of the “extensions” the controller has have no direct effect on positioning
@dunkelstern I don't get how repetitions or calculations have no effect on positioning. If you simulate them inaccurately, you'll end up in a different final position than you'd otherwise, no? Then, given that the usual gcode I've seen contained mostly (only?) relative movement commands, such errors would be applied additively to the rest of the program. Do I misunderstand some part?
@robryk yes and no. I mean the machine is not able to position better than a micron (self built machines anyway) so if you would calculate fixed point or with a magnitude higher accuracy you’d have to run very long programs to accumulate an error big enough to matter. You’d have other problems like tool wear and thermal problems that will amount to bigger errors. From the software perspective you could do “perfect” but then there’s physics which has its own mind
@dunkelstern I am thinking of (a) numerically unstable implementations (which, in some parameter regions, amplify floating point inaccuracies ~arbitrarily much) or (b) slightly buggy implementations, rather than simply floating point inaccuracy adding up.
@robryk i do not think gcode is even the thing we should do today. But i did not find anything better that’s even on the level that old stuff from 1989 was on, and that’s the thing. I think we surpassed everything Stratasys did with their 3D printers some years ago, but CNC is not that far yet.
@dunkelstern Hm~ I wonder how related what you want here is from a missing format I see in 3d printing: there we have either shape description (STL or one of the ones based on parametric surfaces), or toolpath description (basically gcode). There's no format that would allow one to specify a shape, with tolerances (e.g. "this surface can be arbitrary as long as it stays between these two provided surfaces") and with printing expectations (e.g. "this has to be at least two extrusions wide"). Currently that lack causes people to have to reverse-engineer e.g. what thickness of a wall will cause it to be formed out of 2 circumferences without a space between them (e.g. from the POV of mechanical strength, width of 2.5 seems worst, because it creates a weird print with a somewhat wider gap between the two lines of extrusion), or what is the shape of an unimportant surface that causes the object to be printable without supports.
@robryk absolutely. That’s what i mean with even with the advances in 3d printing we have lots of untapped potential here. Bad thing is that the current approach leads to “works for me”-models that could be non-reproducible on other machines. There are new ideas with signed distance fields/functions which can describe things better but the design approach is node based and basically non-visual until you render the object,which is a problem (and it’s slow and besides rendering there’s no tooling)