burtoogle

Hi @P3D, I have just sliced your model using a Cura built from the master branch and it doesn't show those lines so, perhaps, the problem has already been fixed for a future release?

Hi @GeriX, I have taken a quick look at your files and can't see anything obviously wrong apart from the fact that you have z-hop set to 3mm which is, perhaps, somewhat OTT (literally).

It would be most useful if you could attach the project file and the gcode file. Thanks.

That wall is being printed as an outer wall and a skin. There's no inner wall in either case (it would be green not yellow). So Cura must think that the gap is too narrow to fit a wall into. Try reducing the line width slightly and it may then fit the inner wall in and with overlap compensation enabled and the min wall flow hack enabled, it should print as a single inner wall (green) surrounded by an outer wall (red).

Yes, I get the same behaviour quite often. My "quick fix" is just to hit F5 which reloads the model which wakes the Prepare button up again!

Hello again. I have now managed to create a Windows version of my development version of Cura. It can be found in the location mentioned above. It's very new and hasn't been tested other than I installed it, and Cura started up and sliced a model. It identifies itself as "master" and should not wreck any existing installations but, of course, it comes with no warranty so please take care to back up anything valuable first if you want to give it a go. And, yes, it includes the gyroid infill and various other gems that didn't make it into 3.5. All feedback is most welcome.

Hello @Link, you're very kind. I hope you are referring to the new implementation of "not in skin" combing which now, courtesy of me, really doesn't comb in skin and other places it should have avoided but hasn't done since the beginning of time.

Hi @Kalveo, thanks for the project. I fiddled with a few settings and now the travels look less wild. I have set the combing mode to "not in skin" which has been reworked in the 3.5 beta release and now behaves as you would expect. If you are using an older Cura release you will still see travels across air. CFFFP_MotorMount.curaproject.3mf

Hello @Kalveo, it would be much easier to answer your questions if you could attach the Cura project file to this thread. Use the file menu save (or save as project in older versions of Cura).

Yes, but it is how it is. We have to live with the current behaviour. You can open an issue on github and complain about it but I doubt if it will get acted upon.

I agree that it would be good if you could choose between faster slicing and better quality output.

No, z-seam alignment settings will still have an influence as before but the difference is that now it will no longer start a new layer where the previous layer finished when z-seam is set to closest.

Hello @Neukyhm, the second thing (layers start at same corner of box) is a constraint that came along when Cura's slicing engine moved from being single threaded to multi-threaded. Now it is multi-threaded, all layers start at the same location. Arguably, that is a regression but that's progress for you.

Hello @YairHH, as mentioned above, Cura always prints walls as pairs. Also, as mentioned above, there is now a setting that will not print walls when their flow has been reduced to below a threshold value that you can set. So the solution to the odd number of walls problem is to enable the overlap compensation and also set the wall min flow threshold to something like 20.

I'm trying to build Cura on a Windows 10 VM and have installed the community edition of Visual Studio 2017 along with the 2014 build tools. The build is failing when trying to build python with messages like these: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140\Microsoft.Cpp.Current.targets(64,5): error MSB4062: The "SetEnv" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140\Microsoft.Build.CppT asks.Common.dll. Could not load file or assembly 'Microsoft.Build.Utilities.Core, Version=14.0.0.0, Culture=neutral, Pu blicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contain s a public class that implements Microsoft.Build.Framework.ITask. [C:\Users\burto\cura\cura-build-environment\build\Pyt hon-prefix\src\Python\PCbuild\pythoncore.vcxproj] I don't normally use Windows so this is all foreign for me. Has anyone any suggestions as to what is required to fix this?

If you are an OS X user and are feeling adventurous, OS X versions of my development releases are now available from the same location. Please note that these have not been tested other than they actually start up OK on my development machine so there could be problems that I am not aware of. All feedback is welcome. Please note that all of the development releases are supplied with no warranty, use at your own risk.

I can now produce Linux AppImage files so my future development releases will be using that format rather than archives as that makes the files a lot smaller. I am still working on creating OS X releases but haven't successfully managed to build and package a working OS X release yet. I'll keep trying!

Hi @phantom, thanks for the files. I just looked at the 3.5 file and it only contains the model and no settings. Could you please save the project (File menu -> Save) as that will contain the settings as well as the model. Thanks.

Please save the project from 3.5 and attach the .3mf file here (if you are able/willing to share that).

Sorry, I don't have an answer but one thing I have noticed is that UM advocate using nozzle sizes that are equal or even larger than the line widths specified in the slicer. Perhaps that works for UM nozzles but it is completely the opposite to what I do myself on my non-UM machines that have e3d v6 hotends. So, if you have a 0.4mm nozzle for your printer, please try the same print, using 0.6mm line widths and see what happens. I print 0.6mm wide lines using a 0.4mm nozzle often with no problems.

Hi, @Link, could you please attach the project file (.3mf) or at least the model (.stl) so I can take a look. Thanks.

Sorry, I have no experience of plugins but I'm sure if you are capable of writing Python then almost anything can be done.

Great, I'm glad it's working well for you. As for the requirement of printing the outer walls first, rather embarrassingly, I cant right now remember why I thought that was required. It may be a mistake or there may be some subtle reason why it should be done. The overlap compensation that reduces the wall thickness is carried out independently for the outer wall and the inner walls so it should not make any difference the order in which the outer and inner walls are printed. EDIT - OK, I have remembered why it is better to print the outer wall first. When that option is selected it will print the outer wall of the part before it prints any holes within the part. If a hole is so close to the edge of the part that the walls overlap, it produces (generally) nicer result if the outer wall is printed before the hole wall because then the hole wall will be thinned down by the compensation rather than the outer wall being thinned down. You have to understand that the way the overlap compensation works is that when two walls try and occupy the same space, the first wall that is printed will have it's normal thickness and the second wall gets thinned. Here's an example that shows the difference. This first image shows the result when the outer wall is not printed first. So the hole red wall is printed complete and the outer red wall gets thinned down. This will tend to produce a rougher finish on the outer wall. This next image shows the result when the outer wall is printed first. The outer red wall is complete and the red wall for the hole is thinned down and so the roughness that it will create is, hopefully, less visible because it's inside the hole. So, it's not really a requirement, just a suggestion to maximise the surface quality when holes are close to the part outer wall. Hope this makes sense!

The weird fat infill lines look like the issue I reported in https://github.com/Ultimaker/Cura/issues/4314 . I have also noticed how the setting visibility dialog always jumps to the top when I expect it to go to the selected category.