All tools are heated at start regardless of how many are used.

[TypQxQ]

Version

PrusaSlicer 2.4.0-rc2+win64

Operating system type + version

Windows 10

3D printer brand / version + firmware version (if known)

Custom Toolchanger, RRF 3.4 beta 7

Behavior

When slicing for RepRap firmware a print where 2 tools are used, all 3 tools are heated up between the custom Start G-code and the custom Tool change G-code:

G10 S220 P0 ; set temperature
M116 ; wait for temperature to be reached
G10 S220 P1 ; set temperature
M116 ; wait for temperature to be reached
G10 S205 P2 ; set temperature
M116 ; wait for temperature to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion

Project File (.3MF) where problem occurs

Christmas_Tree_Window.zip

[rtyr]

It is automatically added only if G10 commands are not specified in your custom start g-code.

You can add for example:
G10 S{first_layer_temperature[initial_tool]} P[initial_tool] ; set temperature

[TypQxQ]

Thank you!
G10 is the old way and M568 is the new way:
https://duet3d.dozuki.com/Wiki/G10

[bubnikv]

We recently switched from M104 to G10 for RepRap firmware, should we now switch to M568?

[n8bot]

We recently switched from M104 to G10 for RepRap firmware, should we now switch to M568?

No no no no!

RepRap version 2.05 does not support the new m568. Many users still use RRF 2 because Rrf3 is basically still beta -- "stable" release aside. I prefer 2.05.1 (last release of rrf2)

The documentation for rrf says that new versions of rrf will support g10 for quite a while.

It would be awkward to allow the user to choose which gcode they want to use... so I don't know how to handle this.

I don't know why rrf made that change. I'm not a user of the new 3.0 firmware because I prefer the "long term stability" of 2.05.1

This is a long way of saying please don't change anything right now. There is time to make this decision.

[n8bot]

@bubnikv as a stop gap, until G10 is fully deprecated, IMO, PS should emit only G10 but detect both G10 and M568 as valid.

[JohnOCFII]

And while M104 is deprecated in RRF 3.x, it is still supported and functions properly.

[n8bot]

And while M104 is deprecated in RRF 3.x, it is still supported and functions properly.

Yes this is true. I think it is the case, but we should confirm, that M104 is properly detected by PS when in RRF flavor.

All versions of RRF understand M104.
All versions of RRF understand G10 (I believe the change was made a long time ago in a galaxy far far away).
Only versions RRF 3.3-beta2 and up understand M568.

While most bleeding-edge users have moved to RRF3+, I think many OEMs prefer to deploy RRF2 for the time being.

Also, the M568 command used to have a different meaning in older versions of RRF, so it is problematic to emit without knowing the version number. G10 is safe to emit to all versions.

[JohnOCFII]

Yes this is true. I think it is the case, but we should confirm, that M104 is properly detected by PS when in RRF flavor.

It does - here's a snippet from GCODE I just sliced with rc2

...
...
...

M107
;TYPE:Custom
; Railcore 300ZL start code - 20 May 2021
M140 S75 ; Raise bed temp to profile requested bed temp
M190 S75 ; Wait for bed temp to rise
G28 ; home all axes
G32 ; Autocalibrate bed
G32 ; Autocalibrate bed a second time
G28 Z ; Home Z after bed leveling
;
;
G1 Z20 F600 ; Move bed down 20
M104 S255 T0 ; Raise hot-end temp to profile requested hot-end layer 1 temp
M109 S255 T0 ; Wait for hot-end temp to rise to profile requested hot-end layer 1 temp

[lukasmatena]

Can you please check this in 2.6.0-alpha2 and provide some feedback? Thanks.