Settings values replacements not working when in a single line (for Klipper Macro) when using extruder indexing

[seth995]

Cura Version

5.9

Operating System

MacOS Sequoia

Printer

custom w/ klipper

Reproduction steps

File has 2 parts, temp for extruder0 is 200, temp for extruder1 is 240, Bed temp is 70

add start gcode in single line:
START_PRINT EXTRUDER={extruders_enabled_count} EXTRUDER1=1 EXTRUDER_TEMP={material_print_temperature, 0} EXTRUDER1_TEMP={material_print_temperature, 1} BED_TEMP={material_bed_temperature}

When separated as such each value comes through as expected:
START_PRINT
EXTRUDER={extruders_enabled_count}
EXTRUDER1=1
EXTRUDER_TEMP={material_print_temperature, 0}
EXTRUDER1_TEMP={material_print_temperature, 1}
BED_TEMP={material_bed_temperature}

Actual results

Values in produced Gcode from single line is :
START_PRINT EXTRUDER=2 EXTRUDER1=1 EXTRUDER_TEMP=210

values in produced Gcode from separated line is:
START_PRINT
EXTRUDER=2
EXTRUDER1=1
EXTRUDER_TEMP=200
EXTRUDER1_TEMP=240
BED_TEMP=70

Expected results

Values should be
START_PRINT EXTRUDER=2 EXTRUDER1=1 EXTRUDER_TEMP=200 EXTRUDER1_TEMP=240 BED_TEMP=70

Add your .zip and screenshots here ⬇️

CURA5_9_Bug.zip

[GregValiant]

Thanks for the report.
I agree there is a bug in there somewhere.
It appears that {material_print_temperature, 0} is causing it to fail. If I leave out the extruder number it works.
Usually, when there is a failure in a replacement the entire code fails and the gcode will show the replacement pattern text unchanged.
I have no idea where that "210" number is coming from.
This seems to be OK:
START_PRINT EXTRUDER={extruders_enabled_count} EXTRUDER1=1 BED_TEMP={material_bed_temperature}
EXTRUDER_TEMP={material_print_temperature,0}
EXTRUDER1_TEMP={material_print_temperature,1}

I think the next release of Cura is coming up. @HellAholic or @wawanbreton this would appear to warrant some attention.

[seth995]

Looks like in the the fdmprinterdef.json is defining the default value which is 210
"material_print_temperature":
{
"label": "Printing Temperature",
"description": "The temperature used for printing.",
"unit": "\u00b0C",
"type": "float",
"default_value": 210,
"value": "default_material_print_temperature",
"minimum_value": "-273.15",
"minimum_value_warning": "0",
"maximum_value_warning": "285",
"maximum_value": "365",
"enabled": "machine_nozzle_temp_enabled",
"settable_per_mesh": false,
"settable_per_extruder": true
},

[seth995]

Additionally, this problem occurs with {material_print_temperature_layer_0, } and {material_initial_print_tempeature, }

{material_initial_print_tempeature, } results in the default value of 200 in the output gcode file, again suspect it is from the definitions.json

"material_initial_print_temperature": { "label": "Initial Printing Temperature", "description": "The minimal temperature while heating up to the Printing Temperature at which printing can already start.", "unit": "\u00b0C", "type": "float", "default_value": 200, "value": "max(-273.15, material_print_temperature - 10)", "minimum_value": "-273.15", "minimum_value_warning": "material_standby_temperature", "maximum_value_warning": "material_print_temperature", "maximum_value": "365", "enabled": "machine_nozzle_temp_enabled and not machine_extruders_share_heater", "settable_per_mesh": false, "settable_per_extruder": true },

[GregValiant]

I think some of the relevant code changed when the extended "logic" capability was introduced in 5.9.0. This might be an "unexpected consequence" of that.

EDIT: I just checked and it works correctly in 5.8.0.