burtoogle

Sorry, I can't help you there but I'm sure that others can, perhaps @kmanstudios, can suggest a fix?

Freecad also says...

Thanks for the 2nd file. It loaded but I get a warning about it not being watertight and it fails to slice correctly as you have found. And freecad says it has self intersections...

Hello @valely97, when I tried to load that model, Cura told me it was too small and nothing appeared on the build plate.

When I try to slice this, CuraEngine crashes. Before it crashes it says... 2019-03-30 22:20:49,185 - DEBUG - [Thread-12] UM.Backend.Backend._backendLog [101]: [Backend] [WARNING] Mesh has overlapping faces!

Hello @valely97, could you possible share the model, please? If so, please attach to this thread.

Hi @JujuLab, thanks for the file. I can't explain the weird tower in the middle but the other dangly bits are probably because the model has bridges. You could try enabling the experimental option "Enable Bridge Settings" which will modify print speed, flow rate, etc. and that may improve the quality.

So it is possible for Cura to detect that the OpenGL context will use software rendering by inspecting the response from OS X? If so, then that should be done so the program is at least usable. If not, then it has to be a user preference.

So can't we just have a user preference that forces the use of OpenGL 2?

Hello @JujuLab, please save the project file (File -> Save) and attach the .3mf file to this thread. Thanks.

In your dreams!

The positions of the part's walls are not taken into consideration when the infill pattern is generated. The infill pattern is fixed with respect to the build plate so if you move the part on the build plate, the infill lines within the part will move with respect to the part's walls.

Hello @Adam324, sorry to hear you are unwell, I wish you a speedy recovery. I pretty much always use a line width of 0.5mm with my 0.4mm nozzle and have never had any particular problems with precision. With a model such as yours, the width of that inner gap varies. You can see that clearly in my image above as the yellow gap fill is thinner where the wall outline is straightest and fatter where the wall outline curves more. If the inner (green) wall line width is such that it is close to the average width of the gap, in some places the gap will be smaller than the wall line width and in other places it will be bigger. Where the gap is bigger, the slicer will generate normal wall line segments (green) and then the gaps get filled with yellow.

Hi @Adam324, I sliced your model using my Cura release and it looks really good. This is with 0.5mm wide wall lines and the wall gap fill enabled. Print time is around 2 hours, quite a saving! The wall gap fill produced by Ultimaker Cura releases tends to be rather zig-zaggy but this is nice and smooth as you can see.

OK, so to reduce the number of retractions in the infill I would recommend these settings: 1 - Use gyroid infill at whatever density you need (can often be lower than with the other patterns) 2 - Enable Connect Infill Lines - this will zig-zaggify the infill and really does cut down on a lot of travel moves. 3 - Use the No Skin combing mode 4 - Set the Max Comb Distance With No Retract to whatever value you wish (typically 10 - 30). That would be the Optimize Wall Printing Order setting. Sorry, I know nothing about the UI or the graphics so I can't help with your other gripes. Hope this helps!

Hi @tonycstech, could you please say some more about this issue? Thanks.

Hello @tonycstech, I agree that the layer view could be more useful. The last time they revamped it, I suggest that they make it more like the craftware viewer which is what I use when I want to inspect the cura gcode. However, most people don't need that level of details so I can see why they didn't bother to enhance it further. What retraction problem are you referring to?

Hello @chputney, two recommendations, enable the wall print order optimization and also don't use z-seam alignment set to sharpest corner, that very rarely does what you want. Instead, it's nearly always better to choose the User Specified setting.

Hello @Fortunato, please save your project (File->Save) and attach the .3mf file so we can check your settings.

Unless, I am slicing a model that requires particularly thin lines, I always use a line width of 0.5mm. Sometimes, I use 0.6mm for infill.

Hi @jens3, I don't have any real good answer but I do know that if I am overextruding then I see ripples like that. It most often occurs on the first layer when the nozzle is too close to the bed. I don't normally see it for higher layers. Maybe the whole print is too hot, what bed temp are you using? I have found with PETG that you tend to get worse problems of filament sticking to the nozzle when really hot so now I am using a bed temp of 60, a first layer temp of 240 and then 230 for the rest. That's with a 0.4 nozzle and lines either 0.5 (walls) or 0.6 (infill). Finally, unless the object being printed has fine details, I normally use 0 fan to keep the strength up. Hope this helps.

Hi @spencerdiniz, I'm glad the problem is solved. I still think you would do well to stop the print cooling fan from blowing onto the hotend block. Cheers!

Ah!, I just noticed that in the bad results file you are using relative extrusion. That would explain the poor print quality if your extruder resolution is low. Try using absolute extrusion rather than relative.

Hello @spencerdiniz, a quick look at those files shows me that the good result was printed at 200 deg and the bad result is using 225 deg. As I mentioned above, that's pretty hot for PLA and you can expect to get very different results compared to using 200 deg. The other obvious difference between those files is that the good result does 3 walls at around 20mm/S and the bad result uses 2 walls at around 20 mm/S and the outer at 10 mm/S. So I suggest you try using 200 deg and 20 mm/S for all the walls and see if that makes a difference.

Hello @spencerdiniz, please attach the cura gcode that gives a good result and also the cura gcode for the same model that gives a bad result. I can then compare the gcodes and see where they differ. Thanks.