9
$\begingroup$

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?

Improve this question
$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – nanofarad
    Jan 14, 2016 at 0:27

1 Answer 1

Reset to default
8
$\begingroup$

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().

Improve this answer
$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .