Prepend Temperature Error #19204
Comments
GregValiant
added
Type: Bug
|
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. |
|
Here's my test project, gcode and screenshots as another data point: test.zip
As you can see, the |
|
I also ran into this. |
|
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. |
|
@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. |
|
Sorry about that... |
Good find @robertaramar , but in Python |
|
I just observed the same issue. With 5.1.0: With 5.7.2: 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: 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. |
|
@HellAholic have you noticed this one? |
|
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 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. |
|
That first M104 line is part of the Prepend and shouldn't be there if there are temperature keywords in the StartUp. 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. |
|
For what it's worth, I notice it when upgrading from |
|
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 <#19204 (comment)> , 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: ***@***.*** ***@***.***> >
|
|
I've installed Let me know if you want me to test anything. |
|
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. |
|
@GregValiant |
|
Hi, |
|
Not fair. 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: |
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. |
|
@kamermans , @bellzw , @robertaramar , @rmeissn |
|
Thanks @GregValiant, I'll give it a go when I get home 👍 |
|
Worked for one STL I sliced: ;Generated with Cura_SteamEngine 5.7.2 Thanks @GregValiant. |
|
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 <#19204 (comment)> , 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: ***@***.*** ***@***.***> >
|
No luck for me @GregValiant I did some debugging, and I see that although the code is loaded, only the function Happy to troubleshoot for/with you if you want. To clarify, I put the Python script here:
|
|
That's where it goes. |
|
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 😅 |
|
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. |
|
Nice, thanks! |
Thanks! I was chasing my tail on this tonight as well! |
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 😬 |
|
@GregValiant 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 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 while 5.7.2 adds some random heater commands |
|
I've added the prepend script and normal service seems to have been resumed. |
|
FYI The script removes any M109, M104, M190, M140, and M105 lines up until it encounters the M82 line. At that point it exits. |
|
@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. 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. |
|
with the PREPEND script in place i have normal operation restored |
MariMakes
added
Status: On Backlog
|
👋 Quick update on our side. I'll close this issue since it's resolved. |
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
The text was updated successfully, but these errors were encountered: