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

    help with optimizing heater temperature

    Scheduled Pinned Locked Moved Solved
    Tuning and tweaking
    6
    21
    416
    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.
    • dc42undefined
      dc42 administrators @jltx
      last edited by

      @jltx said in help with optimizing heater temperature:

      I am trying to optimize my print start times by kicking off some prep work just prior to the bed reaching temperature (the long pole).

      I pass the bed temp as param.B and use an expression to subtract 5 degrees. I wait for that to reach the then set final bed temp and nozzle temp without waiting, and kick off bed leveling, etc while those finish.

      However, this does not work. It just heats up the bed to full temp every time before anything else. So either the expression does not work here or I don't understand how heater requests are queued by the firmware. Any help? This is 3.6 but behaved the same on 3.5.

      ; set bed and hotend temps
      M190 S{param.B-5} ; set bed up to last 10 degress
      M568 P0 R170 S{param.A} ; set nozzle to first layer temp
      
      M140 S{param.B} ; finish bed to first layer temp
      T0  ; select tool 0
      
      ...
      

      That should work, unless either your tpre0.g or tpost0.g file waits for heating to finish. Do they?

      Another trick you can do to speed up hot end heating is to set the hot end standby temperature to the active temperature minus e.g. 50C (low enough to avoid oozing) and switch the heater to standby. Then set the bed temperature and wait for it. When that command completes, probe the bed, then select the tool, which will switch the heater to active.

      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

      jltxundefined 2 Replies Last reply Reply Quote 0
      • jltxundefined
        jltx @dc42
        last edited by

        @dc42 said in help with optimizing heater temperature:

        @jltx said in help with optimizing heater temperature:

        I am trying to optimize my print start times by kicking off some prep work just prior to the bed reaching temperature (the long pole).

        I pass the bed temp as param.B and use an expression to subtract 5 degrees. I wait for that to reach the then set final bed temp and nozzle temp without waiting, and kick off bed leveling, etc while those finish.

        However, this does not work. It just heats up the bed to full temp every time before anything else. So either the expression does not work here or I don't understand how heater requests are queued by the firmware. Any help? This is 3.6 but behaved the same on 3.5.

        ; set bed and hotend temps
        M190 S{param.B-5} ; set bed up to last 10 degress
        M568 P0 R170 S{param.A} ; set nozzle to first layer temp
        
        M140 S{param.B} ; finish bed to first layer temp
        T0  ; select tool 0
        
        ...
        

        That should work, unless either your tpre0.g or tpost0.g file waits for heating to finish. Do they?

        My tpost0.g does have M116 P0, but that isn't triggered until the T0 command, correct? the very first M190 should be blocking and wait for the set temperature. Which it does, btw, because the nozzle temp does not change at all until after the bed completes. The problem is the value passed to the M190 is always param.B without offset. Even this mod still passes the full param.B, which seems impossible.

        var bed_temp = {param.B}
        var start_bed = var.bed_temp - 10.0
        M190 S{var.start_bed} ; set bed up to last 10 degress
        

        param.B is passed in from the gcode file thusly:

        M98 P"0:/macros/print_scripts/print_start.g" A220 B55 
        

        Another trick you can do to speed up hot end heating is to set the hot end standby temperature to the active temperature minus e.g. 50C (low enough to avoid oozing) and switch the heater to standby. Then set the bed temperature and wait for it. When that command completes, probe the bed, then select the tool, which will switch the heater to active.

        I will try this but would still like to resolve the expression issue above since I would like to use those reliably in other areas.

        1 Reply Last reply Reply Quote 0
        • jltxundefined
          jltx @dc42
          last edited by

          @dc42 ignore. I found the problem: the slicer is emitting its own gcode outside of the start g-code. Sorry for the bother! The expression does work.

          fcwiltundefined 1 Reply Last reply Reply Quote 0
          • fcwiltundefined
            fcwilt @jltx
            last edited by

            @jltx said in help with optimizing heater temperature:

            @dc42 ignore. I found the problem: the slicer is emitting its own gcode outside of the start g-code. Sorry for the bother! The expression does work.

            Getting a slicer to not generate conflicting code can be a bit tricky.

            Some slicers have options to not send temp commands - using 0 values in the slicer config.

            Other slicers allow specifying the gcode "flavor" (RepRap, Marlin, etc). You can using a simple object and look at the code created for each flavor to find the best.

            If you are using the feature that allows the slicer to invoke your own startup code you can ignore any code before yours is invoked, as your code can/will override it.

            I have tried all the slicers and managed to find settings the prevented the slicer from generating code that conflicted with my code but it's been so long I cannot recall exactly what the settings are.

            Frederick

            Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

            jltxundefined 1 Reply Last reply Reply Quote 0
            • jltxundefined
              jltx @fcwilt
              last edited by jltx

              @fcwilt Yes, this is a surprising discovery. I have been using PrusaSlicer for years but just switched to Orca. To me this is a serious Orca bug. The slicer should NOT control the machine without consent. There are custom gcode sections for a reason.

              For anyone who stumbles on this, Orca looks at your start gcode and if it doesn't see any heater command (because you use a macro, for example) then it injects its own before any of your own gcode is emitted. There is NO WAY to disable directly. You can hack around this by putting M190 S0 and G10 S0 (those are the commands it is looking for, M140 also works) at the start of your start gcode and then it will not emit its own.

              fcwiltundefined dc42undefined engikeneerundefined 3 Replies Last reply Reply Quote 0
              • fcwiltundefined
                fcwilt @jltx
                last edited by

                @jltx said in help with optimizing heater temperature:

                @fcwilt Yes, this is a surprising discovery. I have been using PrusaSlicer for years but just switched to Orca. To me this is a serious Orca bug. The slicer should NOT control the machine without consent. There are custom gcode sections for a reason.

                For anyone who stumbles on this, Orca looks at your start gcode and if it doesn't see any heater command (because you use a macro, for example) then it injects its own before any of your own gcode is emitted. There is NO WAY to disable directly. You can hack around this by putting M190 S0 and G10 S0 (those are the commands it is looking for, M140 also works) at the start of your start gcode and then it will not emit its own.

                If the code generated by Orca appears before the invocation of your own code it shouldn't matter.

                What happens if you specify 0 temp values in Orca?

                Frederick

                Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

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

                  @jltx said in help with optimizing heater temperature:

                  For anyone who stumbles on this, Orca looks at your start gcode and if it doesn't see any heater command (because you use a macro, for example) then it injects its own before any of your own gcode is emitted.

                  This is standard behaviour of all the slicers I have used.

                  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
                  • dc42undefined dc42 marked this topic as a question
                  • dc42undefined dc42 has marked this topic as solved
                  • engikeneerundefined
                    engikeneer @jltx
                    last edited by

                    @jltx in my experience you are better to include the M190 etc lines in the Orca start code, but then comment them out. That way it 'thinks' you already have the temperature commands in there as its notnclever enough to spot that theyre commented out, but they won't mess with your macros etc (e.g. accidentally waiting for the temp to reach 0 if you use M190 S0).
                    At least that's what I do in PrusaSlicer...

                    E3D TC with D3Mini and Toolboards.
                    Home-built CoreXY, Duet Wifi, Chimera direct drive, 2x BMG, 300x300x300 build volume
                    i3 clone with a bunch of mods

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

                      @engikeneer said in help with optimizing heater temperature:

                      @jltx in my experience you are better to include the M190 etc lines in the Orca start code, but then comment them out. That way it 'thinks' you already have the temperature commands in there as its notnclever enough to spot that theyre commented out, but they won't mess with your macros etc (e.g. accidentally waiting for the temp to reach 0 if you use M190 S0).
                      At least that's what I do in PrusaSlicer...

                      Ancient Slicer Wisdom

                      Same was true in Cura and Slic3r since days yore.

                      Z-Bot CoreXY Build | Thingiverse Profile

                      fcwiltundefined 1 Reply Last reply Reply Quote 0
                      • fcwiltundefined
                        fcwilt @Phaedrux
                        last edited by

                        @Phaedrux

                        While there is nothing wrong with doing that it is not needed, in my experience.

                        Here is the start code from Cura 5.10.0:

                        T0
                        M104 S0
                        M109 S0
                        M98 P"print_begin.g"
                        M82 ;absolute extrusion mode
                        M82 ;absolute extrusion mode
                        M98 P"print_extrude_begin.g"
                        M83 ;relative extrusion mode
                        M83 ;relative extrusion mode
                        G1 F1500 E-6.5
                        ;LAYER_COUNT:259
                        ;LAYER:0
                        M107
                        

                        Note that the M104 and M109 are harmless as the call to user code follows them and there is no unwanted code that follows the call to the user code.

                        Here is the start code from Prusa 2.9.2:

                        M98 P"print_begin.g"
                        G21 ; set units to millimeters
                        G90 ; use absolute coordinates
                        M83 ; use relative distances for extrusion
                        M98 P"print_filament_begin.g"
                        M107
                        

                        Again there is no unwanted code that follows the calls to user code.

                        Not big deal, just thought I would mention it.

                        Frederick

                        Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6

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