[4.8.0] strange T0 temperatures sometimes found in g-code file

[bellzw]

Application Version

4.8.0

Platform

64-bit Windows 10 on a Lenovo Yoga 14 laptop

Printer

BIBO Dual

Reproduction steps

slice a project using both extruders and different materials on each Material 1 standby temp = 100 Material 2 standby temp = 175

Actual results

In addition to the expected M104 T0 S100 commands, G-code file contains M104 T0 S100.0 M109 T0 S100.0 M104 T0 S124.8 M104 T0 S124.9 M104 T0 S125.3 M104 T0 S110.8 M104 T0 S109

Expected results

All M104 and M109 code referencing T0 moving to the standby temperature (100 C for PVA) would have S100, not 100.0 (of course, this makes no difference) or S124.8, 124.9, 125.3 or other strange temperatures.

This issue seems only to affect T0. 100.0 v. 100 makes no difference, however 124.8, for example is a little warmer than 100. In the attached g-code file, the strange temperatures occur at lines 6502, 24431, 20408, 290918, 294817. I didn't find an S13x, S14x, S15x, or S16x. I did not notice strange temperatures associated with T1, but it's possible that I missed them.

The 3mf and the g-code file are included in the zip. Yad_for_learning.zip

[fvrmr]

Hi @bellzw thank you for your bug report. This has to do with heating up your nozzle. You can find here an explanation how this exactly works: https://github.com/Ultimaker/CuraEngine/blob/master/docs/inserts.md Also see the setting extrusion cool down speed modifier. Let me know if this makes sense to you.

[bellzw]

inserts.md is a helpful explanation and agrees with what I know about thermodynamics and 3D printing. However, it is not obvious that is the source of my observations.

What caught my attention was that there were rather strange temperatures, being set on at least one of the extruders in anticipation of the changeover. In my case, the standby for T0 was 100 C (PVA) whereas for T1 it was 175 C (PVA). I noticed

1. There were instances of T0 set points that were not 100. insert.md and the explanation of printing temperatures at https://support.ultimaker.com/hc/en-us/articles/360012610379-Material-settings (I assume this is what you suggested I view) make sense, however, I don't think they are the cause of temperatures like 125.3. The strange temperatures do not correspond to any of the temperature settings in my material profiles, and they appear to be the instruction to cool T0 to the standby temperature FOLLOWING the switch to T1. I would have expected M104 T0 S100, not M104 T0 S125.3. The extrusion cooling modifier is supposed to compensate for the heat loss while an extruder is extruding, so I suppose it affects the time at which CURA initiates the move to the final printing temperature in anticipation of the switch. That is, it should affect the placement of the M104 S180 that occurs while T0 is printing.
2. There were instances of .0 added to the temperature set point in the g-code. A bit more searching in the g-code file tells me that it occurs only in my startup g-code where I used S{material_standby_temperature,0} and S{material_standby_temperature,1}. It did not occur when I used S{material_print_temperature_layer_0, initial_extruder_nr}. This is a very minor item, since 100.0 and 100 are the same thing. It's probably a formatting issue. It happens that the standby temperature for both my materials has .0 in the field, but in the g-code file, I do not see the .0 in the file except in the startup g-code.

[Ghostkeeper]

Cura can think of "new" temperatures if it calculates that the stand-by temperature can't be reached in the allotted time. Here is a modified graph of what happens then:

Cura knows the estimated average cool down speed and heat up speed of the printer (machine_nozzle_cool_down_speed and machine_nozzle_heat_up_speed machine settings). If there is not enough time to cool down to the stand-by temperature and heat back up again to the Initial Printing Temperature, Cura will instruct the printer to cool down to the temperature that it thinks the printer can reach instead, based on the amount of stand-by time and the cooling and heating rates. This is how it ends up with temperatures like 125.3 in your case.

There's a good reason for it. You might think that we might as well instruct the printer to just cool down to 100°C and if it didn't actually reach that temperature that's fine too. Halfway through it would just heat back up again to the correct temperature. However Cura's cooling rate estimate is not always accurate, because other printer profiles often don't bother to edit it and because it's linear (designed as an estimate for the entire track between printing and stand-by temperature). That means that if Cura is wrong about the cooling rate and it cools down faster, the temperature of the nozzle will be lower than what Cura thinks it'll be. As a result, it will take longer to heat back up again and your print head will be stationary while it's waiting for the nozzle to heat up. While it's stationary, the other nozzle then also gets more time to cool down, and when that nozzle's stand-by temperature is set it'll also be lower than what Cura thinks it is, even moreso than before. This becomes a feedback loop where the printer needs to wait longer and longer at every nozzle switch.

Setting the stand-by temperature to what Cura expects will become the stand-by temperature breaks this feedback loop, so there is no runaway delay effect any more at every extruder switch.

I think the .0 is a side-effect of CuraEngine calculating the temperature that it'll be able to reach. Using floats and all, we just format the output with fixed-point precision regardless of whether it happens to be an integer. Could be slightly better, but nobody really cares about the 2 bytes you're saving here.

[bellzw]

That makes perfect sense. Consider this question answered. Thanks.