search

gnea / grbl

An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on a straight Arduino
https://github.com/gnea/grbl/wiki
Other
4.07k stars 1.61k forks source link

Question about rotational axes and arc commands #482

Open winder opened 6 years ago

winder commented 6 years ago

I know GRBL does not support these right now, but I'm hoping someone here might know the answer. I'm trying to understand what motions are supported by the gcode specification in conjunction with the ABC rotational axes. Specifically I'm trying to create a visualizer for gcode including ABC axes.

To begin with it seems that an arc type motion in the ZA plane, for example, could be useful as a sort of "ease-in" for the rotational axis. But there doesn't seem to be a ZA plane in the specification. Not only does that plane not exist, but the spec goes on to further limit things by stating the UV, WU and VW planes do not support arcs. Is it true, then, that arcs are only supported on cartesian coordinates?

That seems to be the case, but I'm hoping someone with more experience can verify that this simplification is correct. If so, is it true that to visualize an arc would be similar to the case of helical motions? Meaning, for a helix operation the arc is interpolated across a linear axis depending on the current plane. Would I simply interpolate the arc across the rotation? Logically it seems like that would make sense, but I'm not sure if that is the only case which needs to be handled.

Thanks!

aldenhart commented 6 years ago

Interesting question. There is no mixed linear / rotational "plane" specified in Gcode - only XY, XZ and YZ. That said, the NIST Gcode spec provides some guidance on mixing linear and rotational axes here:

2.1.2.5 Feed Rate The rate at which the controlled point or the axes move is nominally a steady rate which may be set by the user. In the Interpreter, the interpretation of the feed rate is as follows unless inverse time feed rate mode is being used in the RS274/NGC view (see Section 3.5.19). The canonical machining functions view of feed rate, as described in Section 4.3.5.1, has conditions under which the set feed rate is applied differently, but none of these is used in the Interpreter. A. For motion involving one or more of the X, Y, and Z axes (with or without simultaneous rotational axis motion), the feed rate means length units per minute along the programmed XYZ path, as if the rotational axes were not moving. B. For motion of one rotational axis with X, Y, and Z axes not moving, the feed rate means degrees per minute rotation of the rotational axis. C. For motion of two or three rotational axes with X, Y, and Z axes not moving, the rate is applied as follows. Let dA, dB, and dC be the angles in degrees through which the A, B, and C axes, respectively, must move. Let D = . Conceptually, D is a measure of total angular motion, using the usual Euclidean metric. Let T be the amount of time required to move through D degrees at the current feed rate in degrees per minute. The rotational axes should be moved in coordinated linear motion so that the elapsed time from the start to the end of the motion is T plus any time required for acceleration or deceleration.

In other words, if you have a combined linear and a rotational move, make the linear move set the timing and the rotation completes in the same time. But what about the units? It's possible to convert the rotational units to linear if you provide a radius. Then N linear dimensions (mm, inches) equals M degrees.

I'm interest to know how you resolve this.

winder commented 6 years ago

Thanks that's some great information. The speeds during mixed motions sound tricky to calculate, but I think since I'm just trying to visualize the cutting location I can make some simplifications. The key takeaway for me is this: "the linear move sets the timing and the rotation completes in the same time".

For visualizing helix operations with arcs I was already able to do precisely the same thing. Basically, calculate the arc as usual by breaking it into N line segments, then for each line segment adjust the third axis (usually Z) evenly between each segment.

It sounds like I can use the same strategy for rotary motions by calculating the line segments in the XYZ space as usual then sweeping them across the axis of rotation. The only tricky part is that since the points for all axes still must be translated into XYZ coordinates for 3D rendering, those coordinate will no longer correspond to the work location.