burtoogle

A few questions: 1 - How many walls are you using? 2 - How many "extra skin walls" are you using? 3 - what speeds are you using for the walls and skin? 4 - what temperature are you using? Perhaps you could attach the project file, that would answer those questions (and more!)

The real answer (from looking at the code) is that if a polygon has multiple corners with the same degree of "sharpness", then the first corner found will be chosen for the z-seam position. I don't use the sharpest corner feature much but sometimes it can be quite good. For example if you want to hide the z-seam on a vertical edge that curves, using a combination of sharpest corner and x/y z-seam coordinates, can achieve that. It's not perfect but has its uses.

Thanks @cjs. My main reason for spending the number of hours I do working on Cura is to improve the quality of my own prints. The fact that others will benefit too is an added bonus. That is the beauty of open source software. Happy printing!

I sliced one of those STLs and the travels were correct although for some of the moves it went a very long way around the perimeter so it could be better to turn off the combing completely. The time difference between combing no skin and no combing at all is very small. Personally, I think I would just turn the combing off for that print. Cheers!

Not sure that's totally as expected, can you post a project file so I can take a closer look?

What's happened there is that the master branch CuraEngine is trying to retrieve a setting value that is not being provided by the front end. You can probably get away with simply replacing the fdmprinter.def.json in your Cura installation with the one that is in the master branch.

The light blue indicate travel with retraction, the dark blue without retraction. Unfortunately, the layer view doesn't show any z-hop so I use other gcode viewers when I want to get a detailed look at what's been produced. The one I normally use is the CraftWare slicer which has the best gcode viewer I have come across so far.

OK @jazzychad, if you try it please post a screen shot of the layer view so we can see what it has done for the travel routing. If you print it, please carefully inspect the printed output to see if there are any artifacts caused by those travel moves that go along the walls. The nozzle will be close to the edge of the print so it could cause some roughness on the walls. On my own testing I have seen zero roughness due to the nozzle being so close to the edge but I am interested to get feedback from others.

Hi @jazzychad. Yes, this is exactly the problem I mentioned. They call it "no skin" combing but the way it was implemented it was doing "infill combing", i.e. combing within regions of infill but not combing everywhere else. I have submitted a change (PR) so that the no skin combing will comb in regions of infill and also within the walls. That fixes the problem you are seeing because it will no longer travel across a wall without a retraction which it has been doing quite happily before now.

Hi, this is a fundamental problem that Cura has. It can only print an even number of walls. The wall overlap compensation (when enabled) tries to reduce the width of walls that can't fit in the space available but the implementation is less than perfect and so the width of the overlap compensated lines can be wrong in places. Furthermore, in the situation where the last wall is thinned down to nothing (as in your example), Cura still tries to output a wall so the nozzle will travel around the wall path extruding very little. Depending on your extruder resolution this can make quite an ugly print. I currently have a PR (pull request) on the CuraEngine to add an option to replace lines whose flow is below a threshold value (configurable) with travel moves (retraction optional). This provides a "band aid" solution to the problem you are suffering from. The PR has yet to be accepted but if it is (or something similar) then there will be a solution in a future release. I hope this is helpful.

Hi @Cminer, thanks for the feedback. Tricky with a cylinder because you can't hide the seam on an edge. Perhaps you can improve it by tweaking temp/speed/retraction amount/etc. Let's be honest, it's never going to be completely invisible but you should be able to manage something at least as good as this example I just picked at random from a pile of test prints.

When I was working on the bridging (which is still WIP), it occurred to me that I could probably come up with some code that worked for my specific examples that I test in a particular environment (PLA, 0.4mm nozzle, delta printer, etc.). When it was working OK for me, that would be OK for everyone else, too? I don't think so. The point being, as already explored above, there's so much variation in materials/printers/models/requirements (prettiness, strength, etc.) that there is absolutely no way that one size fits all. What works for me, is unlikely to work for others. So we need the ability to tweak and tune. That's why there's such a daft number of experimental bridging settings. It's complicated because we don't yet know what will work best. Once the tweaking and tuning has been done to our collective satisfaction the good combinations of settings can be embodied in "standard" profiles which can then be used with a degree of confidence by people who don't care about the detail. It may turn out that some of the settings are actually redundant and some of the implementation simply doesn't need to be there. In which case, we can chop out the bits that are not required. Cura is complicated because although FDM 3d printing is a theoretically straightforward task, it's made extremely complicated by the limitations and physical properties of real machines and materials.

