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.

[wawanbreton]

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.

This is very likely indeed. The addition of the if/else logic included a complete rewrite of the parsing, and I probably tested with multi-lines gcode only, so this case could have been skipped. I will add it to the unit-tests and see what happens.

For internal reference: CURA-12386

[GregValiant]

@seth995 It looks like a fix has been implemented for the next release. I'll go ahead and close this as it appears to have been addressed for 5.10.0