Klipper Documentation for Extruder Temp is out of date

I have been attempting to setup a CR6-SE with Klipper. I am using Superslicer and Klipper, Moonraker, and Mailsail are all installed and working on a Pi 3. There are a couple of areas that are not clear in the documentation.

The documentation seems to elude that Marlin should be chosen for the best use of Gcode commnds. More importantly, when I use the Klipper interface, and read the documentation for the names of the extruder heater, nothing seems to work when attempting to print a file. One error comes back the the HEATER_TEMP is not a known variable, yet in the documenation it seems any valid method of using gcodes with print_start should work.

Yet, if I use print_start M140 S70 M104 T0 S240 I get an error on the format of the command.

The CR6-SE has several different github examples dating back to 2021 and i is unclear which if any are current when viewed with the samples in the config folder of the current release. This is a pretty extensive product, but for someone is very familiar with technology and development, a data dictionary in a file that is well maintained and current would take confusion out of variables that according to the klipper github readme.md seems to be a moving target when it comes to names. How can I simply call print start with the bed and extruder temperature without format errors when the names seem to change frequently.

Thank You.

print_start is not a built-in part of Klipper. If it exists, it’s a custom macro that you defined in your Klipper config (most example configs in the Klipper documentation do not include a start macro, but a handful do, and if you copied a config from somewhere else it could contain almost anything.)

The correct way to call your custom macro depends on your specific config; the example in the slicer documentation is to give you the basics of what a call might look like, but you still need to know how you’ve configured Klipper in order to apply that. For instance, here’s a macro:

[gcode_macro PULL_THE_LEVER_KRONK]
description: Print start
gcode:
    {% set BED_TEMP = params.YZMA_EVILNESS | default(60) | float %}
    {% set EXTRUDER_TEMP = params.KUZCO_GROOVINESS | default(190) | float %}
    # Lower temp for bed mesh probing, to prevent ooze
    {% set PROBE_TEMP = 140 %}
    CLEAR_PAUSE
    # Start heating bed
    M140 S{BED_TEMP}
    # Home
    G28
    # Set extruder to relative mode
    M83
    # Start heating extruder to probe temp after bed temp reaches 65%
    TEMPERATURE_WAIT SENSOR=heater_bed MINIMUM={BED_TEMP * 0.65}
    M104 S{PROBE_TEMP}
    # Wait for bed to reach temp
    M190 S{BED_TEMP}
    # Wait for extruder to reach temp
    M109 S{PROBE_TEMP}
    # Probe bed mesh
    BED_MESH_CALIBRATE
    # Bring extruder up to print temp
    M109 S{EXTRUDER_TEMP}
    # Turn on LED
    SET_PIN PIN=LED VALUE=1.00
    # Prime extruder
    G92 E0
    G1 E{printer['gcode_macro END_PRINT'].retract} F500
    G92 E0
    # Absolute positioning
    G90

For this particular config the correct custom start g-code to put in SuperSlicer would be:

PULL_THE_LEVER_KRONK KUZCO_GROOVINESS={first_layer_temperature} YZMA_EVILNESS={first_layer_bed_temperature}

Use the START_PRINT macro from sample macros as a start and call it in SuperSlicer on start gcode with this on a single line

START_PRINT BED_TEMP=[first_layer_bed_temperature] EXTRUDER_TEMP=[first_layer_temperature]

Yes, I know it isn’t part of Klipper. However, it is translated and sent to the Klipper firmware. I’ve been successfully developing hardware and software, including real time machine controls for 50 years. What exactly is your point, other than hearing yourself talk. I am well beyond that and quite frankly, your response explains everything wrong with this process. In either case, I solved the issue with the conflicting docs and projects. You people close these issues like you close your eyes to existing issues.

Cheers

Please keep your tone civil here and even better than ranting: Contribute to the project by issuing a pull request to the Klipper GitHub and help improving the documentation.

In addition, I do not understand what you are referring to. The answers given are perfectly valid but maybe unrelated to what you are reporting.
Please point to the relevant documentation and provide a concise example.