Thanks @qwerty8224 , I'm not sure exactly what you mean by waiting for the improvement of this function but work is continuing on the bridging support in Cura. I never imagined that the first version would be optimal and so it is to be expected that there will be some changes over the next few Cura releases but nothing too radical, I hope.

It's fixed and a PR (Pull Request) has been submitted - it will get tested by the Cura guardians and if it receives their blessing will be in a future release. If not, it's back to the drawing board!

Thanks for the project, a couple of things I think you should change are: 1 - enable the wall order optimization 2 - specify a z-seam alignment position, the actual position doesn't much matter but it will force the z-seams to align which often looks best (or not!) These changes will reduce the amount of travel between printing the outer and inner walls which is probably what's going wrong as the long travels let the nozzle dribble and so by the time it gets to print the outside wall it will tend to underextrude. Also, I think to get the nicest looking z-seam, use the same speed for the outer and inner walls because that will avoid a step change in extrusion rate when an inner wall finishes and the outer wall starts. Hope this helps.

The "no skin" combing is a crock! I am currently working on a fix for this problem. It's looking promising... Before fix After fix

Here's the contents of the README.md that goes with the releases: ## Cura development releases (Linux only) These are built on a Ubuntu 16.04.4 system from the current Cura master branches + my own additions/tweaks. Use tar xjf cura-mb-master-DDMMYYYY.tar.bz2 to unpack into a directory called cura. Once unpacked, run `cura/bin/cura.sh` to start the application. **All are supplied with no warranty, YMMV.** ## What's different from the regular master branch? ### Stuff that could be merged into the standard release in the future 1. Mininum Wall Flow + Prefer Retract settings let you specify the minimum flow rate for a wall, if a wall has a smaller flow rate (i.e. is thinner), it is replaced with a travel move and, optionally, may use retraction. 2. Fan Speed Override + Supported Skin Fan Speed settings let you specify a fan speed to be used for the skin areas that are above support. 3. Small Hole Max Size + Small Feature Max Length + Small Feature Speed + First Layer Speed settings let you print small feature outlines slower. 4. Misc tweaks+bugfixes not yet merged into the CuraEngine master branch. ### Stuff that won't be merged into the standard release because it has been rejected by the Cura devs 1. Initial Layer Wall Speed/Acceleration/Jerk lets you specify those values for the walls on the initial layer. 2. Initial Fan Speed At Height/Layer lets you specify the layer at which the initial fan speed comes into effect. Below that layer, the fans are off.

Hi, please post a screenshot or attach the gcode or 3mf file so we can see what the problem is. Thanks.

Hi, if you are using Linux and feeling like trying the cutting edge of Cura development then head over to https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0 where you will find copies of my current Cura installation. They are based on the Cura master branches + my own additions and tweaks and will contain all known bug fixes that have been merged to master. These are not AppImages but an archive of an installation built on a Ubuntu 16.04.4 system, just unpack and then execute cura/bin/cura.sh. Supplied with absolutely no warranty, YMMV.

Hi, is it possible to post the 3.3.1 project please? I would like to take a look at it. Thanks.

Hi @LubosD, that's a tricky thing (most likely impossible) to implement as the layer heights are calculated much earlier in the processing than the bridging. Perhaps it would be useful if Cura could be told to not use adaptive layers in certain height bands. A little project for someone...

I have looked at both of those files and they aren't really comparable as they have been obviously sliced with very different settings. You can see big variations in such areas as support style (zig-zag versus lines), number of lines in walls (1 v 2), amount of skin and so on. So, I'm not saying that the Cura output is great and the other not but I don't think they are very good examples to compare. If you can provide me with the model (STL) I would like to slice it myself and see if there is any improvements that can easily be made.

Please make the project file available if possible.

10GB!, did you mean 10MB? If so you can attach them to this thread. If you really mean 10GB then perhaps you could make the project file available instead.

It's not a stupid idea at all. If you are using more than 1 line for the wall, just make sure the "outer before innner walls" setting is not enabled and the "optimize wall printing order" setting is enabled it will print the inner walls before the outers. Hope this helps.