M109 and M190 Injected after PRINT_START macro

[MarcPot]

Version

2.3.55.2

Operating system type + version

Windows 10 64bit

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

Klipper

Behavior

When using the Klipper gcode flavour there is still a M109 and M190 after my PRINT_START macro.
This causes the printer to wait a sec or 2 after my print start (purge line), causing it to ooze before starting the actual print.

The reason for the printer to wait is because it's not always exactly within the M109 range.

A solution would be an (expert mode) checkbox to disable everything between
; custom gcode end: start_gcode and ;LAYER_CHANGE

I guess you could also make SS detect if you're giving temps to your print_start, but I don't think this would be as friendly for beginners.

Project File (.3MF) where problem occurs

Shape-Box.zip

[OldCurmudgeon3DP]

I use this as my printer tab custom g-code:

; process STARTGCODE
M107
M190 S[bed_temperature] ; just in case the slicer doesn't do it (i.e. 2.2.53)
START_PRINT_PLA ; Klipper macro
M104 S[first_layer_temperature_0] ; finish heating E0 during purge and skirt
PRIME_LINE ; Klipper macro. Must call above items first
; process PARTS

Here is my Klipper macro:

[gcode_macro START_PRINT_PLA]
gcode:
    CLEAR_PAUSE
    set_gcode_offset z=0.000      # higher offset = less squish. added to z_offset below
    M107 ; stop part fan
    M220 S100 ; reset feedrate
    M104 S180 ; start to heat E0, oozing above 185
    G21 ; set units to millimeters
    G90 ; use absolute coordinates
    G28 ; home all axes
    ; Klipper auto-loads the default mesh at the end of this file (defunct)
    BED_MESH_PROFILE LOAD=MESH{printer.heater_bed.target|int}C ; PLA mesh stored end of file
    M82 ; use absolute extruder distances
    G92 E0.0 ; zero the extruder position
    G1 X10 Y10 Z15 F6000 ; ooze here while heating
    M109 S190 ; wait for E0 to preheat
    SET_RETRACTION UNRETRACT_EXTRA_LENGTH=0 RETRACT_LENGTH=0.35
    ; slicer sets first layer hotend temp next

I also use Klipper as the firmware flavor w/ machine limits disabled.

[MarcPot]

Hey @ProfEngr,

Thanks for wanting to help, but I think you misunderstood my issue. Because if I’d use what you have there I’d still have the same problem. Because there would still be a M109 and M190 after the PRIME_LINE.

[OldCurmudgeon3DP]

I had something similar to this a while back. That's why I have the bed and nozzle temp variables specifically called out in the custom section. It was an issue w/ the firmware flavor I was using at the time. I just left it in because it kept working.

[aka13-404]

I would like to confirm, that I get unwanted m104, 109 and 190 injected in the beginning of the gcode. I have them processed entirely on the klipper side, and do not want them in my gcode. AFAIK there is still no way to disable them?

[randellhodges]

I wonder if these lines:

SuperSlicer/src/libslic3r/GCode.cpp

Lines 1406 to 1410 in 201c612

	//write temps after custom gcodes to ensure the temperature are good. (after tool selection)
	if(print.config().first_layer_temperature.get_at(initial_extruder_id) != 0)
	this->_print_first_layer_extruder_temperatures(file, print, start_gcode, initial_extruder_id, true);
	if (print.config().first_layer_bed_temperature.get_at(initial_extruder_id) != 0)
	this->_print_first_layer_bed_temperature(file, print, start_gcode, initial_extruder_id, true);

need a similar gcode_flavor check like these lines:

SuperSlicer/src/libslic3r/GCode.cpp

Lines 1320 to 1328 in 201c612

	if(this->config().gcode_flavor != gcfKlipper && print.config().first_layer_bed_temperature.get_at(initial_extruder_id) != 0)
	this->_print_first_layer_bed_temperature(file, print, start_gcode, initial_extruder_id, false);
	//init extruders
	this->_init_multiextruders(file, print, m_writer, tool_ordering, start_gcode);
	// Set extruder(s) temperature before and after start G-code.
	if ((this->config().gcode_flavor != gcfKlipper || print.config().start_gcode.value.empty()) && print.config().first_layer_temperature.get_at(initial_extruder_id) != 0)
	this->_print_first_layer_extruder_temperatures(file, print, start_gcode, initial_extruder_id, false);

Edit: I believe those new lines were added with ca3d823

[Frix-x]

I confirm, I got the same unwanted behavior.

This come from PrusaSlicer -> if you don't put explicitly M109/M190 into the custom start gcode of the slicer, it will add it for you as a security for Marlin printers. This is a regression in SuperSlicer coming from the last PrusaSlicer merge I think.

[supermerill]

I'm going to add a settign to force disable auto-added heating lines.

Problem is I also have report of "printer not heating" bugs.

[MarcPot]

Thanks Merill! I'll close when I get to testing it :)

[MarcPot]

@supermerill Sadly gotta report that the function is currently broken in the C/C++ Nigthly windows x64 C/C++ Nigthly windows x64 #296.

Sliced with the function off:

Sliced with the function on:

3mf:
raspberrypi_mounting_bracket_x1_rev1.zip

EDIT:
External gcode viewer shows the same issue:

[supermerill]

@MarcPot everyhting is fine.
the difference are:

G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
M104 S245 ; set temperature
M109 S245 ; set temperature and wait for it to be reached
M190 S85 ; set bed temperature and wait for it to be reached

are not written with the 'only custom gcode' so be sure to have them in your start gcode!

also there is a M104 & 140 a bit alter in the print with the option activated, but it's nothing to be worry about, imo.

But you're right that the code viewer misses the header if it's hidden in your macro. I should create one for the gcodeviewer.

[MarcPot]

You're right, should've looked at the files instead of the viewers.
Thanks for the great work Merill!

Closing this issue since it has been resolved and the bug is unrelated to the issue.