Cura underextruding after printing internal features

[spinkham 1]

Cura is driving me nuts with a particular issue: I'm getting under-extrusion as you can see here: http://imgur.com/a/hKNSg.

It only occurs where an internal feature (internal walls for a hole in this case) is printed immediately before start of an external wall, and the under-extrusion is only at the first sections of the walls that print right after the internal hole wall. I've tried everything I can think of, changing temperature, speed, enabling "Retract Before Outer Wall" in case it was a wiping issue, trying various retract settings.

The only thing that made it go away with Cura was editing the .stl to remove the screw holes, which obviously is not ideal. ;-) Craftware with equivalent settings did not have the under-extrusion problem.

Settings: Default cura Draft 0.2 profile, with the following changes:

 

• Wall thickness - 1.2mm
  
• Infill density - 30%
  

 

Printed in Hatchbox Blue PLA, which I've used for many other prints without issue. Printed on my Monoprice Maker Select v2, with DII cooler at 40% and upgraded extruder gear. E-steps were calibrated, PID has been tuned. Bed was heated to 60 degrees.

Settings I tried to play with:

 

• Temperature: 205,210
  
• Speed: 60mm/s, 50mm/s
  
• Retract Before Outer Wall: False,True
  
• Enable Coasting: False, True
  
• Retraction Distance: 6.5mm, 2.5mm, 2.0mm
  
• Retraction Speed: 40mm/s, 20mm/s
  

 

None of it made a lick of difference one way or another, however the instant I used meshmixer to remove the screw holes from the model the under-extrusion went away... I've seen similar issues before, but only now did I have the tools to examine the gcode to see the print order and have to print enough parts (needed 8, printed even more) to be able to remove other possible variables. I'd love to hear otherwise, but pretty sure something is screwy in Cura here, and hope I've collected enough data to help figure out what it is.

The original STL is available here: https://www.thingiverse.com/thing:1033845/#files

I'd be happy to post my modified "no screws" STL if anyone wants it for testing, as well as any gcode that might be useful.

[gr5 2,167]

Try lowering all the printing speeds to 30mm/sec (all of them except travel speed which needs to be at least 150mm/sec). That will fix it I'm sure. Then you can experiment with increasing the various speeds (there's several of them).

[spinkham 1]

Unfortunately, no substantial change with all 30mm/s speeds (tried both default 120 and your suggested 150mm/s travel). Here's the print with 30mm/s print speed, except 150mm/s travel. All other settings are draft 0.2 defaults, plus 1.2mm walls and 30% grid infill.

Print speed settings:

Everywhere else on the print is fine except the screw hole to external wall transition, and the same part minus the screw holes prints fine at any of the settings I've tried..

Here's a partial print with 50mm/s main speed and defaults (120mm/s travel speed):

I was pretty sure the ooze on the infill is what's missing from my outer wall, until I turned off combing, which removed the ooze but didn't fix the under-extrusion:

Edited August 10, 2017 by Guest
Added print speed settings screen cap

[spinkham 1]

A further detail that might be helpful: From a closer look at the partial prints, it seems like cura is only under-extruding on the outermost of the exterior wall layers:

Outside layer, looking rough:

Inside layer, looking fine:

Sorry pictures aren't great, it's an old USB microscope but the best I can do.

Edited August 10, 2017 by Guest
Added more pics of inner and outer wall layers

[gr5 2,167]

Retraction should probalby be 4.5mm by the way. Is this um2 or um3? Please could you post the sliced gcode file from your most recent test with all speeds at 30mm/sec? This is... strange. Never seen this issue before as far as I can tell.

Yes, turning off combing should help. A little. Maybe. As it might add a retraction right after printing the inner circle on the hole. Or maybe that "oozing" in your image was on the inner shells and not related to the final shell layer. Not sure.

Regardless. This is quite strange. I'm wondering maybe some cura bug. If you have a um2 I would strongly consider using cura 15.X right now.

https://ultimaker.com/en/products/cura-software/list

[spinkham 1]

It's a Monoprice Maker Select V2, used the Cura Prusa i3 preset with a few modifications to match my printer.  Pretty sure it's a Cura issue(prints fine in other slicers and in Cura with slightly modified models), came here for a sanity check before I file a bug on github.

stl and gcode files are here: https://www.dropbox.com/sh/gr134av8sy8sfd9/AAAkuOyiAPmyKW2SiOq03uOba?dl=0

Edited August 11, 2017 by Guest
Accidently a word

[gr5 2,167]

