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 the controller can even simulate the part in a 3 dimensional view (this is on a monochrome screen with hardware from the mid 80ies, so wow…)
@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 yes of course bugs are bugs. In the manual to the heidenhain controller are many caveats as well. For example: you can not do more than 15 rotations in incremental polar mode, you have to have an absolute move in between. Furthermore program length is capped at 1000 instructions and you can have only 32 programs. Local stack size is 8 and global inter program stack size is 4, etc. but this is with basically a C64 of hardware. Even arduino should be more capable.
@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)
@robryk it just takes a lot of mental load away from the programmer. For example G2/3 circles are a pain because you need the center point. A tangential circle that is used in so many designs that has a defined start and endpoint does not need that, as it is completely constrained by being tangential. There are codes for just “use same curve direction as last command” and support for polar coordinates. Bolt circle? Use polar coordinates and incremental measuring: 1 move, 1 drill command per hole
@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.