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

    nozzle heating GCODE wait command not working as intended

    Scheduled Pinned Locked Moved
    General Discussion
    6
    8
    1.3k
    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.
    • Phil333undefined
      Phil333
      last edited by

      Hello everyone 🙂

      I am using a Duet Wifi and have a 3D printer with 2 nozzles/extruders.

      Its strange, but the printer does not wait until the nozzle is heated up but starts immediately.

      The GCDOE I have is this:

      M107
      G10 P1 R200 S195 ; sets the standby temperature
      G10 P1 S200 ; set temperature
      G28 ; home all axes
      G1 Z5 F5000 ; lift nozzle
      G10 P1 S200 ; set temperature
      M116 ; wait for temperature to be reached
      G21 ; set units to millimeters
      G90 ; use absolute coordinates
      M83 ; use relative distances for extrusion
      T1
      ; Filament gcode
      ;BEFORE_LAYER_CHANGE
      ;0.24
      

      So in theory, the printer should use Tool 1 (G10 P1) and wait (M116) until the nozzle is hot (regarding the documentation).
      But instead the printer is setting the temperature and starts to "print".
      Because the nozzle is not instant hot, I get the message:
      ""Warning: Tool 1 was not driven because its heater temperatures were not high enough or it has a heater fault""

      Currently I bypass this, by editing every gcode manually with:

      M107
      M104 S205 T1 ; set temperature
      G28 ; home all axes
      G1 Z5 F5000 ; lift nozzle
      M109 S205 T1 ; set temperature and wait for it to be reached
      

      Can someone tell me, whats wrong here or where to start looking at?

      Board information:
      Board: Duet WiFi 1.02 or later
      Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 2.05.1 (2020-02-09b1)
      Duet WiFi Server Version: 1.23

      Thanks in advance 🙂

      engikeneerundefined deckingmanundefined Stephen6309undefined 3 Replies Last reply Reply Quote 0
      • engikeneerundefined
        engikeneer @Phil333
        last edited by engikeneer

        @Phil333 I think M116 on its own only waits for the bed and active tool. You don't select T1 until after you've already done your M116

        Move your T1 up earlier (or add another M116 after T1). Edit: or add in P0/P1 to your M116 so that it knows which tool to wait for (this is what I do for my chimera)

        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

        1 Reply Last reply Reply Quote 1
        • deckingmanundefined
          deckingman @Phil333
          last edited by

          @Phil333 My best guess is that it's because you need to select the the tool (T1) earlier. The G10 will set both the active and standby temperatures but that doesn't select the tool - it just prepares the active and standby temperatures that will be be used when the tool is selected. I know, that probably sounds daft or confusing but for those of us who use multiple tools, it makes sense.

          So move your "T1" to the start of code. Or at least use T1 before the G10 R and S.

          BTW, did you really mean to use Tool1 (P1)? Tool numbering starts at 0 (zero) so by default, if you only have a single tool, then it ought to be P0 (Tool zero). But if you've defined T1 in your config.g, then it'll be fine.

          Finally, with G10, the R is the standby temperature and the S is the active temperature. So usually, the active temperature is set higher than the standby temperature. I mention it simply because you have them the other way round.

          Ian
          https://somei3deas.wordpress.com/
          https://www.youtube.com/@deckingman

          1 Reply Last reply Reply Quote 1
          • Stephen6309undefined
            Stephen6309 @Phil333
            last edited by

            @Phil333 I use this for the start code in Prusaslicer, I only have one print head:
            T-1 ; deselect tool
            M98 P"/macros/PETGOffset" ; set z probe offset
            G10 P0 S[first_layer_temperature] R150
            M190 S[first_layer_bed_temperature]
            G28 ; home all axes
            G32 ; bed calibration - RRF
            T0 ; select tool 0
            M116
            G1 E5 ; extrude a bit
            ;M117 [input_filename_base]

            On the G10 R parameter, I set it high enough to soften the filament before the z home is done. The macro PETGOffset is to set the G31 for needed to print PETG.

            1 Reply Last reply Reply Quote 0
            • piglet74undefined
              piglet74
              last edited by

              I noticed a problem started for me when I upgraded to Prusaslicer 2.3. The reprap based gcode have deprecated m104 for heating hotend. So prusa implimented the g10 and now my printer starts moving but the hotend never gets turned on.

              They retained a version called reprap/sprinter for backwards compatibility.

              So I guess an update may be required for Duet to handle g10 the way the slicers expect it to be implemented???

              Stephen6309undefined 1 Reply Last reply Reply Quote 0
              • Stephen6309undefined
                Stephen6309 @piglet74
                last edited by

                @piglet74 The start code I posted above works with PrusaSlicer 2.3 on a Duet 3 Mini+ 5, and a Duet 3 6HC, both running off a PI4.

                It starts with a T-1, to deselect T0, which is set in config.g and start.g. When the G10 is sent, my T0 heats up to standby temp of 150C. After the G28 & G32, T0 is selected and the M116 waits for the temp to go to first_layer_temperature.

                The standby temp, is to make sure any filament dribbles don't affect Z probe homing.

                1 Reply Last reply Reply Quote 0
                • Phil333undefined
                  Phil333
                  last edited by

                  Thank you all, for your answers.

                  I reported this bug back to the developers of the slicer (SuperSlicer).
                  It will be fixed in the future.

                  In this case I also started to wonder a little what slicer to use with the RepRap firmware.

                  So far I dont see any slicer is implementing the RRF (3.x) GCODE correctly.

                  Examples:
                  Cura generating marlin flavor
                  Slic3r, PrusaSlicer and SuperSlicer are either generating marlin flavor or wrong RRF GCODE.

                  For me it does look like the RRF is doing its own thing - and based on DC42 explaination, I do understand why (eg. beeing more flexible).
                  But its a bit problematic if there is no slicer that generates GCODE how RRF 3 wants it to be.

                  So what is the advice to use?
                  Which slicers do you use and supports RRF 3 (with multiple printheads etc) correctly and out of the box?

                  Thanks a lot 🙂

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

                    RRF will accept GCode generated in Marlin mode by most slicers. Unfortunately, some of those slicers generate M201 and M203 commands that mess with the acceleration and speed limits. Worse, when Marlin implemented M203 the developer ignored the existing specification and changed the units in which the speed limits are configured. But it's usually possible to configure the slicer not to generate those commands.

                    AFAIK the current PrusaSlicer in RRF mode generates good code.

                    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