Prepend Temperature Error

[GregValiant]

Cura Version

5.7.2

Operating System

Windows 10 Pro

Printer

Non-Ultimaker

Reproduction steps

Create a StartUp Gcode with Replacement Patterns for the bed and hot end temperatures

Actual results

The Prepend temperature for the hot end is added regardless of the Replacement Patterns in the StartUp. The bed temperature seems to be OK. ;Generated with Cura_SteamEngine 5.7.2 M104 S200 M105 M109 S200 M82 ;absolute extrusion mode ; Init Print 200 Init Bed 60 Print 200 Bed 60 ;

Expected results

Given that both the Hot End and Bed Temps were called out in the StartUp there should be no prepend. ;Generated with Cura_SteamEngine 5.7.2 M82 ;absolute extrusion mode ; Init Print 200 Init Bed 60 Print 200 Bed 60 ;

Add your .zip and screenshots here ⬇️

Project file using a Tevo Tornado. The issue seems to occur with any non-Ultimaker printer. The issue is not present in 5.7.1 or previous versions. This may be a Cura Engine problem. Prepend Temperature Error.zip

[kamermans]

I have also experienced this bug, which is quite troubling as it leaves my extruder at 260 for minutes while I wait for the adaptive bed mesh to complete. I too noticed it only after upgrading to 5.7.2.

[kamermans]

Here's my test project, gcode and screenshots as another data point: test.zip

