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

Initial/final layer print temperature doesn't match desired print temperature #14019

Open
2 tasks
Reynolds-Beta opened this issue Dec 11, 2022 · 2 comments
Open
2 tasks
Labels
Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. Type: Bug The code does not produce the intended behavior.

Comments

@Reynolds-Beta
Copy link

Application Version

5.2.1

Platform

Windows 11

Printer

Ultimaker S5

Reproduction steps

  1. Add a new material. In this case I duplicated generic PLA to create a MatterHackers MHBuild PLA material which (from experience) operates better from a bit lower temp than the generic settings
  2. Set Default Printing Temperature in the material to 185C - this is the lower range of MHBuild PLA recommended temps.
  3. Set Default Build Plate Temperature in the material to 40C. Again, as recommended
  4. Active the new material profile, choosing to discard any settings from previous settings
  5. Choose the Default Fine (0.1) profile - you can actually choose almost any "profile" and get a bunch of different temperatures other than what you set.

See the material printing temperatures highlighted.

Actual results

Printing and build-plate temperatures do not reflect what was entered - or at least there isn't an explanation as to why they are different and how they are controlled. See picture below.

Some of these values are now below the range of recommended settings from the manufacturer (see Initial/Final Layer Temperature) - in this case 180 is the low point of the range.

image

Expected results

Entered values are reflected in settings. If such is the case, then the material settings (when making the material profile) should have the additional fields to set the calculated fields.

and

Explanations on why they are different to expected values.

Checklist of files to include

  • Log file
  • Project file

Additional information & file uploads

Choosing other profiles such as Default Extra Fast change the values to even different than Default Fine, again without explanation or documentation. See below.

image

@Reynolds-Beta Reynolds-Beta added Status: Triage This ticket requires input from someone of the Cura team Type: Bug The code does not produce the intended behavior. labels Dec 11, 2022
@GregValiant GregValiant added Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. and removed Status: Triage This ticket requires input from someone of the Cura team labels Dec 12, 2022
@GregValiant
Copy link
Collaborator

Thanks for the report.
I think this comes down to the priority of the order of the over-rides. Should "Material" settings over-ride the custom "Profile Settings" of a user?
If you use a "canned" profile like "Standard Quality" then changing material will update the temperatures. If you are using a "Custom Profile" then changing materials has no effect on the temperatures.

There was a recent bug report regarding the "Initial Print Temperature" and the "Final Print Temperature". From what I was able to determine - neither of them ever gets inserted in the gcode by Cura. A user could enter them manually into the gcode file, but I don't actually see a point to that.
If you were to add this to your StartUp Gcode then the setting would work:
M109 S{material_initial_print_temperature}
M104 S{material_print_temperature_layer_0}
In this example - If you Initial Print Temperature was 200 and the Initial Layer Print Temperature was 210 then the hot end would get to 200 and printing would start as the heater continued up to 210 but Cura doesn't add it.

To have any value, the M104 S{material_final_print_temperature} would need to be inserted prior to the end of the last layer. Cura doesn't do that either. The line would need to be added manually after the gcode was created and in that case the keyword "material_final_print_temperature" would not work so the line would be M104 S185 (or whatever).

I'll leave the bug label on for now and someone from the Cura team will respond but what I see here is expected behavior. A user's custom profile will not be over-ridden by the material settings but a stock profile can be over-ridden. As far as the Initial Print Temperature and the Final Print Temperature settings go, it appears it doesn't matter what is entered in the boxes as they aren't used anyway.

@Reynolds-Beta
Copy link
Author

Reynolds-Beta commented Dec 12, 2022

Appreciate the response, and I understand the situation - it's complex - isn't it always?

In this particular case - I'm not using a custom "profile", just the canned ones for the Ultimaker S5 (Visual, Engineering, Draft, etc.). This is always my starting point, after which if I need to tweak a setting, I'll do so then save it as a custom profile.

Let's break it down by the bugs in just this case:

  • Ignoring initial/final layer temp, the Printing Temperature setting is 195 when I choose a different "canned" profile, not 185 that I set for the material.
  • Build plate is set to 60, not the 40 that I set - in any of the canned profiles I can choose.
  • Irrespective of whether they are included in gcode or not, the initial/final layer temp are incorrect,

Basically, the settings are all over the place. There may indeed be a good reason for these kinds of deviations, but it is non-obvious to the user what is driving them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Under Investigation The issue has been confirmed or is assumed to be likely to be a real issue. It's pending discussion. Type: Bug The code does not produce the intended behavior.
Projects
None yet
Development

No branches or pull requests

2 participants