Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Bad firmware retractions using Simplify3D and M101/M102/M103

    Scheduled Pinned Locked Moved
    Tuning and tweaking
    3
    5
    1.6k
    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.
    • Ak Ericundefined
      Ak Eric
      last edited by

      Community FYI post

      I'd been doing test getting firmware retraction hooked up. I slice with Simplify3D fyi.
      As a baseline I first tested using S3D's software retraction. Then using the trick where you write a little text-replace script in S3D so it replaces all of it's retraction gcode with G10's & G11's (and made sure my RRF's M207 values matched S3D's), and it printed exactly the same results. So that's good. But it's annoying that you have to write this little script in S3D to pull it off. I believe in other slicers, like Slic3r, this is handled far more elegantly.

      Recently I read in a duet forum post that you can actually use S3D's 'Include M101/M102/M103' 'G-Code Options', and RRF will respect that as an alternate path to firmware retraction: So, I disabled 'normal retraction', killed my scripts, and checked that option on. No more little scripts needed. A downside is that S3D no longer shows the 'retraction bubbles' in its gcode preview.

      It does work but, the results are substantially worse that the other other method mentioned above. It seems to retract a 'lot more' during printing, and the overall print quality suffers in general. My guess was that it (that 'Include M101…' checkbox) may not be respecting S3D's own slicers settings when it comes to things like 'Only Retract When Crossing Open Spaces', and the side effect is it retracting a lot more often than it should. I decided to diff the two gcode files: Sure enough, the 'bad' one was retracting a lot more than the good one, confirming my suspicions.

      Here's a chunk of 'good gocde' (no extraneous retractions)
      [c]G1 X12.541 Y-4.566 E0.0311
      G1 X-4.566 Y2.562 F9000
      G1 X5.938 Y13.066 E0.6225 F1426[/c]

      And here's the same chunk of 'bad gcode' with retractions happening where they shouldn't.
      [c]G1 X12.541 Y-4.566 E0.0311
      M103
      G1 X-4.566 Y2.562 F9000
      M101
      G1 X5.938 Y13.066 E0.6225 F1426[/c]

      Below is a a pic comparing them: M101/M102/M103 on the left, the scripted version using G10 & G11 on the right. It's hard to tell because of the DOF, but the one one the left has significantly worse surface quality all over.

      I'm going to go back to the scripted route, just a headsup to the community.


      Cross-posted to S3D's forums as well: https://forum.simplify3d.com/viewtopic.php?f=9&t=9329

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

        Thanks for this information. Perhaps you should ask S3D to support G10/G11 retraction like every other slicer does.

        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
        • Ak Ericundefined
          Ak Eric
          last edited by

          I have, but asking them for anything is a black hole: Requests go in, nothing ever comes out.
          I did post this to their forum too, for what it's worth.

          1 Reply Last reply Reply Quote 0
          • Neotkoundefined
            Neotko
            last edited by

            @dc42:

            Thanks for this information. Perhaps you should ask S3D to support G10/G11 retraction like every other slicer does.

            Well I have to disagree with this gcode. Retractions without moves force stationary moves, unless the firmware does something magic with this.

            S3D does retractions mostly (if enabled) while doing a move (wipe while retracting) etcetc. Also you already set the filament size on s3d so using a g10/g11 doesn’t do much.

            About s3d team implementing this I’m 99.99% that they will never do it, I been hearing people asking for this since the um2 uses that g10/g11 and even um has move to simple extrude/retract moves to enable retractions while moving to kill stationary blops for um3.

            About the poster issue. Mind that if you have wipe while retract the way it works is different. Also the amount of Tool change retractions affects directly to what happens from printing A process to B. S3D thinks of processes as different prints and if the tool change isn’t the same as the main page of retractions/speed the toolchange kicks in between processes and changes the retraction amount. S3D has quite a lot of settings that sometimes when mixed can mess stuff

            1 Reply Last reply Reply Quote 0
            • Ak Ericundefined
              Ak Eric
              last edited by

              FWIW, I do not have 'wipe with retract' on the machine used for this test: I've found if I'm using a volcano nozzle from .8-1.2, this has a large advantage in reducing blobbing from all the drool that falls out. But on .4-.6mm nozzles, not so much, and in fact, can actually make the print quality look worse in some cases, IMO.

              But you bring up a good point: I've actually wondered (and not yet tested, although it would be easy) the same thing: If, in S3D, you have 'wipe with retract' set, but also enabled firmware retraction (via scripting solution of m101/m103) what would happen? Can you combine the two? I thought not, figuring S3D would be doing some sort of magic wipe/retract combo gcode, while firmware retraction (I presumed) 'just retracted', and had no concept of combining that with any other move at the time.

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