No, Gcode is pretty primitive and simple. Each move/axis is independent. The moves don't translate or rotate the part, they translate/rotate the cutting point relative to the current part coordinate system. So an 'A' move effectively rotates the cutting tool around the X axis. In practice, of course, it might be rotating the part in a rotary device or a trunion table or some other device but the part's coordinate system hasn't changed.realthunder wrote:hmm... I have zero experience with any machine beyond XYZ. So, how does it work? ABC is supposed to be the surface normal, right? So if any ABC move is executed, is the following XYZ in the rotated space or not. How does Path handle this? And also, if the user machine has less axis, say only has A, is there any way to convert Gcode file containing ABC move? I think this is in the Path postprocess territory. I haven't looked at that yet.sliptonic wrote:Yes and no. The Path commands can handle additional axis of movement but the viewprovider ignores everything except XYZ.
The only qualification to this is how arc moves are handled. A gcode (G17/G18/G19) determines the plane and then any arc moves (G2/G3) that follow are calculated in that plane. G17 is the default so arcs are calculated in the XY plane. The other selection planes are almost never used these days but I mention it now since it does affect how gcode is processed.