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

    Time estimate by layer errors

    Scheduled Pinned Locked Moved
    Tuning and tweaking
    3
    4
    432
    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.
    • mperdueundefined
      mperdue
      last edited by mperdue

      I've always noticed a difference between the various time estimates with the layer based estimate being very far off the other two - sometimes by two orders of magnitude. I finally looked at it and the reason is that it calculates the time based on some period related to the time to print a layer (current time, average, whatever) times the number of remaining layers. The problem is that the number of remaining layers is based on the stopping position of the Z axis divided by the layer height. In my ending script I always send the Z axis to 300 to make accessing the part easier. This causes the system to assume there are 2999 layers when my layer height is set to 0.1mm even when the actual part is only 10mm tall. Is there a code that can be put in the script to tell it that the part stops here?

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

        Add a comment that starts with ;E or ; E to that line. Example:

        G1 Z300 F3000 ; E

        That will prevent RRF for thinking that your last layer is printed at Z=300.

        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 1
        • Phaedruxundefined
          Phaedrux Moderator
          last edited by

          Another way to avoid this is to move your slicer end gcode into a macro called stop.g, and then change your slicer end gcode to be M0 which will execute stop.g.

          This can also help with nozzle prime lines in the starting gcode having a z height set differently to the first layer height of the sliced file, which can interfere with some info displayed in the DWC. Most of that start gcode can be moved into either start.g which gets run before every print, or by calling a separate macro explicitly.

          The only gcode that can't get moved from the slicer to duet macros would be any slicer specific placeholder labels like those used to set temperatures. Like [first_layer_temp], etc.

          Z-Bot CoreXY Build | Thingiverse Profile

          1 Reply Last reply Reply Quote 1
          • mperdueundefined
            mperdue
            last edited by

            Thanks guys. I knew someone here would know what to do.

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