<p>Marlin does allow one to change the size of the buffers, in <code>Configuration_adv.h</code>. In the current version there's an ifdef that switches between two cases, one with SD support, and the other without. Both have a movement planner of size 16, which can be adjusted.</p>

<p>Additionally, in the same file, <code>BUFSIZE</code> can be changed to modify the size of the buffer storing <em>unparsed</em> commands before they are parsed and enter the movement planner buffer.</p>

<p>Additionally, for some firmwares, <code>M112</code> will immediately shut down the printer, no matter what is in the buffer, but the reset button will need to be used, and the axes will not be homed afterward. In Marlin, it's hardcoded to call <code>kill()</code>.</p>

CC BY-SA 3.0
2016-01-13T23:39:51.063Z
2016-01-14T16:28:26.077Z
2016-01-14T16:28:26.077Z
nanofarad
<p>I am reconfiguring a Printrbot Simple Metal that has been retrofitted with a RAMPS+Arduino Mega running Marlin, with a fairly slow feedrate due to mechanical and quality limitations.</p>

<p>I am finding that upon cancelling a print where something goes wrong, I have a long period of time in which the printer is continuing to print from the G-code and movement buffer, although the host software (Octoprint) has long stopped sending G-code.</p>

<p>Is there a way I can either a) configure Marlin to have a smaller print buffer (since Octoprint has no trouble keeping up with the printer as it stands) or b) send a particular signal or G-code to the printer that stops it without continuing to read buffer contents?</p>

CC BY-SA 3.0
2016-01-14T00:27:58.683Z
Matt: Thanks for the edit suggestion. I rejected it for now since this question isn't Printrbot-specific. It is applicable to almost any Marlin-based printer, that happened to be a Printrbot in this case. If you still feel it's a necessary tag, please resubmit the edit and I'll approve it, or let me know by comment.
nanofarad
<g-code><firmware><marlin>
How do I set the G-code buffer size on Marlin?
nanofarad
# How do I set the G-code buffer size on Marlin?

(Asked by: username_0 on 2016-01-13)

I am reconfiguring a Printrbot Simple Metal that has been retrofitted with a RAMPS+Arduino Mega running Marlin, with a fairly slow feedrate due to mechanical and quality limitations.

I am finding that upon cancelling a print where something goes wrong, I have a long period of time in which the printer is continuing to print from the G-code and movement buffer, although the host software (Octoprint) has long stopped sending G-code.

Is there a way I can either a) configure Marlin to have a smaller print buffer (since Octoprint has no trouble keeping up with the printer as it stands) or b) send a particular signal or G-code to the printer that stops it without continuing to read buffer contents?

**Tags:** g-code, firmware, marlin
> **Comments:**
> **username_0**: Matt: Thanks for the edit suggestion. I rejected it for now since this question isn't Printrbot-specific. It is applicable to almost any Marlin-based printer, that happened to be a Printrbot in this case. If you still feel it's a necessary tag, please resubmit the edit and I'll approve it, or let me know by comment.  

---

## 1 answers

### Answer by username_0 on 2016-01-13. Score: 9 | Accepted answer

Marlin does allow one to change the size of the buffers, in `Configuration_adv.h`. In the current version there's an ifdef that switches between two cases, one with SD support, and the other without. Both have a movement planner of size 16, which can be adjusted.

Additionally, in the same file, `BUFSIZE` can be changed to modify the size of the buffer storing *unparsed* commands before they are parsed and enter the movement planner buffer.

Additionally, for some firmwares, `M112` will immediately shut down the printer, no matter what is in the buffer, but the reset button will need to be used, and the axes will not be homed afterward. In Marlin, it's hardcoded to call `kill()`.


---

