burtoogle

BTW, @Kefon, Cura mesh tools plugin says that your nice model is not watertight so I think that maybe explains why you get that weird missing line. Also, if you look at the model in a viewer, you can see there is something weird in the area that has the missing line. You can see it here about 1/2 way up this image there are some darker segments...

It would be helpful to see the complete layer 9 but I'm guess that it ends up with some skin partially covering the 3 big holes. Anyway, you have 2 options: (1) use support or (2) make the skin on layer 9 completely cover the holes and then drill them out when the part has completed. The skin only needs to be a single layer thick. I use this technique always when I have a small diameter hole directly above a larger diameter hole (i.e. when you have a nut trap or similar. Here's what I mean... Hope this helps!

My releases are to be found at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

I am using my own version of Cura which has some fixes to the spiralisation which haven't made it into Ultimaker's Cura yet so you may be seeing a problem that I have already fixed. If you want you can try one of my releases which I have mentioned many times on this forum.

Hi @Kefon, I briefly looked at your project. Yes, it does have that weird missing layer with the straight line. I set the experimental setting called Slicing Tolerance to Inclusive and it appears to slice OK (layer view looks OK, haven't actually looked at the gcode yet). So I wonder if there is something in the model that doesn't get converted into Cura's internal representation correctly? Will play with it some more later or tomorrow. Hope this helps.

Hello @Kefon, please could you save the project file and attach to this thread so I can check for myself what is happening. Thanks.

Hello @Link. The skin expansion is helpful when you have a skin surface with a wall on top of it. Expanding the skin will push the skin further under the wall and this can avoid ugliness if the infill density below the skin is not high. It's also useful for removing small gaps that can occur in skin when a small feature lies on top of skin, e.g. lettering. The skin removal feature is used to shrink back skin before it is expanded. So if you shrink and expand by the same amount, the result will be the same? Not if any of the skin area becomes so narrow that it completely disappears. That's the main use for shrinking the skin. Hope this helps.

Hello @McMorton, welcome to the wacky world of 3d printing! It's very common when 3d printing that when you add some internal feature to a model, it can have an effect on the outside of the printed part. The effect can either be very subtle like a small variation in the outer wall profile or it can be much more obvious like some under/over-extrusion or other bad quality issue. Sometimes you can reduce or even eliminate such effects but choosing to print the outer wall first or the infill first or change the number of walls, infill pattern etc. There's quite a lot of variables to play with which is why we all spend hours tweaking settings to try and achieve the best results for a given model and material. At the end of the day, no matter how expensive the FDM printer, there are limitations to the achievable quality due to the nature of the technology.

Hello @pelleS, if possible, please save the project file and attach to this thread. Then I can look into a solution. thanks.

There are now versions for Linux, OS X and Windows. They should install without affecting your existing Cura installations. I normally use a skirt of 500mm length or so that gives plenty of time for the nozzle to prime correctly and also you can wipe away any "worms" and other stringy bits of filament that often get attached to the nozzle even if it is wiped before the print starts. I do not use a prime blob.

Hello @davidbuttress, set the skin removal width to a smaller value or even 0. Hope this helps.

Not 100% sure but I think this maybe related to a regression that has crept into a recent Cura release that causes some bad infill and skin regions. If that is so, I don't think there is anything you can do about it apart from going back to an earlier Cura version or maybe trying one of my releases which can be found at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

Hi @joestefano, thanks for the gcode. You can see the difference when comparing that with the gcode from my Cura: You asked above about tracking updates. Just revisit that Dropbox folder from time to time. If either I or the Cura developers have made some significant change then I will produce a new release. Please note that these releases are built from "bleeding edge" sources so they can sometimes have (even more) issues than the normal Ultimaker releases although I will not make a release if I am aware of any major problems.

Hi @joestefano, I tried running the Ultimaker 3.6 Linux release and it crashes(!) on initial startup so I can't actually slice your 3.6 project using a real 3.6 release. I can slice the master project using my master release and I can see that it is using the inter-wall gap fill. Is that where it is causing the shakes? Could you please slice using 3.6 and save the output to file but not the default ufp format, tell it to save as gcode and then attach that file to this thread so I can look at the gcode you are getting. My guess is that 3.6 is using zig-zag infill for that inter-wall gap. If I am right then you cannot do anything apart from set fill gaps between walls to nowhere (or use my release!)

Brave man. You may want to consider incorporating some of the changes I have already made which can be found in the mb-master branch of https://github.com/smartavionics/CuraEngine. Good luck!

Hi @Arbitur, I wish you good luck. I can tell you now that it's hard to fathom how some of that code works, I don't think the original coders (who, incidentally, are still around) even understand how some of that stuff works. My cura does have some changes to that code but I have never managed to understand how a lot of it works so I have given up trying to improve it further. Personally, I think the whole wall overlap system needs ripping out and replacing. But I'm not going to do that because what I am using works sufficiently well for my simple needs.

Hi @Boffy, the surfaces in that model are really too thin to print well but I have managed to print it by lying it on its side and enabling the print thin walls option. I am using 0.2mm layers.

But then I tested the same model with different settings (layer height, line width, etc.) and it actually took slightly longer slicing with the newer code so maybe it's better to stick with what we have at the moment?

Looking again at that earlier PR, it is possible to save some time and so now it takes around 220 seconds compared to 260 so I shall submit a new PR for the changed code.

@phantom, @ghostkeeper, I have investigated why using one or more top surface skin layers causes a big slowdown. The culprit is my contribution (https://github.com/Ultimaker/CuraEngine/pull/631). What that PR does is fix the problem described in https://github.com/Ultimaker/Cura/issues/2656. I can't see right now how the implementation can be made quicker so we either have to live with the slowdown when that feature is enabled or we remove the fix and allow prints to fail again.

Hi @Arbitur, the sources are in my own github repos which are forked from the Ultimaker originals. See https://www.dropbox.com/s/mzmzgkqn2hnf5zy/README.md?dl=0 for a little more info. Looking at your images above. The green lines are the inner walls and they are subject to overlap compensation. That is an ancient (before I became involved) feature in Cura and the way it works is that when you have a gap that is wider than a single line but not wide enough for two lines then one line is printed normally and the other line is flow reduced. To be honest I don't think it really matters that the lines are not symmetrically spaced because, hot plastic being what it is, the end result is a filled gap. Where that fails, of course, is when the available gap is such that the second line is flow reduced to less than, say, 30% of it's normal flow rate and then you can end up getting blobs and gaps due to the very small extrusions commanded. Of course, it would be better to have two lines of, say, 60% width instead of one line of 100% and the other of 20%. It would require some major work I think to redo the overlap compensation and I'm not signing up for that. What I have done recently is rework the wall gap filling and thin wall support and, as you have observed above, it manages to fill the gaps with a single, variable width, line (yellow in the above images). It's still work in progress but is producing quite nice results. I think perhaps my solution is not the fastest (slice time, not print time) which doesn't worry me because I only print small things but may make it too slow for anyone printing large complex prints that use a lot of wall filling and/or have thin walls. My focus has always been on improved print quality rather than slicer speed.

Hi @ViennaBlood, you don't have to delete anything, just disable the blasted thing...

You may be interested in trying out my Cura builds which feature various tweaks and fixes that are not in standard Cura. In particular, I have made some improvements to the wall overlap compensation and a recent addition has been a new implementation of the wall gap filling and thin wall support. You can install my releases alongside the Ultimaker releases and they should happily coexist. If you are interested you can find them at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

Hello @Arbitur, thanks for the project file. Yes, I those little blobs are generated by the wall overlap compensation. Unfortunately, that part of Cura is quite buggy and it definitely could be improved. With a cross section width that alters with height, it's very difficult to workaround because no one line width will be an exact multiple of the model width.

As the print takes 15+ hours to print, the slice time is pretty inconsequential. I know that everyone wants the slicer to be as quick as possible but, obviously, there's a trade off here whereby increasing the quality of the sliced gcode almost always increases the time to slice. Also obviously, the implementation could be buggy or just not that well written in which case it can be improved once the devs are aware of the issue. Producing good quality gcode in a time efficient fashion is a challenge!