Slicer still generates G10 command before custom code, even if custom code contains G10

[LeavOA]

What happened?

I think this might be a RepRapFirmware-specific issue?

RRF deprecated the use of M104 And even G10 is not future-proof, since it is being replaced by M568

Currently SuperSlicer doesn't detect G10 Or M568 commands, and still adds the G10 to the beginning of the output g-code, even if it exists in the custom g-code.

Expected behavior would be:

• Slicer would recognize G10 and M568 commands in the custom code, and if it sees them, would not issue it's own G10 command
• Alternatively, the auto-generated code before the custom code could be edited in Expert mode
• Nice to have: tool tip would be updated to reflect G10/M568 in RRF.

P.S. The behavior works fine for M140 (bed temp) but nothing is ever mentioned about it in the tool tip....

Thanks!

Project file & How to reproduce

Tub thread.zip

Version

Version 2.3.57

Operating system

Windows 8.1

Printer model

Custom based on Duet 2 wifi

[supermerill]

I currently didn't wrote an algo to ensure the gcode has no heating problem. So I add an extra heat command after the custom start, to be on the safe side. Check "only custom start gcode" (start_gcode_manual) if you want full control and no saveguard.

For the G10 -> M568 ... We'll see. I guess they will change again next year.