1
$\begingroup$

TL;DR: Upper layers of a stringing pyramid test are missing retractions in the G-code.

Edit 1: added printer info and additional settings.
Edit 2: Clearing up confusing wording.

Update:
I wrote a program to parse the G-code and count the retraction-extension pairs between layers. The first 17 layers (base) and 18-95 (pyramid start) have the appropriate number of extruder calls. I expect an extension at the start of the layer, retraction before moving to the second tower, extension to print the second tower, and a retraction before moving back to the first tower.

After layer 95 of 391 the number of retraction pairs starts to decrease from missing a pair every other layer to eventually almost no retraction pairs. The last 70-ish layers have a retraction pair every dozen or so layers.

Perhaps this is related somehow to the shrinking width of the pyramid since the missing retraction-extension pairs increase as the pyramid comes to a point

Disabling Z-Hop shows no difference in this behavior

Original question:
After switching to a 0.2 mm nozzle I starting printing some calibration tests to find my stringing pyramids end up looking like a pair of trees. I suspect I've always had this issue, but it's much more evident now with a smaller nozzle that likes to ooze.

This is on an Ender 3, so using a Bowden tube, with a MicroSwiss all metal hot end and the extruder mechanism is aluminum with a pair of toothed drive gears. I'm seeing the problem in 1.75mm PLA of multiple well regarded manufacturers.

Relevant Settings (let me know of other settings I should list):

  • enabled retraction
  • combing mode 'off'
  • enabled z-hop when retracted
  • retraction distance 3.5mm
  • retraction speed 50mm
  • retraction minimum travel 1.5mm
  • Infil 100%

Looking at the G-code, sometimes I see a retraction paired with the Z-hop, but sometimes it's missing. It seems pretty random for when it's missing, but the first quarter or so of the layers do not show the problem. Originally I thought it had something to do with extruder drift over time, or something crazy, until I looked at the G-code and saw it was missing commands.

Snippit of retracting for Z-hop:

G1 F1200 X204.632 Y161.781 E77.9224
G1 F3000 E74.4224
G1 F300 Z7.08
;MESH:NONMESH
G0 F9000 X190.179 Y161.901 Z7.08
;TIME_ELAPSED:2354.891407
;LAYER:171
;MESH:string_test_fast_pyramid.stl
G0 X190.179 Y161.901 Z7.12
;TYPE:WALL-INNER
G1 F300 Z6.92
G1 F3000 E77.9224
G1 F600 X190.179 Y161.555 E77.92356

Snippit of not retracting for z-hop:

G1 F1200 X204.473 Y161.666 E78.0239
G1 F300 Z7.12
;MESH:NONMESH
G0 F9000 X190.182 Y161.898 Z7.12
;TIME_ELAPSED:2359.620803
;LAYER:172
;MESH:string_test_fast_pyramid.stl
G0 X190.182 Y161.898 Z7.16
;TYPE:WALL-INNER
G1 F300 Z6.96
G1 F600 X190.182 Y161.558 E78.02503

Test on the left is done with 'Equalize filament rate' enabled, on the right side is done with the option disabled.

enter image description here

Any advice you can give as to what settings I am missing or misconfigured would be much appreciated.

Improve this question
$\endgroup$
3
  • $\begingroup$ Are you entirely sure the stringing corresponds to where retractions were skipped? In other words, do the initial layers that look ok all have the correct retraction? I'm not sure what would be making Cura mess this up, but I your settings (Z-hop and low retraction distance) look suspect for causing this kind of stringing themselves. $\endgroup$
    – R.. GitHub STOP HELPING ICE
    Commented Jul 23, 2020 at 17:39
  • $\begingroup$ The only plausible explanations I see for the missing retractions are either a higher "retraction minimum travel" setting than you reported (you say "I think" which is not reassuring) or a bug in Cura. I certainly wouldn't rule out the latter. It might be an interaction with Z-hop, so it would be worth turning off Z-hop to see if that makes it go away. I'm not sure why you're using Z-hop to begin with; it generally causes stringing rather than fixing it, and only makes sense if you have warping issues that are making the nozzle collide with part and knock it off the buildplate. $\endgroup$
    – R.. GitHub STOP HELPING ICE
    Commented Jul 23, 2020 at 17:47
  • $\begingroup$ I'm sorry for the confusion. The 'I think' was to say I am not sure which settings are relevant. The values for the listed settings are accurate. I have edited to clarify this. I was under the mistaken impression that z-hop helps force the retraction. I will print another test without z-hop and post the results. $\endgroup$
    – Spottenger
    Commented Jul 25, 2020 at 1:39

1 Answer 1

Reset to default
2
$\begingroup$

It's likely that you're hitting Cura's Maximum Retraction Count (retraction_count_max) within the Minimum Extrusion Distance Window (retraction_extrusion_window). This is a misfeature supposedly designed to avoid grinding/flattening the filament, but of course acting on it will ruin your print in exactly the same way you're seeing. I think setting the window to 0 or the maximum count to some ridiculously high number like 1000000 will fix the problem.

Note that it's exacerbated by the thin nozzle making the number of retractions needed take place over a much smaller extruder-axis move distance than what you'd have with a normal 0.4 mm nozzle. This is probably why nobody has noticed and complained about the badness of Cura's defaults here.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thank you! After increasing the Maximum Retraction Count, the G-code shows all the expected retractions. It makes sense that the allowed retractions would be used up at an increasing rate as the pyramid grows. A 0.3mm Minimum Extrusion Distance Window would be required to have all retractions within the default 100 maximum due to how little material is extruded for the final layers. Regardless, I can understand the developer intent behind these settings since its only a loss in print quality to ignore the retraction as compared to a potential failure to extrude which ruins the print. $\endgroup$
    – Spottenger
    Commented Jul 26, 2020 at 4:03
  • $\begingroup$ @Spottenger: Skipped retraction is also a failed print. Every string is material that was supposed to be somewhere else and didn't get there, meaning you have underextrusion and thus insufficient bonding that will cause the part to break or otherwise not function properly (assuming it's functional and not just decorative). So this really is a bad default - it's trying to reduce chance of one type of failure by creating a guaranteed failure of a different sort. $\endgroup$
    – R.. GitHub STOP HELPING ICE
    Commented Jul 26, 2020 at 4:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .