# Feature request: minimum feed distance (max gcode rate)

**URL:** <https://forum.grid.space/t/feature-request-minimum-feed-distance-max-gcode-rate/146>\
**Category:** CAM\
**Created:** [November 21, 2020, 12:12am UTC](https://forum.grid.space/t/feature-request-minimum-feed-distance-max-gcode-rate/146 "2020-11-21T00:12:39Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![pmc](https://forum.grid.space/letter_avatar_proxy/v4/letter/p/e9c0ed/32.png) [@pmc](https://forum.grid.space/u/pmc)\
**Post date:** [November 21, 2020, 12:12am UTC](https://forum.grid.space/t/feature-request-minimum-feed-distance-max-gcode-rate/146/1 "2020-11-21T00:12:39Z")

</div>

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:

> <https://github.com/GridSpace/grid-apps/blob/a2a75dc5f7d30a48bd3510ccf45180b283e3812d/src/mode/cam/prepare.js#L230-L240>

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)

---

<div class="post-metadata">

**Author:** ![stewart](https://forum.grid.space/user_avatar/forum.grid.space/stewart/32/21_2.png) [@stewart](https://forum.grid.space/u/stewart)\
**Post date:** [November 21, 2020, 12:40am UTC](https://forum.grid.space/t/feature-request-minimum-feed-distance-max-gcode-rate/146/2 "2020-11-21T00:40:55Z")

</div>

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.