Bug: Wrong first layer / Preheat temp in 3d printing when switching machine with different material

[tyeth]

🐞 bug report

Affected Version(s)

4.2.1

To Reproduce

SOG-dual-mode-spring-motor-rolling-chassis-wheel-rear.zip

Steps to reproduce the behavior:

1. Start a 3dp project for the Snapmaker 2.0 A350 and select PETG.
2. Add a model, generate gcode and export as file somewhere.
3. Start a new blank 3dp project using the File Menu -> New Project.
4. Change machine settings to Snapmaker Original (Snapmaker OG / SOG)
5. Witness Luban restart at welcome / examples screen.
6. select 3dp option to load into blank project for snap OG.
7. Verify PLA is selected visually but don't touch material settings.
8. Add wheel-rear.stl
9. Use Duplicate and witness one is out of bounds
10. use Auto Arrange to squeeze both models onto bed.
11. Adjust settings to wall size 1.5mm, infill percentage 30, bed adhesion from skirt to raft
12. Generate gcode and export as file.
13. Load file in favourite text editor and verify start gcode is wrong temp

Exception or Error (optional) Printing with octoprint the file started the first layer (layer number -6 which is raft) at PETG temperatures instead of PLA

Expected behavior File would contain start gcode using temperatures from Material selected on screen not whatever is cached.

🌍 Your Environment

Platform:

- Operating System: [Windows 11 x64]
- Printer: [Snapmaker Original & Snapmaker A350]

This is also in the private forum thread for the beta https://forum.snapmaker.com/t/snapmaker-original-pla-after-using-a350-petg-starts-at-wrong-temp/24708

[afresh1]

I can reproduce something very similar with Luban 4.1.4 on Windows 10. If I have "Normal Quality" Printing Settings selected or choose "Normal Quality" after opening Luban and do not change the Material Settings, when I Generate G-code and export to a file, it exports with the first layer at 215 degrees and the bed at 60 degrees. If I change the Material Settings, even switching to a different one and back, it seems to export properly (most of the time). Changing Printing Settings does not fix it however, choosing Normal and then Fast or High gets me the wrong values in the generated G-code.

If either of the other two default Printing Settings are chosen when I start Luban and I never choose Normal I do not see this issue.

The STL I use, or moving it around, does not seem to matter.

This could be related to #1400

[vibutway]

Thank you for your feedback, according to your steps, we have reproduced the problem, this problem will be fixed in a subsequent version