[Suggestions] Minimum layer time improvements. minimum layer time/minimum speed lift improvements, improved warnings to user

[Sophist-UK]

Application version
4.60

Platform
Windows 10 64-bit

Printer
Dagoma DiscoEasy200

This issue was logged as a consequence of a charred print, however the initial analysis about missing retractions was incorrect - nevertheless some potential suggestions for improved handling of minimum layer time and fans did come out of the discussion and consequently this description (and the title) have been updated to reflect the outcome of the extended discussion below.

Suggestions

1. The purpose of minimum layer time is to allow the last layer to cool sufficiently before printing the next layer. However it seems to me that this depends on whether the layer is an unsupported overhang or not:

   • If it is not an overhang, then it needs to cool past the glass point in order that the new layer doesn't distort the previous layer.
   • However if it is an unsupported overhang, you actually want the print to be as stiff as possible so that the overhang is not pushed down by the extrusion i.e. you want it to be a lot cooler.

   So perhaps Cura should have two minimum layer times, one without unsupported overhangs and one with.

   (Playing devil's advocate, it could be argued that if you have a problem with unsupported overhangs being pushed down and getting distorted printing, then the answer is to use supports. My arguments against this are a) that supports create surface markings, so better to print without supports if at all possible; and b) that ideally you want to be able to create a profile which gives good prints in as many different circumstances as possible without tweaking for every print. But I am open to being persuaded.)

2. When a layer is so small that slicing it at the minimum printing speed still takes less than the minimum layer time, Cure does a retract and lift. When it does this, there should be an option to move somewhere where any drips from the nozzle will not land on the print or at least not land on either outer walls or top surfaces.

3. In the minimum speed / minimum layer time situation where lifts are needed, then Cura should warn the user that lifts and retractions were needed, and this message should also identify whether these lifts are for overhangs or not as per point 1.

4. Because lifts in these situations are likely to be for every layer and because each layer is extruding only a small amount of filament because that is what is triggering the minimum speed / minimum layer time, it is possible that the maximum retraction count gets exceeded and retractions are omitted leading to a greater risk of oozing. In these circumstances the user should be warned that lifts without retractions might result in oozing.

Original title and Description for historical purposes

Oozing and charring on minimum layer time - retraction needed as well as head lift

Reproduction steps

1. Print something with small layers and 20s min layer time.

Actual results
Head lifts, filament oozes creating a small amount of spaghetti. The PLA chars in the nozzle as it slowly oozes.

Expected results
FILAMENT RETRACTS then head lifts.

[mahtDFR]

Just a heads up - we can of course review pull requests, but we won't be able to put our development time into this as it's a third party machine. I'll mark it as deferred.

It may help to include a project file with this issue so other members of the community can test this with the same settings as you.

[Sophist-UK]

The fact that I print on a 3rd party printer is not relevant. This issue will effect Ultimaker printers as much as it will effect any other make of printers. It is bad functionality as oozing (and possibly charring) is a predictable consequence of doing a lift without a retraction - IMO a retract should always have been included in the functionality.

However, I do understand that minimum layer time is not a frequently used functionality, and that a fix is therefore going to have a lower priority than other more important development.

[Ghostkeeper]

I'd indeed expect it to retract. It does call the normal retraction routine there:

https://github.com/Ultimaker/CuraEngine/blob/cda97df76ed1a7f00963086fa1b80c84567ee1a9/src/LayerPlan.cpp#L1728

This should retract even if retraction is disabled (which may not be what the user would expect), unless the retraction distance is 0 or there have been too many retractions recently such that the feeder would wear through the filament.

And indeed I am seeing a retraction. This is a snippet of g-code that I get when I perform the spirit of your reproduction steps. Some comments are mine:

G1 F900 X115.069 Y107.173 E9.05668    ;<-- Last extrusion move, E is at 9.
M204 S5000
M205 X30 Y30
G0 F15000 X115.136 Y107.107
;MESH:NONMESH
G0 F600 X115.136 Y107.107 Z3.47       ;<-- Move to next layer
G0 F15000 X116.009 Y107.5
;Small layer, adding delay
G1 F1500 E2.55668                     ;<-- Retraction!
G0 F15000 X116.009 Y107.5 Z6.47       ;<-- Lift nozzle
G0 X136.009 Y107.5
G4 P3063                              ;<-- Pause for 3 seconds.
;TIME_ELAPSED:211.385380
;LAYER:32

Project file (for 4.7, sorry): retraction_before_lift_nozzle.zip

Do you have a project file that reproduces your bug?

[Sophist-UK]

I have to admit that lack of retraction was an assumption on my part to explain the amount of oozing and the charred filament - I don't normally get these when I have the nozzle hot between prints - so unclear why I am getting them during minimum layer time lifts.

Retraction distance was not 0 - retractions had been happening perfectly without printing defects for the whole of the rest of the 10 hour print - but as it got to the small area at the highest point of the object it reached minimum layer time and started to lift but without a retraction - but of course when you have a small area you are not going to extrude much per layer, so you can easily reach this limit when you don't in the main model.

However, looking at my actual settings, a maximum of 90 retractions in a window of 5mm it seems to me to be unlikely that I hit the limit (not the least of which because you can only get 1 lift per layer, so I would have to have had 90 layers of minimum layer time to even get close).

Tomorrow I will generate the GCODE and review it to see what Cura is asking the printer to do.

But in the mean time some questions to prompt us all to think...

a. Retraction is normally for travel - a short period of time. A lift is for a longer time - do we need a greater retraction distance for minimum layer lifts in order to reduce oozing?

b. Should we provide settings to allow for a lower nozzle temp during minimum layer time slowdowns / pauses in order to reduce oozing?

c. Should we try to move the print head over a blank area of the bed during the lift so that oozed filament is not deposited on the print?

d. (Not the problem in my case, but) Should we ignore the retraction count limit during minimum layer time lifts?

Thanks in advance.

[Sophist-UK]

Ok - I saved the Gcode file (I normally print via USB) and have extracted the minimum wait layers at the end. And I am confused.

The last 18 layers have triggered minimum print - and the first 13 of these don't have a retraction, but the last 5 do.

In these 18 layers there are a total of 93 retractions over a total filament length of 46.02018mm of filament - so it seems VERY unlikely that it is the 90 retractions per 5mm which is the problem. Indeed, more than the 5mm is used in the first of the minimum layer time layers, so the second of these layers should definitely have a retraction. I am enclosing the gcode for these last 18 layers.
minimum layer time gcode.zip

Looking at the slicer engine code you pointed to, it seems unlikely that the extruder plan is going to change between layers as mine is a single extruder machine. And in any case the rest of the lift code is written just fine. So if there is a bug it will be in gcode.writeRetraction.

I have looked at this code in src/gcodeExport.cpp and cannot see why this would happen some of the time and not others. But I have submitted a PR Ultimaker/CuraEngine#1295 to give an explanation of why a retract was cancelled.

[Ghostkeeper]

The minimum layer time is 5 seconds by default. Even if you spend only half of that printing, the lift duration is not a whole lot longer than a travel move with combing or z-hop. I don't think it really warrants having a different retraction distance. I don't think a lot of people would try optimizing that parameter. And certainly not change the temperature, because that would cause the PID regulator to go haywire, changing temperatures every 2.5 seconds. I also think that in many cases, travelling back and forth to a purge bucket is probably going to take longer than the pause itself. Currently it moves to a hard-coded offset position of the last known position (X+20, Y+0, Z+3). It's 3mm in the air, so it would have to ooze pretty bad before it hits any wall.

We can ignore the retraction count limit, at the small risk of losing grip on the filament due to many retractions (e.g. when there are many small layers in a row). I don't think people will really hit this retraction count limit though, because if their layers print that quickly, they are probably small and don't have a lot of parts, so they don't use many retractions.

[Sophist-UK]

@Ghostkeeper - I agree with your analysis of my earlier possible suggestions. However my later comment supersedes this because it shows that the issue is NOT that retraction doesn't happen during minimum layer time lifts, but that this is not happening consistently.

I have no idea what is causing this - and haven't found code issues that would account for it.

[Ghostkeeper]

Looking at your g-code, I think it's just an oversight because the retractions are there, just a while earlier. Take for instance the first nozzle lift. Here's a snippet (with my added comments again):

G1 F4800 X79.743 Y121.64 E3196.18239      ;<-- Last extrusion move, a skin line.
G1 F3000 E3191.18239                      ;<-- Retraction!
;MESH:NONMESH
G0 F240 X79.743 Y121.64 Z25.06            ;<-- A whole bunch of travel moves to get to the start of the next layer.
G0 F9000 X80.252 Y121.213
G0 X80.84 Y121.931
G0 X80 Y122.778
G0 X59.284 Y109.391
G0 X48.961 Y97.922
G0 X48.195 Y91.324
G0 X48.929 Y90.7
;Small layer, adding delay
G0 X48.929 Y90.7 Z28.06                   ;<-- Nozzle lift.
G0 X68.46 Y95.002
G4 P1749                                  ;<-- Pause 1.7s.
M117 Time Left 0h 7m 9s
;LAYER:248
M117 Layer 249 of 266 phaser_side2_repaired
;MESH:phaser_side2_repaired.stl
G0 X48.929 Y90.7 Z25.06
;TYPE:WALL-OUTER
G1 F3000 E3196.22396

So indeed it's not retracting for the nozzle lift, because it's already retracted a while back to make those travel moves.

[Sophist-UK]

I'll take another look and check.

But if that is the case, then we need to go back to the previous comment about how to reduce ooze and char during a lengthy retraction period for a lift (cf. a short retraction period for travel - and which can be managed by combing settings). The problem with ooze is that it has two consequences. 1. Oozing onto the print causing quality blemishes. 2. Under extrusion immediately following.

I think my minimum layer time is 30s - I increased to 30s to ensure that the small area has cooled sufficiently and (if an overhang) stiffened sufficiently before printing the next layer. However 30s might well be higher than needed, and if I reduce the minimum layer time then I reduce the lift period. I can also allow slower printing to avoid lifts.

But since minimum layer time is to ensure print has cooled sufficiently, perhaps we should turn the fan on when minimum layer period is triggered (either slow down or lift) in order to cool the previous layer as much as possible and allow the minimum layer time to be lower.

Of the possible mitigations so far, here is my summary:

1. Move outside the build volume (to the purge bucket if it exists - otherwise just outside the build volume) in order to avoid oozing onto the print. Travels are usually quick so this would not be too time consuming.

2. (CLOSED) Additional retraction - on further research, I have heard talk of issues with blockages because the retracted filament has strings and if they cool too much you can get blockages - if this might have unintended consequences because the filament cools too much, we should probably avoid it.

3. (CLOSED) Lower temp - agreed that this is not a good idea.

4. (CLOSED) Ignore retraction maximum - this risks unintended consequences of filament then breaking or slipping, and I now think not.

5. (NEW) Fan on during slowdown / lift - is there an existing setting we can use for this?

6. (NEW) Warning of lifts shown during Slicing - so user is given a chance to tweak settings?

[Ghostkeeper]

1 - We're not allowed to move outside of the build volume. Moving to a custom location within the build volume is possible though. I don't think a lot of people would customise that either though. The head lift routine is a very minor detail to most people, and the 20mm move works fine for almost every print. Unless you really are oozing more than 3mm down of course. We could opt to use the Z hop height rather than always use those 3mm, maybe?

5 - There is, the Maximum Fan Speed.

6 - Your pull request to add comments for every missed retraction probably won't get merged. We see this as debugging information that really doesn't belong in the g-code for everyone. For people that actually do want to debug CuraEngine we're considering a compilation flag or maybe a hidden (machine-ish) setting. It raised some discussion. We'll come back on that PR.

Were you able to look through your g-code to find the retractions?

[Sophist-UK]

1. Better to prevent oozing in the first place I think.

2. Why does Maximum Fan Speed apply during minimum layer time?

3. Personally I believe that people need to be able to read Gcode so comments on each Gcode should not be necessary.

However, when Gcode that is expected is cancelled, then I think a comment should be included explaining why the expected Gcode is missing.

[Ghostkeeper]

The Maximum Fan Speed is defined as the setting that applies during minimum layer time. See this diagram:

Above the Regular/Maximum Fan Speed Threshold, the Regular Fan Speed applies. Between the Regular/Maximum Fan Speed Threshold and the Minimum Layer Time, it interpolates between the Regular and the Maximum Fan Speed. At the Minimum Layer Time, the Maximum Fan Speed applies. So as you approach the minimum layer time, it should gradually increase the fan speed. If you're at the Minimum Layer Time and the print speed is being reduced, it should always be using the Maximum Fan Speed. The Maximum Fan Speed should pretty much always be 100% except for materials with very high shrinkage ratios that would warp the model if they are cooled down too fast.

I think users shouldn't need to be able to read g-code to debug their retraction problems. Layer view is preferred.

Did you look through your g-code to find the missing retractions?

[Sophist-UK]

I did find the retractions.

Another couple of ideas I had is this:

1. The purpose of minimum layer time is to allow the last layer to cool sufficiently before printing the next layer. However it seems to me that this depends on whether the layer is an unsupported overhang or not.

If it is not an overhang, then it needs to cool past the glass point in order that the new layer doesn't distort the previous layer.

However if it is an unsupported overhang, you actually want the print to be as stiff as possible so that the overhang is not pushed down by the extrusion i.e. you want it to be a lot cooler.

So perhaps Cura should have two minimum layer times, one without unsupported overhangs and one with.

(Playing devil's advocate, it could be argued that if you have a problem with unsupported overhangs being pushed down and getting distorted printing, then the answer is to use supports. My arguments against this are a) that supports create surface markings, so better to print without supports if at all possible; and b) that ideally you want to be able to create a profile which gives good prints in as many different circumstances as possible without tweaking for every print. But I am open to being persuaded.)

2. When slicing, in addition to displaying a warning if it goes into lifting, we should display a warning if it goes into minimum layer time and there are unsupported overhangs.

[GregValiant]

Is this still an issue in current versions of Cura (5.8.0 and up)? Can this be closed?

[github-actions]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[Sophist-UK]

This issue has been open for 4.5 years - 3 weeks ago you asked for more information (and I didn't spot the notification email) and having previously had an extended discussion and the information-needed flag removed, because all the necessary information had been provided. After 4 years, I cannot remember what the part was that was having this problem, and at the moment I don't have time to retest it at the moment. But in any case, it would seem that the best way to determine whether any of my ideas were implemented would be to review the code again - but instead you expected me to spot that you had asked me to retest this and find time to go back 4 years to work out what the part was and retest it - and then despite it having been 4 years, within 3 weeks to closed it, so shame on you for doing that.

That said, right now I have a hundred other activities competing for priority, and realistically this doesn't have sufficient priority to get to the top of the queue in any reasonable timeframe.

Nevertheless I still believe that the suggestions presented here:

1. Have merit;
2. Don't require any further information to evaluate.

[GregValiant]

Thanks for the response.
Hundreds of bug reports have been closed as they are no longer an issue in current Cura versions. I'm probably the only person who looked at this report since your response in August of 2020.
One of the reasons I attempted this "house cleaning" is to eliminate those reports that are no longer relevant so that reports like this can stand out better.

This will stay open.

[Sophist-UK]

We probably need to rename the issue to reflect the later conclusions and suggestions.

[fieldOfView]

Please do. Neither Ghostkeeper nor mahtDFR work on Cura anymore, so anything you can do to make your problem clear and concise will help towards getting things done. You could even edit your original post with those later conclusions and suggestions.

[Sophist-UK]

@Ghostkeeper @mahtDFR @fieldOfView @GregValiant

Thanks for all your inputs. I have tried to summarise the eventual conclusions of this discussion in a revised title and description.

[GregValiant]

"...there should be an option to move somewhere where any drips from the nozzle will not land on the print..."

Attached is a collection of (occasionally useful) post processors. Some are for debugging, one adds "line numbers" to the gcode, another removes all the comments in a file, and one is "Lift Head Parking".
If you feel like fooling around with it then unzip the file and put "Little Utilities_v15" into the "scripts" folder within your "Configuration Folder". I doubt that I will ever submit this as a PR for Cura. It's the sort of thing that is only useful to a few people. (The file also has almost 1900 lines of poorly-written script that no competent coder will want to check.)
LittleUtilities_v15.zip
Add the post-processor to the project, enable the script, and enable "Lift Head Parking".

"Lift Head Parking" performs a calculation to determine where the outside edge of the print is. When a head lift is noted in the gcode (using "small layer" as the search term) an "X" or "Y" move is added to move the nozzle to the edge of the print foot print which is (usually) off the print. It does not add retractions so they must already be present. Whether it's an X or Y move is determined by which direction is the shorter distance.

G1 F1500 E1990.94636      ; >> Cura Retract
;MESH:NONMESH
G0 F600 X123.639 Y124.781 Z5.4
G0 F7200 X115 Y125.5
;Small layer, adding delay
G1 F600 Z8.4               ; >> Cura z-hop
G0 F7200 Y131.7 ; Move away   ;>> the script adds this move away from the print.
G4 P15183                   ; the delay that Cura adds
G0 F7200 X115 Y125.5 ; Return to print    ;>> the script adds the return line
.......
G1 F600 Z5.4          ; >>Cura adds the Return to the working Z

As Ghostkeeper noted above, fooling with the temperature is count-productive as the hot end takes a few seconds to react to any change and then to settle down. Using "M109 R" that will often take ~20 seconds and the nozzle is oozing during that time.
I was not able to incorporate a "snuffle" into the code. It might be nice to have the extruder continue to retract (sort of like Retract Continue) but it does not. When the nozzle moves back to the print any oozing would still get stuck to the print.

[Sophist-UK]

As Ghostkeeper noted above, fooling with the temperature is count-productive as the hot end takes a few seconds to react to any change and then to settle down. Using "M109 R" that will often take ~20 seconds and the nozzle is oozing during that time.

Yes - I took note of the temp thing first time it was said, and since this issue was raised I have created bespoke Marlin firmware for my 3DP and dialled it in - including retraction settings - so I fully understand that temp is not the way to go.

I was not able to incorporate a "snuffle" into the code. It might be nice to have the extruder continue to retract (sort of like Retract Continue) but it does not. When the nozzle moves back to the print any oozing would still get stuck to the print.

Based on the extra experience, I would say that the user needs to get their retract settings dialled in so that it retracts and lifts/z-hops cleanly, and hopefully oozing won't then occur. If you have any references to "snuffling" that would explain it in a lot more detail I would be interested to learn about it.

[GregValiant]

Hah!!
A "snuffle" is what you do when you have a runny nose and nothing handy to blow it with.
Retract Continue (and PrusaSlicer, OrcaSlicer, et al) does that with the hot end. During travel moves the extruder keeps pulling the filament back so it can't really ooze. It's handy when printing with big nozzles.
It isn't really possible with the script because the nozzle is staying in one position. It goes well beyond the scope of what I had wanted to accomplish which was just to get the nozzle away from the print.