Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order

    M201, M204, & Slic3r Geometry Dependant Acceleration Control

    Firmware developers
    3
    6
    1077
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • DocTrucker
      DocTrucker last edited by 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?

      Alive: 1 Ormerodish machines. 1 Custom Cantilever. 3 P3Steel. 1 Ciclopish scanner. In build: 1 P3Steel. Controllers: 2 Duet 2 , 2 D0.6, 1 D0.8.5, 1 D3 v0.5, 1 RAMPS/DRV8825, 1 Uno/Scan Card.

      1 Reply Last reply Reply Quote 0
      • dc42
        dc42 administrators last edited by

        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.

        Duet WiFi hardware designer and firmware engineer
        Please do not ask me for Duet support via PM or email, use the forum
        http://www.escher3d.com, https://miscsolutions.wordpress.com

        1 Reply Last reply Reply Quote 0
        • DocTrucker
          DocTrucker last edited by

          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.

          Alive: 1 Ormerodish machines. 1 Custom Cantilever. 3 P3Steel. 1 Ciclopish scanner. In build: 1 P3Steel. Controllers: 2 Duet 2 , 2 D0.6, 1 D0.8.5, 1 D3 v0.5, 1 RAMPS/DRV8825, 1 Uno/Scan Card.

          1 Reply Last reply Reply Quote 0
          • Phaedrux
            Phaedrux Moderator last edited by

            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?

            Z-Bot CoreXY Build | Thingiverse Profile

            dc42 1 Reply Last reply Reply Quote 0
            • DocTrucker
              DocTrucker last edited by DocTrucker

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

              Alive: 1 Ormerodish machines. 1 Custom Cantilever. 3 P3Steel. 1 Ciclopish scanner. In build: 1 P3Steel. Controllers: 2 Duet 2 , 2 D0.6, 1 D0.8.5, 1 D3 v0.5, 1 RAMPS/DRV8825, 1 Uno/Scan Card.

              1 Reply Last reply Reply Quote 0
              • dc42
                dc42 administrators @Phaedrux last edited by

                @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.

                Duet WiFi hardware designer and firmware engineer
                Please do not ask me for Duet support via PM or email, use the forum
                http://www.escher3d.com, https://miscsolutions.wordpress.com

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Unless otherwise noted, all forum content is licensed under CC-BY-SA