M201, M204, & Slic3r Geometry Dependant Acceleration Control

DocTrucker

Hi.

I am currently working on a gcode parser and I have noticed that Slic3r's approach to variable acceleration appears to be flawed.

Is it correct to say that M204 limits acceleration along a vector/move, rather than limiting the acceleration relative to the unique axis?

My settings in Slic3r are currently very conservative:

Acceleration control (advanced)
Perimeters: 800 mm/s2
Infill: 1000mm/s2
Bridge: 500mm/s2
First Layer: 500mm/s2
Default: 1000mm/s2

This appears to be being set very crudely in the job gcode file before each printing block as follows (before a block of printing G1 moves on the first layer):

M201 X500 Y500
M204 P500 T500

I'm surprised to see the M201 line in the code, as that is my maximum that I set in the configuration file, and I though it was safe to put whatever value I like in Slic3r and the configuration file values would stop anything from going crazy.

I'm assuming the M204 is limiting the acceleration of the end effector along the print/travel move, rather than the acceleration as seen on the axis drive? The acceleration maybe equal if perpendicular to the axis, but if the end effector runs each axis equally the resulting acceleration on a Cartesian machine would be more like M204 P707 T707.

Am I missing something or is this some kind of bodge to cover a hole in one of the firmwares?

dc42

It looks like a bodge to me. IMO, slic3r shouldn't be generating M201 at all because those values are the machine limits. It should only use M204.

DocTrucker

That's what I suspected. I'll be cutting them out. Will check latest dev version and file a github issue if it's still doing it that way.

Phaedrux

This would explain why when canceling a print on the first layer the acceleration remains stuck set to the very low accel I use for the first layer.

The way that Marlin uses M204 seems to be very different as well, and everything that Slic3r PE does seems to be very marlin centric, even when set to use RepRap firmware flavour.

@dc42 How did your push for gcode syntax conformity play out? Ever get any buy in?

DocTrucker

I was thinking about the option in Slic3r that changes the output gcode a little. Not had a chance to test them yet.

dc42

@phaedrux said in M201, M204, & Slic3r Geometry Dependant Acceleration Control:

@dc42 How did your push for gcode syntax conformity play out? Ever get any buy in?

The Smoothieware devs agreed, but the Marlin devs ignored it. All I got was a complaint that the GCode wiki at reprap.org was hard to use because it had too many RRF-specific GCodes in it.