As you can see, the M104 get injected despite the presence of {material_bed_temperature} and {material_print_temperature} (I was using {material_bed_temperature_layer_0} and {material_print_temperature_layer_0} before, but they also don't work now).

[robertaramar]

I also ran into this. I guess the bug could be here in plugins/CuraEngineBackend/StartSliceJob.py: bed temperature is compared with '==' but print temperatures with 'is' But that's already in there for three years, so that wouldn't explain why it only surfaced in 5.7.2

[GregValiant]

I saw that as well and a comparison with the same file in 5.7.1 showed no changes.

I noticed that if I turn off "Enable Nozzle Temperature Control" the problem goes away. That might be an OK workaround for single extruder printers. They don't use "Heat up time" or "Cool down time" anyway.

[rmeissn]

@GregValiant Where is this option supposed to be? I can't find it within the settings (hide/show) view and there is no machine option called this way.

[GregValiant]

Sorry about that... Go to the MarketPlace and install the plugin "Printer Settings". After restarting Cura there will be an additional setting group added below "Experimental".

[kamermans]

I also ran into this. I guess the bug could be here in plugins/CuraEngineBackend/StartSliceJob.py: ... bed temperature is compared with '==' but print temperatures with 'is' But that's already in there for three years, so that wouldn't explain why it only surfaced in 5.7.2

Good find @robertaramar , but in Python re.search() returns exactly None if there is not a match, so == None and is None will have the same behavior in this case.

[bellzw]

I just observed the same issue. With 5.1.0: ;Generated with Cura_SteamEngine main T0 M82 ;absolute extrusion mode ; Start of BIBO startup code M140 S60 M104 T0 S175.0 M104 T1 S150.0 G21 ;metric values G90 ;absolute positioning M107 ;start with the fan off T0 G92 E0 G28 G1 Y0 F1200 E0 T1 G92 E0 ;set extruder 2 position to 0 M109 T0 S175.0 ; now wait for E1 to reach temperature M109 T1 S150.0 ; now wait for E2 to reach temperature M109 T0 S200.0 ; now set the correct extruder to the correct initial temperature T0 M190 S60 M117 BIBO Printing...

With 5.7.2: ;Generated with Cura_SteamEngine 5.7.2 T0 M104 S200 <------- M105 <------- M109 S200 <------- M82 ;absolute extrusion mode ; Start of BIBO startup code M140 S60 M104 T0 S175.0 M104 T1 S175.0 G21 ;metric values G90 ;absolute positioning M107 ;start with the fan off T0 G92 E0 G28 G1 Y0 F1200 E0 T1 G92 E0 ;set extruder 2 position to 0 M109 T0 S175.0 ; now wait for E1 to reach temperature M109 T1 S175.0 ; now wait for E2 to reach temperature M109 T0 S200.0 ; now set the correct extruder to the correct initial temperature T0 M190 S60 M117 BIBO Printing...

The different T1 temps, above, are because I had different materials on T1 in 5.1.0 and 5.7.2, and are not important because this particular print only used T0.

The startup code is the same in both Cura versions: ; Start of BIBO startup code M140 S{material_bed_temperature_layer_0} M104 T0 S{material_standby_temperature, 0} M104 T1 S{material_standby_temperature, 1} G21 ;metric values G90 ;absolute positioning M107 ;start with the fan off T0 G92 E0 G28 G1 Y0 F1200 E0 T1 G92 E0 ;set extruder 2 position to 0 M109 T0 S{material_standby_temperature, 0} ; now wait for E1 to reach temperature M109 T1 S{material_standby_temperature,1} ; now wait for E2 to reach temperature M109 T{initial_extruder_nr} S{material_print_temperature_layer_0, initial_extruder_nr} ; now set the correct extruder to the correct initial temperature T{initial_extruder_nr} M190 S{material_bed_temperature_layer_0} M117 BIBO Printing...

Unfortunately for me, the BIBO printer is dual extruder, so not having Cura guess as to when to cool a nozzle in preparation for a switch won't be a work around. For now, I just delete the lines I marked above with a text editor since I know they're there.

[GregValiant]

@HellAholic have you noticed this one?

[bellzw]

Update of my previous comment:

I looked through the Printer Settings section and noticed that both Wait for Build Plate Heatup and Wait for Nozzle Heatup were checked in 5.7.2 AND 5.1.0. However, if I uncheck Wait for Nozzle Heatup, 5.7.2 generates:

;Generated with Cura_SteamEngine 5.7.2 T0 M104 S200 <------- M82 ;absolute extrusion mode ; Start of BIBO starutp code M140 S60 M104 T0 S175.0 M104 T1 S175.0

Only a fairly innocuous M104 is generated, which gets changed very shortly after in my startup code. The Wait for Build Plate Heatup does not affect the insertion of the M104/M105/M109. This may be a better work around for 2-nozzle printer users until the issue is fixed.

I don't think this is the root cause of the error since both settings are enabled in 5.1.0, and probably other versions below 5.7.2.

[GregValiant]

That first M104 line is part of the Prepend and shouldn't be there if there are temperature keywords in the StartUp. Your M104 S175 lines look like they might be "M104 S{material_standby_temperature}" in the StartUp. The problem arises with printers that have auto-bed-leveling as the original M104 S200 would allow the nozzle to ooze during the leveling travels. Something changed and I'm not familiar enough with the code to dig it out. I always preheat the nozzle and bed because I level with a piece of paper so the extra lines don't affect how I do things. They certainly would affect some people.

Either the temperatures are handled in the StartUp, OR they are handled by the prepend. They should not be handled by both which would lead to a double dip, and that looks like what is occurring.

The problem may have arisen when the StartUp gcode was altered to allow for some logic functions. That may have changed the regular expression patterns that are being used.

[kamermans]

For what it's worth, I notice it when upgrading from 5.6.0 to 5.7.2, so I can't personally confirm which version broke it. I'll try to test 5.7.1 tonight.

[bellzw]

I agree that the M104 200 put in by Cura should not be there since there are M104 and M109 codes in the startup. At least unchecking the wait box in the settings removes the need for me to edit the gcode file; I don’t think Cura’s M104 causes any problems for me if it’s there. The problem is undoubtedly related to parsing the startup code. It was a RE pattern/function issue that caused a problem processing {param 1, param 2} in the startup code.

You are correct about my startup code. It first starts both extruders toward their standby temperatures and the bed heating while it homes the axes and extruders. Then, after the extruders have reached standby temperature, it sets the initial extruder to the layer 0 print temp, waits for it, and then waits for the bed to reach temperature.

I also level with a piece of paper or a 0.004” spark plug feeler gauge, whichever I find first, when the nozzle(s) and bed are at temperature, but I do that off line. My experience has been that my printer doesn’t need to have the bed leveled very often, so I do it when a print shows signs of something being amiss.

From: GregValiant @.> Sent: Tuesday, June 11, 2024 12:50 PM To: Ultimaker/Cura @.> Cc: bellzw @.>; Comment @.> Subject: Re: [Ultimaker/Cura] Prepend Temperature Error (Issue #19204)

That first M104 line is part of the Prepend and shouldn't be there if there are temperature keywords in the StartUp. Your M104 S175 lines look like they might be "M104 S{material_standby_temperature}" in the StartUp. The problem arises with printers that have auto-bed-leveling as the original M104 S200 would allow the nozzle to ooze during the leveling travels. Something changed and I'm not familiar enough with the code to dig it out. I always preheat the nozzle and bed because I level with a piece of paper so the extra lines don't affect how I do things. They certainly would affect some people.

Either the temperatures are handled in the StartUp, OR they are handled by the prepend. They should not be handled by both which would lead to a double dip, and that looks like what is occurring.

The problem may have arisen when the StartUp gcode was altered to allow for some logic functions. That may have changed the regular expression patterns that are being used.

— Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/19204#issuecomment-2161208529 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AMFTMULU57PX3JUS6NTNQDLZG4TDPAVCNFSM6AAAAABJAG3U3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRRGIYDQNJSHE . You are receiving this because you commented. https://github.com/notifications/beacon/AMFTMUNR25AUTLIJUGYJZ2LZG4TDPA5CNFSM6AAAAABJAG3U3OWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUA2FWNC.gif Message ID: @. @.> >

[kamermans]

I've installed 5.7.1 and I do not see the issue, so as far as I can tell, this appeared in 5.7.2, which is very strange since none of the changes seem to be relevant.

Let me know if you want me to test anything.

[GregValiant]

I hadn't noticed it but I wasn't using 5.7.2 much as it always brings up the "Welcome" dialogs which need to be dismissed. That's more annoying to me than the prepend thing.

For people who want the hot end at standby during leveling - maybe replacing the M104 S or M109 S (that comes before the leveling command in the StartUp) with M109 R would work. It would cause the printer to wait until the temperature gets down to standby before doing the leveling.

I always run some post-processors so I added a little script that just comments out the 3 lines.

[HellAholic]

@GregValiant Thanks for the report, Ticket for investigation/internal reference: CURA-11961

[wawanbreton]

Hi, We did make a change about this in 5.7.2. There is actually a setting called material_print_temp_prepend or "Include Material Temperatures", which is a printer one, so not easily editable. But is was ignored in the engine for Griffin-flavored G-Code, until now. However the description cleary says that it should be forcibly set to False if the start gcode already contains temperature commands, so that is indeed a possible bug that is present for a long time, but was not really visible because the engine ignored it anyway.

[GregValiant]

Not fair. Was this "Invisible and Inaccessible Setting" a test to see if anyone was paying attention?

I see "material_print_temp_prepend" in fdmprinter, but can't make it appear in Cura. It is missing from the "Setting Visibility" list even when I change ""enabled":" to "true". In addition, when I hardcoded "enabled" to "true" - "Manage Printers" broke.

My preference would be: Prepending the bed and hot end temperatures is enabled by default. BUT If the hot end temperature keywords are in the StartUp, don't prepend the hot end temps. If the bed temperature keywords are in the StartUp, don't prepend the bed temps.

[wawanbreton]

Prepending the bed and hot end temperatures is enabled by default. BUT If the hot end temperature keywords are in the StartUp, don't prepend the hot end temps. If the bed temperature keywords are in the StartUp, don't prepend the bed temps.

That is exactly what is supposed to happen, which is why this change shouldn't have had that much impact. So we do have a bug somewhere in this process, because the setting is not automatically disabled as advertised.

[GregValiant]

@kamermans , @bellzw , @robertaramar , @rmeissn Here is a little script to fix the bug. Unzip and stick "CuraPrependBugFix.py" into the "scripts" folder in your Configuration Folder. Let me know if there are issues. CuraPrependBugFix.zip

[kamermans]

Thanks @GregValiant, I'll give it a go when I get home 👍

[bellzw]

Worked for one STL I sliced:

;Generated with Cura_SteamEngine 5.7.2 T0 M82 ;absolute extrusion mode ; Start of BIBO startup code

Thanks @GregValiant.

[bellzw]

Even if material_print_temp_prepend and material_bed_temp_prepend are set to false in my printer’s definition, the M104/M105/M109 are still prepended. I added

    "material_print_temp_prepend": {"default_value": false},

    "material_bed_temp_prepend": {"default_value": false},

to my printer’s definition, but there was no change in 5.7.2’s behavior.

From: Erwan MATHIEU @.> Sent: Wednesday, June 12, 2024 7:45 AM To: Ultimaker/Cura @.> Cc: bellzw @.>; Comment @.> Subject: Re: [Ultimaker/Cura] Prepend Temperature Error (Issue #19204)

Prepending the bed and hot end temperatures is enabled by default. BUT If the hot end temperature keywords are in the StartUp, don't prepend the hot end temps. If the bed temperature keywords are in the StartUp, don't prepend the bed temps.

That is exactly what is supposed to happen, which is why this change shouldn't have had that much impact. So we do have a bug somewhere in this process, because the setting is not automatically disabled as advertised.

— Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/19204#issuecomment-2162801365 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AMFTMUOIFFG3YFAWNLJKV3LZHAYDHAVCNFSM6AAAAABJAG3U3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRSHAYDCMZWGU . You are receiving this because you commented. https://github.com/notifications/beacon/AMFTMUPNSNSZLZOG7Y4BPUDZHAYDHA5CNFSM6AAAAABJAG3U3OWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUA5G5NK.gif Message ID: @. @.> >

[kamermans]

@kamermans , @bellzw , @robertaramar , @rmeissn Here is a little script to fix the bug. Unzip and stick "CuraPrependBugFix.py" into the "scripts" folder in your Configuration Folder. Let me know if there are issues. CuraPrependBugFix.zip

No luck for me @GregValiant

I did some debugging, and I see that although the code is loaded, only the function getSettingDataString is called. The execute function never gets called for me.

Happy to troubleshoot for/with you if you want.

To clarify, I put the Python script here: %APPDATA%\cura\5.7\scripts

[GregValiant]

That's where it goes. Did you install it in the post-processor list? ("Extensions / Post Processing / Modify Gcode" - Add Script) It runs for me and it appears that it runs for bellzw. If it's enabled and loaded as a post-processor it will run when you save the file to disk. When I added those "self.log" lines Cura wouldn't load it at all.

[kamermans]

Oh, thanks @GregValiant, that did the trick :) This is my first time adding a script to Cura, now I just need to resist the urge to poke around in here 😅

[GregValiant]

The script "Advanced Cooling Fan Control" is one of mine. It's a piece of work. I have a lot of post-processors and 6 are always loaded. The one I call "Little Utilities" has 21 separate scripts in it for all kinds of crap. The latest addition will move the purge lines to different edges of the build surface (in case a model is near the left edge) and another will move the print head around the periphery of the build surface to the layer start point so it doesn't string across the area where the print will be. That was surprisingly hard to do for round bed printers. I'm still not 100% happy with it. If you want to play with it, here it is. Under the "Bug Fixes" is that "Prepend" fix. It's the same code, just a different wrapper. You can run one or the other. If you use Purge Line script you must remove the purge lines from your startup gcode. You don't want to double dip. LittleUtilities_v19.zip I had to make this dialog box longer to fit everything in. There will be a scroll bar in yours.

[kamermans]

Nice, thanks!

[shmaque]

@kamermans , @bellzw , @robertaramar , @rmeissn Here is a little script to fix the bug. Unzip and stick "CuraPrependBugFix.py" into the "scripts" folder in your Configuration Folder. Let me know if there are issues. CuraPrependBugFix.zip

Thanks! I was chasing my tail on this tonight as well!

[wawanbreton]

Even if material_print_temp_prepend and material_bed_temp_prepend are set to false in my printer’s definition, the M104/M105/M109 are still prepended. I added "material_print_temp_prepend": {"default_value": false}, "material_bed_temp_prepend": {"default_value": false}, to my printer’s definition, but there was no change in 5.7.2’s behavior.

Yeah it seams that this setting is completely overwritten (with a wrong value) when sent to the engine, as pointed out by @robertaramar. So the only way to disable it right now is to change the code :grimacing: The bug is on our backlog, I'll make sure it is on the top.

[MikeOxawopper]

@GregValiant This appears to be a variation of what i have reported, i must have missed this thread.

I can confirm in my case that Version 5.7.1, 5.6.0 5.3.1 all work as expected it is only 5.7.2 that has the odd behavior.

my Cura custom start gcode is START_PRINT BED_TEMP={material_bed_temperature_layer_0} EXTRUDER_TEMP={material_print_temperature_layer_0} Which is the same in 5.3.1, 5.6.0 and 5.7.1

The START_PRINT macro is the same one i have been using for 18 months or so

The GCode produced by 5.7.1 is ; Pre-Processed for Cancel-Object support by preprocess_cancellation v0.2.0 ; 1 known objects EXCLUDE_OBJECT_DEFINE NAME=Left_Block_stl CENTER=129.853,116.942 POLYGON=[[65.021,85.952],[65.021,156.948],[195.28,156.948],[195.28,85.952]] M82 ;absolute extrusion mode START_PRINT BED_TEMP=60 EXTRUDER_TEMP=210 G92 E0 G92 E0 G1 F2100 E-0.5

while 5.7.2 adds some random heater commands ; Pre-Processed for Cancel-Object support by preprocess_cancellation v0.2.0 ; 1 known objects EXCLUDE_OBJECT_DEFINE NAME=Right_Guide_Block_2_stl CENTER=127.487,113.048 POLYGON=[[53.665,64.905],[53.665,167.19],[210.002,167.19],[210.002,64.905]] M104 S210 M105 M109 S210 M82 ;absolute extrusion mode START_PRINT BED_TEMP=60 EXTRUDER_TEMP=210 G92 E0 G92 E0 G1 F2100 E-0.5

[MikeOxawopper]

I've added the prepend script and normal service seems to have been resumed.

[GregValiant]

FYI The script removes any M109, M104, M190, M140, and M105 lines up until it encounters the M82 line. At that point it exits.

[MikeOxawopper]

@GregValiant i don't use those natively in my start gcode so i didn't want them added in the 1st place My macro uses bed temp and extruder temp from material settings

[GregValiant]

The function of the Prepend code is to add heating commands for the bed and hot end as a safety to prevent the possibility of attempting to extrude with a cold hot end and/or print on a cold bed. When Cura keywords appear in the StartUp Gcode, (whether they are part of EXTRUDER_TEMP or M104 S or M140 S) Cura is supposed to refrain from adding the prepend temperature lines because they aren't needed. That's the bug here in 5.7.2...Cura is adding them regardless.

As wawabreton explained, the setting to add the prepend is being passed with an incorrect value and so those lines (M104, etc.) are always being added. The result is the hot end is going to the Initial Temperature and would be there during leveling and cause the hot end to ooze all over the build plate. The bug won't hurt anything, but it can be messy.

[MikeOxawopper]

with the PREPEND script in place i have normal operation restored

[MariMakes]

👋 Quick update on our side. This is resolved in the 5.8 release 🎉 , you can download the Beta version with the fix here: https://github.com/Ultimaker/Cura/releases/tag/5.8.0-beta.1

I'll close this issue since it's resolved. Thanks again, and please let us know if you run into any other issues 💪