nozzle heating GCODE wait command not working as intended

Phil333

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

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)

deckingman

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

Stephen6309

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

piglet74

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

Stephen6309

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

Phil333

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

dc42

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.