Oh! That's not a bowden printer. The feeder is right on the head. Make sure retractions are very low. 2mm max I'm guessing. 4.5 is much too much - lets air in the nozzle. I'd try 1mm or 2mm. That printer accelerates more slowly than a UM also. Hmm. I'd try 20mm/sec for all speeds. You can just dial down the feedrate to 50 to 66% as a test on each layer and see what happens. You can do 5 layers at 100% speed, 5 layers at 50%, 5 layers at 25% and see what is the right speed in this area. I'm quite curious. Then once you know you can have cura print the bottom layers slower and speed up after it's done with that area. I'm still confused as to what is going on.

[gr5 2,167]

It's a Monoprice Maker Select V2, used the Cura Prusa i3 preset with a few modifications to match my printer.  Pretty sure it's a Cura issue(prints fine in other slicers and in Cura with slightly modified models), came here for a sanity check before I file a bug on github.

stl and gcode files are here: https://www.dropbox.com/sh/gr134av8sy8sfd9/AAAkuOyiAPmyKW2SiOq03uOba?dl=0

There's 2 gcode files there. Which one is the latest at 30mm/sec and with combing turned off?

[Dim3nsioneer 557]

Are acceleration control and / or jerk control activated with this printer in Cura? If yes, you may want to switch it off.

[spinkham 1]

It's a Monoprice Maker Select V2, used the Cura Prusa i3 preset with a few modifications to match my printer.  Pretty sure it's a Cura issue(prints fine in other slicers and in Cura with slightly modified models), came here for a sanity check before I file a bug on github.

stl and gcode files are here: https://www.dropbox.com/sh/gr134av8sy8sfd9/AAAkuOyiAPmyKW2SiOq03uOba?dl=0

There's 2 gcode files there.  Which one is the latest at 30mm/sec and with combing turned off?

The one with 30mms in the name is the 30mm/s gcode, but that one didn't have combing turned off. I can generate one like that if you wish as well, but for the most part tried one major kind of change from the defaults at a time to see which might make the difference.

Edited August 11, 2017 by Guest
typo

[spinkham 1]

Are acceleration control and / or jerk control activated with this printer in Cura? If yes, you may want to switch it off.

Acceleration and jerk control are not enabled in Cura. They were set in the firmware as recommended here, to 800 for x and y and 8 for jerk.

[gr5 2,167]

Here's the relevant part of the gcode:

G1 X75.9 Y113.408 E1487.17481
G1 X75.829 Y113.136 E1487.18416
G1 X75.723 Y112.865 E1487.19384
G1 X75.588 Y112.607 E1487.20353
G1 X75.421 Y112.364 E1487.21333
G1 X75.228 Y112.142 E1487.22312
G1 X75.009 Y111.945 E1487.23291
G1 X74.771 Y111.774 E1487.24266
G0 F9000 X74.596 Y111.678
G0 X74.838 Y111.24
G0 X89.372 Y89.414
G0 X89.8 Y89.342
G0 X89.8 Y89.842
G1 F1800 X89.8 Y139.642 E1488.89902

The movements with an "E" term include the extruder - those are extruding moves.

The 5 G0 moves without the E are non-extruding - those move from the circle to the part where it underextrudes. The E1488.89 is extruding about 1.6mm of filament which according to the gcode analyzer (image below) is the same rate as everywhere else (.022mm/mm). I looked at 2 layers - one with solid infill near bottom and 1 with cross hatch infill about 1mm up. Same results.

So in summary the gcode looks fine. I think it's your printer. Sorry. And there is zero retraction on this one.

Maybe it's because there are 4 travel moves before it starts printing again. The UM printers have very high jerk setting - about 20mm/sec so they blow through those tiny moves almost instantly. Maybe your printer is leaking/oozing during that. Or maybe the motion planner inside your printer has a bug. Motion planners are very complicated. I've rewritten one and looked at the code in Marlin and Repetier and other motion planners and there are hacks and bugs in all of them.

[gr5 2,167]

