[4.8.0-beta] Option to remove decimals from temperature

[Gaweringo]

Cura 4.8.0 adds a .0 to the Printing and Build Plate Temperature.

This trailing 0 is not in the Print Settings of the material.
My printer (Monoprice Voxel/Flashforge Adventurer 3) interprets a number like 210.0 as 0 and thus tries to print with a room temperature nozzle and bed.

A solution would be to add an option that removes the decimal place. Probably in the Machine Settings.

The way of doing it now is to manually remove the decimal before every print. Which Cura then wants to save into the Profile.

Affected printers are, as stated earlier:

• Monoprice Voxel
• FlashForge Adventurer 3 (probably)

And if there already is a way to change this, please let me know.

[nallath]

I've tried changing the temperature a few times, but it only adds decimals when I explicitly add them myself.

Cura also doesn't have a voxel profile built in, so it could be that whatever profile that you use has something set up weird / incorrectly. Could you add some more information as to how you got o this state?

[Ghostkeeper]

This .0 may be visible in the interface (depending on whether the value was derived from a formula), but is not put in the actual g-code if the temperature is integer. In the g-code it says:

M104 S210

So the printers should not be affected.
Generally g-code parameters are allowed to be fractional. It's weird that your firmware would interpret 210.0 as "0".

[Gaweringo]

Here I removed the .0 from the Build Plate Temp and left it on the Printing Temp

The resulting .gcode looks like this:

M140 S50 T0
M104 S210.0 T0

I am using a custom Profile which I got from here: https://andybradford.dev/2020/01/12/using-the-monoprice-voxel-with-ultimaker-cura/

[nallath]

Oh right. It's the tag replacement of the start g-code that's causing this. Those don't get explicitly casted to ints.

I still don't see how you ever go to the .0 without you explicitly adding it though. I simply can't reproduce it.

[fieldOfView]

The temperatures are defined as floats. Would it make sense to make them ints instead?

[Gaweringo]

Now I'm confused. It now does the same on 4.7.1 which I don't remember it doing before. And I get the .0 when the Temp is calculated from the material I choose.
4.8.0:

4.7.1:

[Gaweringo]

It depends on the material Profile. Then Generic ones don't add a .0
eSun and my custom ones do add it:

In the Materials both don't have decimals:

[nallath]

For some reason, the esun profiles specifically define the temperature to be a float ending with .0 . No idea why they do that.

[Gaweringo]

FABtotum also has the .0.
Leapfrog only has it on the Build Plate Temp.
TiZYX has it on ABS and PETG. PVA and Flex only on Print Temp.
Velleman has .0 everywhere.

[Gaweringo]

The ChangeAtZ Post Processing Script also adds .0s when using it to change temperature.

[Ghostkeeper]

The temperatures are defined as floats. Would it make sense to make them ints instead?

Temperatures can be floats, normally. CuraEngine limits it to 1 decimal. Why this printer apparently breaks on it, I don't know.

[Ghostkeeper]

In some cases the profile value is float because it ends up from a calculated formula. This goes for most profiles as well as for the ChangeAtZ script. The only exception is what Nallath pointed out, the eSUN materials already write "190.0" and such in their profiles, which makes it a float even though it's not a calculated formula.

While CuraEngine properly shortens the float to just "190" then, the front-end doesn't do this in the replacement keys of the start g-code. A minor issue.

This doesn't solve the issue though. CuraEngine can still output fractional numbers willy-nilly, even if all of the profiles have integer values. For instance, if there isn't enough time to reach the stand-by temperature it'll instruct to cool down to the temperature that it thinks it can reach, which is computed from the cool down speed and the print duration and may be fractional. And normally that is fine, but apparently this printer firmware breaks on that.

[danilocesar]

I have the same problem that @Gaweringo has.

I have been doing a nasty workaround to deal with it:

[danilocesar]

Btw, this is easy to reproduce on new installations of cura, without any special profile: Has no relation with materials calculation.

To reproduce the issue, in a bare installation of cura 4.9.1 on Linux (Fedora 33 x86) do the following:
1 - Open Cura
2 - Add a custom FFF printer
3 - Use "M104 S{material_print_temperature_layer_0} T0" as Start GCode for the printer
4 - Add any stl file, slice it and save the result as gcode. See the GCODE file starts with "M104 S200 T0"

Now open the Expert print profile.

5 - Replace the first zero from "Printing Temperature Initial Layer" by the number two, the result will show 220.0
6 - Slice and save the gcode. See the GCODE now starts with "M104 S220.0 T0"

Now go over the print temperature Initial Layer again.
7 - Select and remove the ".0" part from the initial layer temperature. Leave the field and see that the result will show 220.0 again.
8 - Slice and save the GCODE. See that it now starts with "M104 S220 T0" again.

So I believe this troubleshooting shows two things:
1 - There's a minor interface inconsistency as the input value doesn't proper reflect what is being stored. It always shows the decimal point even tough sometimes it's not holding a decimal point.
2 - This problem can only be reproduced when replacing variables in the START GCODE section like {material_print_temperature_layer_0}. All other interaction and usages of M104 will use it without decimal point.

All that said: Clearly Adventurer 3 can't handle decimal points when setting temperatures. It's a known issue. While this is true,
the problem I described is not restricted to the profile that @Gaweringo is using or only to Adventurer 3 printers.

[Ghostkeeper]

1 - There's a minor interface inconsistency as the input value doesn't proper reflect what is being stored. It always shows the decimal point even tough sometimes it's not holding a decimal point.

This is not entirely true here. The interface shows what is being stored, but it doesn't always store what you fill in. If the number you fill in is equal to the default from the profile, it doesn't store it as an override. Even if the profile holds a floating point type and what you type is integer.

2 - This problem can only be reproduced when replacing variables in the START GCODE section like {material_print_temperature_layer_0}. All other interaction and usages of M104 will use it without decimal point.

No, Cura will also output fractional temperatures when there is not enough time to reach the stand-by temperature in multi-extrusion prints, even if all of the settings are integer. What's more, the user can still type in fractional temperatures. So fixing the start g-code is no guarantee that there will not be any fractional temperatures in the output.

The only real solution is to have a machine setting to determine whether the printer firmware supports fractional temperatures or not. I.e. effectively what the title of this issue asks for. That is a detail which we won't be implementing since it is only applicable to third-party printers that we can't test with nor have any incentive for. Pull requests are welcome, but we can't implement this on Ultimaker's time. Sorry! I'll have to defer this.

[themorfeus]

If anyone is working on a PR for this, or is willing to point me to where the related things are in the code i'd be glad to help with this issue.

[Ghostkeeper]

That would be in the GCodeExport::writeTemperatureCommand function in CuraEngine: https://github.com/Ultimaker/CuraEngine/blob/530d97b7c8322962c523d4e860b91dee9390dbde/src/gcodeExport.cpp#L1251

Or in the case of the start g-code, in the StartSliceJob._expandGcodeTokens function:

Cura/plugins/CuraEngineBackend/StartSliceJob.py

Line 379 in d5d1633

def _expandGcodeTokens(self, value: str, default_extruder_nr: int = -1) -> str:

[vasilp]

Practically no one will need to setup so precisely the temperatures, so there is not practical need to be with fractional values.
I think these properties should be changed to integers (whole numbers)! Backward compatibility would be easily solved by rounding of course.

[github-actions]

Hi 👋,
We are cleaning our list of issues to improve our focus.
This feature request seems to be older than a year, which is at least three major Cura releases ago.
It also received the label Deferred indicating that we did not have time to work on it back then and haven't found time to work on it since.

If this is still something that you think can improve how you and others use Cura, can you please leave a comment?
We will have a fresh set of eyes to look at it.

If it has been resolved or don't need it to be improved anymore, you don't have to do anything, and this issue will be automatically closed in 14 days.

[danilocesar]

I don't think it's worth pursuing this as it was a workaround to fix an issue with the flashforge firmware.

[Swamp-Ig]

I would like to see this fixed, it should a pretty simple fix. I can probably provide a PR if required.

[Swamp-Ig]

Actually... scratch that. It looks like the M140 and M104 lines can just be left out of the start G-code and the start temps get generated.

I'm going to create a plugin for the adventurer, I'm doing it bit by bit.

[eldade]

I don't think it's worth pursuing this as it was a workaround to fix an issue with the flashforge firmware.

My Guider 2S continues to suffer from this problem on its latest firmware, in 2024. So while I get that MOST printers accept the floating point temperature format, clearly many FlashForge printers do not.