Feature request: minimum feed distance (max gcode rate)

pmc · November 21, 2020, 12:12am

Low priority. Just thinking.

The problem

sending a gcode to a machine controller takes finite time (e.g. ~2msec for G1 Xnn.nnnn Ynn.nnnn over a 115.2kbps serial link)
for a given feed rate, moving a very short distance takes very little time
the time to move a short distance can be less than the time to send the next gcode
in a sequence of many very short moves, a controller may not receive gcodes fast enough to keep acceleration planning ahead of the machine in motion
in that case, the controller must plan decelerating moves to stop at the last available endpoint
feed stops
for long sequences of many tiny moves, machine feed may stop and continue by alternating small bits of motion and delays for the time required to receive & process the long sequence of many gcodes
recurring sequences (e.g. by layer) can significantly increase the running time of an operation

Current code

KM already has a static threshold:

GridSpace/grid-apps/blob/a2a75dc5f7d30a48bd3510ccf45180b283e3812d/src/mode/cam/prepare.js#L230-L240


// measure deltas to last point in XY and Z
let deltaXY = lastPoint.distTo2D(point),
    deltaZ = point.z - lastPoint.z,
    absDeltaZ = Math.abs(deltaZ),
    isMove = !cut;

// drop points too close together
if (deltaXY < 0.001 && point.z === lastPoint.z) {
    console.trace(["drop dup",lastPoint,point]);
    return;
}

If I understand correctly, this will not emit g1 codes for very close points until it gets to a point which is far enough from the endpoint of the last emitted g1 code.

Suggesting

Make “far enough” a tunable parameter
For UI, an intuitively meaningful parameter could be
- maximum rate of gcodes/second instead of minimum distance/move – compute “far enough” from (feed rate)/(gcode rate)
- speed of link to machine controller (gcode consumer) – compute “far enough” from (feed rate)/((link speed/nominal size of a g1 code))
Always emit a g1 feed to the exact last point before a g0 move (i.e. before disengaging tool from work)

stewart · November 21, 2020, 12:40am

The 3D printing code already does something like this because it’s a common problem there. One wrinkle in this is keeping straight lines straight. The danger is dropping close points around a curve going into a very long straight section. You never want to drop the point just before that long segment. This code doesn’t yet account for that case. But I can add it to the todo list so that parameterizing this can make sense.