Custom GCODE from Printer settings not honored

[dpeart]

What happened?

In my printer custom Gcode I have: `START_PRINT EXTRUDER_TEMP={first_layer_temperature[initial_tool]} BED_TEMP=[first_layer_bed_temperature] MATERIAL=[filament_type] SIZE={first_layer_printmin[0]}{first_layer_printmin[1]}{first_layer_printmax[0]}{first_layer_print_max[1]} INITIAL_TOOL={initial_extruder} LAYERS={total_layer_count} NOZZLE_SIZE={nozzle_diameter[0]}

STOP_LED_EFFECTS LEDS="neopixel:caselight"

SET_LED_EFFECT EFFECT=busy SET_LED_EFFECT EFFECT=progress_bar

SET_PRINT_STATS_INFO total_layer={total_layer_count}`

I use START_PRINT instead of PRINT_START.

When I get the gcode it looks like: `;TYPE:Custom ; custom gcode: start_gcode PRINT_START

;; If you are passing variables to PRINT_START, comment out above line and uncomment the last 3 lines instead. ;; Guide: https://github.com/AndrewEllis93/Print-Tuning-Guide/blob/main/articles/passing_slicer_variables.md ;; Make sure the variable names match (for example if you use "EXTRUDER" instead of "HOTEND") `

When I run the code I get the error that PRINT_START unknown as in my setup it is START_PRINT.

This worked previously.

Project file & How to reproduce

[c]_Coupler_Block_xN.zip

Version

2.5.59.6

Operating system

windows 11

Printer model

voron 2.4 with afterburner

[supermerill]

when loading your project, i have that:

I don't really understand what you did and what you want.

[dpeart]

OOPS, I was trying different things. Let me re-upload

[dpeart]

Well I think that is part of the problem. Here is what my custom gcode looks like in the tool when I save the 3mf

But when I open the saved 3mf I get the default custom gcode setting like you show.

[dpeart]

Here is a copy of the text: `START_PRINT EXTRUDER_TEMP={first_layer_temperature[initial_tool]} BED_TEMP=[first_layer_bed_temperature] MATERIAL=[filament_type] SIZE={first_layer_printmin[0]}{first_layer_printmin[1]}{first_layer_printmax[0]}{first_layer_print_max[1]} INITIAL_TOOL={initial_extruder} LAYERS={total_layer_count} NOZZLE_SIZE={nozzle_diameter[0]}

STOP_LED_EFFECTS LEDS="neopixel:caselight"

SET_LED_EFFECT EFFECT=busy SET_LED_EFFECT EFFECT=progress_bar

SET_PRINT_STATS_INFO total_layer={total_layer_count}`

[supermerill]

Can't reproduce, even when starting from a voron printer. So, i need to be in the same state as you before you save. Can you zip your configuration directory (you get to it via help -> show configuration directory) and drop it here? And then the minimum manual steps to fail to save your custom gcode?

that way, i can really try to replicate your issue as much as possible.

[dpeart]

SuperSlicer.zip

I then load any STL, slice and export gcode.

[dpeart]

I don't know if this helps, but I also get a skirt, even though it is disabled.

[neophyl]

dpeart I took a look at some of the .ini files from the SuSi config folder that you attached. Several (most) of your filament ini files have settings in for print/filament and printer. They should only have filament based settings. I think that is the root cause of the differences in slicing you are having. Merill will have to confirm though.

I've seen this before in earlier versions of Prusa Slicer. The user had imported a profile from somewhere online and it contained all the settings from all 3 profiles. It meant that there duplicate settings and because the gui could only edit the ones in the profile its supposed to they could never edit these duplicates so they had the same sorts of issues you seem to be having. Of course saving a 3mf for others and them opening it doesn't have an issue as we only get the settings inside the 3mf. As you have the profiles installed on your system I suspect its load all the settings in, including ones for print and printer that are in the filament section.

They ended up clearing all of their config out and starting from scratch. I remember Prusa adding something in to filter out such imports. Edit - found the issue on the PS github https://github.com/prusa3d/PrusaSlicer/issues/6533 that one was a malformed Printer profile on a snapmaker that someone had imported. Yours looks like its your filament profiles.

[dpeart]

Thanks for looking into it. I recreated all my profiles from scratch and things have been working well since then. This matches what you suspect.

[supermerill]

I looked a bit why it's not possible to edit. The problem is PresetBundle.cpp:l655 out.apply(this->filaments.get_edited_preset().config); the filament preset has entries for everything, and so will overwrite everything. exactly what you said, neophyl. There already is some protections against that kind of problem, but there seems to be a way to slip through

[supermerill]

Found the bug. In preset.cpp:l1071: std::string incorrect_keys = Preset::remove_invalid_keys(config, default_preset.config); should be std::string incorrect_keys = Preset::remove_invalid_keys(preset.config, default_preset.config);

Also submitted a pr to prusaslicer.