• Tags
  • Documentation
  • Order
  • Register
  • Login
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.
  • undefined
    Phil333
    last edited by 11 Jan 2021, 14:06

    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 🙂

    undefined undefined undefined 3 Replies Last reply 11 Jan 2021, 14:31 Reply Quote 0
    • undefined
      engikeneer @Phil333
      last edited by engikeneer 1 Nov 2021, 14:33 11 Jan 2021, 14:31

      @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
      • undefined
        deckingman @Phil333
        last edited by 11 Jan 2021, 14:38

        @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
        • undefined
          Stephen6309 @Phil333
          last edited by 12 Jan 2021, 14:40

          @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
          • undefined
            piglet74
            last edited by 22 Jan 2021, 17:13

            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???

            undefined 1 Reply Last reply 22 Jan 2021, 18:35 Reply Quote 0
            • undefined
              Stephen6309 @piglet74
              last edited by 22 Jan 2021, 18:35

              @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
              • undefined
                Phil333
                last edited by 8 Feb 2021, 11:30

                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
                • undefined
                  dc42 administrators
                  last edited by 8 Feb 2021, 11:53

                  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