The graphic above and the gcodes are from the exact same region of the file. gcode.ws is an amazing website. Notice I checked the box "emulate extrusion width" for this analysis. I also played with turning on "mm extrusion per move" and looking at the "layer info" tab. The layer info tab indicated there were only ever 2 extrusion rates (flow rates). One was for the bottom layer which must have been thicker (that's default in cura - thicker bottom layer). The other was for the rest of the print. No 3rd extrusion rate.

I urge you to play with this tool. Anyway - I see no bugs in cura in this situation. There is something weird with your printer - probably in the firmware.

[spinkham 1]

The graphic above and the gcodes are from the exact same region of the file.  gcode.ws is an amazing website.  Notice I checked the box "emulate extrusion width" for this analysis.  I also played with turning on  "mm extrusion per move" and looking at the "layer info" tab.  The layer info tab indicated there were only ever 2 extrusion rates (flow rates).  One was for the bottom layer which must have been thicker (that's default in cura - thicker bottom layer).  The other was for the rest of the print.  No 3rd extrusion rate.

I urge you to play with this tool.  Anyway - I see no bugs in cura in this situation.  There is something weird with your printer - probably in the firmware.

It is a nice tool, but I can't get the "mm extrusion per mm move" to show me anything useful. Everything on every layer is black, even though almost all layers except layer 4 (which you seem to have examined) have at least 2 different values shown in the key. I'd expect something somewhere to match the key, or at least the base layer to be a different color from the rest.

However, I did isolate the gcode and manually calculate the rates for the inner wall which prints fine and the outer wall that doesn't, and they were the identical ~0.033mm/mm extrude rate, so it doesn't seem to be a cura problem per se. I'll keep messing with the model and/or gcode to see if I can figure out the precise cause to work around it, as I don't want to stop using cura or have to upgrade my board and/or firmware, and those seem the only options otherwise. I have have this sort of problem with Cura on a number of prints and never yet with Craftware, so wherever the issue is it would be nice to figure it out..

[gr5 2,167]

As a test you could delete the first three travel moves for 20 layers in a row to see if that helps.

G1 X74.771 Y111.774 E1487.24266

G0 F9000 X74.596 Y111.678 //del

G0 X74.838 Y111.24 //del

G0 X89.372 Y89.414 //del

G0 X89.8 Y89.342 //del

G0 X89.8 Y89.842

G1 F1800 X89.8 Y139.642 E1488.89902

The ones above that say "del" are useless. It's faster to just move directly (green line in screen shot above) the other moves are too tiny to be useful and I suspect your printer is taking too long to do them or your firmware does something weird with these tiny/short moves.

If that fixes the problem then you would know a lot more. For example a square hole might be better. Or maybe you could reduce the polygon count in the cad model of the round holes. Right now they have an excessive amount of movements.

Actually that could be the whole problem! Do you have the original cad model? Can you edit it? I'm guessing yes. If so when you export to STL try to make those holes have only maybe 10 line segments - not the 50 or so they have now.

What happens is the planner inside the printer typically only has 16 move look ahead and has to be able to stop after 16 moves in the future so it has to slow down for those short line segments because it needs to be able to stop within a mm or so. But if 16 line segments are at least 5mm distance then it can print them much faster. The speed change of doing those vertical holes to suddenly doing a long straight line (like a highway) causes your underextrusion.

[spinkham 1]

As a test you could delete the first three travel moves for 20 layers in a row to see if that helps.

It helped a decent amount, but didn't solve the problem. The under-extruded area became about 1/2 as long, about 10mm vs 20mm vs the same gcode without the extra moves removed.

Actually that could be the whole problem!  Do you have the original cad model?  Can you edit it?  I'm guessing yes.  If so when you export to STL try to make those holes have only maybe 10 line segments - not the 50 or so they have now.

I do not have the model, just an STL from thingiverse. I did reduce the triangle count in meshmixer and printed that, and had no major issues, however the print order was completely different so hard to say. There were a few even longer moves from internal features to external walls than were in the previous print, but basically no noticeable underextrusion. I can see just a *tiny* bit thinner walls at the end of the moves that probably come from wiping and only because I was looking so hard , but it's *way* better than the prints from the versions with the round holes with the many tiny print segments.

I'm not sure what to do with any of that information. Is there any settings I can tweak to make cura more reliable for me, or any bugs I should submit to the project? Other slicers with alternate build orders seem to be much more reliable for me, but that's not an option in Cura...

[burtoogle 513]

I'm not sure what to do with any of that information. Is there any settings I can tweak to make cura more reliable for me, or any bugs I should submit to the project? Other slicers with alternate build orders seem to be much more reliable for me, but that's not an option in Cura...

In the fairly near future, Cura should make a better job of your print. I don't know what the real problem is that you are suffering but a new feature (wall order optimisation) that is currently under test should help. Unfortunately, it's not going to be in 2.7 but it is now in the master branch so it should be in 2.8. The feature optimises the order that walls are printed within a single part. So instead of printing all of the inner walls of the holes and part outline first followed by all of the outer walls, it tries to group the walls for each hole and the outline together so in your example, as long as you are not using the "outer wall first" option, it should print the inner walls before the outer for each hole (and the outline) and any long moves should be to the inner walls and not the outer so any loss of filament due to dribble should have a less obvious effect.

Here's a layer of your part showing the optimised travel moves:

Notice how it doesn't do multiple moves to each hole or the outline.

Edited August 13, 2017 by burtoogle

[gr5 2,167]

I think reducing the triangle count is the most important take away here. If you are printing this for someone else then I would get them to re-export or ask them for step files or something (step files will have those holes as cylinders instead of multiple line segments/triangles).

This part is very simple so an alternative is to model it in cad yourself. Drop it into cad as an stl and measure the diameters, lengths, curvatures and draw the same part next to it. Then export that with fewer triangles.

[gr5 2,167]

Another option is to change the controller board on your printer. The UM (and most printers) still uses Marlin with 16 line look ahead but some of the newer controllers go out to 256 look ahead. For example redeem/replicape, smoothie board (not certain), and tinyg are all modern controllers with much more powerful computers yet still inexpensive (the wonder of cell phones).

[spinkham 1]

In the fairly near future, Cura should make a better job of your print. I don't know what the real problem is that you are suffering but a new feature (wall order optimisation) that is currently under test should help. Unfortunately, it's not going to be in 2.7 but it is now in the master branch so it should be in 2.8.

...

I tried installing the latest version via the Cura Master PPA (https://launchpad.net/~thopiekar/+archive/ubuntu/cura-master), but do not see this behavior. Did the code get reverted, or is it not in the PPA version for some reason?

I have cura version: 2.6.99-master~201708250033~rev2169~pkg163~ubuntu17.04.1

And cura engine version 2.6.99-master~201708251301~rev1718~pkg163~ubuntu17.04.1

Edit: Found "Optimize Wall Printing Order" toggle, still does not have the behavior described with that enabled.

Edited August 25, 2017 by Guest
trim quote

[burtoogle 513]

In the fairly near future, Cura should make a better job of your print. I don't know what the real problem is that you are suffering but a new feature (wall order optimisation) that is currently under test should help. Unfortunately, it's not going to be in 2.7 but it is now in the master branch so it should be in 2.8.

...

I tried installing the latest version via the Cura Master PPA (https://launchpad.net/~thopiekar/+archive/ubuntu/cura-master), but do not see this behavior. Did the code get reverted, or is it not in the PPA version for some reason?

I have cura version: 2.6.99-master~201708250033~rev2169~pkg163~ubuntu17.04.1

And cura engine version 2.6.99-master~201708251301~rev1718~pkg163~ubuntu17.04.1

Edit: Found "Optimize Wall Printing Order" toggle, still does not have the behavior described with that enabled.

The optimisation code is still in the master branch, if you see that toggle it's there. Whether a given layer is optimised or not depends on the number of holes , number of insets and whether the infill before walls option is enabled or not (if enabled, no optimisation is used if 3 or more walls are specified).

[spinkham 1]

The optimisation code is still in the master branch, if you see that toggle it's there. Whether a given layer is optimised or not depends on the number of holes , number of insets and whether the infill before walls option is enabled or not (if enabled, no optimisation is used if 3 or more walls are specified).

I see.. The default seems to be infill before walls and I'm using 3 walls. I do see the expected behavior with 2 walls as well as with infill before walls disabled.

Is there a strong reason it's automagically disabled for that particular (fairly common) set of settings?

[burtoogle 513]

The optimisation code is still in the master branch, if you see that toggle it's there. Whether a given layer is optimised or not depends on the number of holes , number of insets and whether the infill before walls option is enabled or not (if enabled, no optimisation is used if 3 or more walls are specified).

I see.. The default seems to be infill before walls and I'm using 3 walls.  I do see the expected behavior with 2 walls as well as with infill before walls disabled.

Is there a strong reason it's automagically disabled for that particular (fairly common) set of settings?

Well, I never use infill before walls but the cura devs told me that when it is enabled the walls have to be printed from the innermost wall outwards otherwise there can be some degradation of the print quality and the optimiser does not guarantee to abide by that constraint when there are more than 2 walls. So, currently, the optimiser is disabled when infill first is enabled and there are more than 2 walls. I will look into whether it is possible for it to be enabled in that situation with maybe a little less optimisation.

[burtoogle 513]

I have made some changes to how it decides whether to optimise or not and your example can now be optimised when outputting infill first and with more than 2 walls. I shall test the changes some more and put a PR together so that it gets into a future release.

[spinkham 1]

I have made some changes to how it decides whether to optimise or not and your example can now be optimised when outputting infill first and with more than 2 walls. I shall test the changes some more and put a PR together so that it gets into a future release.

Awesome!

Signed up for notification on your pull, but meanwhile having great success with two perimeters in the current git master version. It also seems to have solved an intermittant problem I've been having with weak tubes (like the smokestack on the benchy), and Cura's back to my daily driver.