Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom GCODE from Printer settings not honored #4079

Closed
dpeart opened this issue Jan 18, 2024 · 11 comments
Closed

Custom GCODE from Printer settings not honored #4079

dpeart opened this issue Jan 18, 2024 · 11 comments
Labels
bug Something isn't working as intended fixed for the next version That means that you should be able to test it in the latest nightly build

Comments

@dpeart
Copy link

dpeart commented Jan 18, 2024

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_print_min[0]}{first_layer_print_min[1]}{first_layer_print_max[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
Copy link
Owner

when loading your project, i have that:
image

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

@dpeart
Copy link
Author

dpeart commented Jan 18, 2024

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

@dpeart
Copy link
Author

dpeart commented Jan 18, 2024

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

image

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

@dpeart
Copy link
Author

dpeart commented Jan 18, 2024

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_print_min[0]}{first_layer_print_min[1]}{first_layer_print_max[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
Copy link
Owner

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
Copy link
Author

dpeart commented Jan 18, 2024

SuperSlicer.zip

I then load any STL, slice and export gcode.

image

@dpeart
Copy link
Author

dpeart commented Jan 18, 2024

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

@supermerill supermerill added the bug Something isn't working as intended label Jan 24, 2024
@neophyl
Copy link

neophyl commented Jan 24, 2024

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 prusa3d#6533 that one was a malformed Printer profile on a snapmaker that someone had imported. Yours looks like its your filament profiles.

@dpeart
Copy link
Author

dpeart commented Jan 24, 2024

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.

@dpeart dpeart closed this as completed Jan 24, 2024
@supermerill
Copy link
Owner

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
Copy link
Owner

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.

@supermerill supermerill added the fixed for the next version That means that you should be able to test it in the latest nightly build label Jan 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working as intended fixed for the next version That means that you should be able to test it in the latest nightly build
Projects
None yet
Development

No branches or pull requests

3 participants