nozzle heating GCODE wait command not working as intended

  • 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:

    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
    ; Filament gcode

    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:

    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 🙂

  • @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)

  • @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.

  • @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
    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.

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

  • @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.

  • 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.

    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 🙂

  • administrators

    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.

Log in to reply