burtoogle

Here's a direct comparison, first image is what you get with 3.0.3 and the second image is what you should get in 3.1.

The changed zigzag code does not attempt to find the optimal order for printing the zigzags but it does have two good qualities: 1 - it always starts a zigzag line at an end. 2 - it uses the combing distance rather than the as the crow flies distance when deciding which zigzag line it should start next. This stops it jumping across air gaps like in your above example where, when half way round the circle it decides that the nearest line is (by the as the crow flies distance) on the other circle and so does a travel which because you are using combing routes the long way round to get to the other line.

I made something similar to your example above and you can see that it does not travel too much with the new zigzag ordering:

Use the print outer walls first option because at the moment it is printing from the inside out and the inside walls are not connected.

Hi @Haabilo, yes it should make a big difference to the speed of printing the zigzag infill in your example, can you please post a link to that model so I can test that?

Hello @qwerty8224, thanks a lot for the kind comments. I am very pleased you are happy. The work I do on Cura is relaxation for me, it's a lot of fun!

As regards to infill, I have improved how zigzag infill is printed so it now starts at the ends of the zigzag lines rather than anywhere along the line. This cuts down on the amount of travel while printing infill and stops some silly behaviour where it can print a pair of lines (a zig and a zag) and then move to another pair and so on. That's already in the master branch and so should be in the next major release (3.1, I guess).

Hi guys, thanks for the feedback. I agree, often the travel time saved isn't really significant (although that depends on the number of holes and walls and the distances involved) but it does cut down on the amount of dribble when using combing. It's definitely a case of YMMV.

Cura 3 has a new experimental setting called "Optimize Wall Printing Order". Please try it.

Hi @shadowfiend, just letting you know that the changes I made to improve the order in which zigzag infill (and skin) is printed have made it into the master branch which means that unless the testers find a problem that can't be fixed, they will be in the next release (3.1?) So, no more funny zigzags being printed backwards like you were seeing. I have also some changes that (IMHO) improve the routing taken while combing although they are really tweaks rather than a complete revamp. Yet to be merged.

Hi, I'm not connected to Ultimaker and I don't use Windows but I do have a suggestion. As you sound like you are desperate for a solution why don't you install Virtual Box, then install a basic Linux system in a VM and then try the Linux version of Cura? What have you got to lose apart from a few more hours of downloading?

Here's what freecad shows, there appears to be a couple of rogue points. Also, freecad reports lots of other problems with that model as you can see on the right:

Thanks, glad you like it. As to the line on the top/bottom, have you tried setting the combing mode to "no skin"? That's what I normally use and don't get nozzle marks on the top/bottom.

There is a new setting in Cura 3 called "Extra Skin Wall Count" that determines how many extra walls skin layers will have. For some reason, they decided to make the default 1 rather than 0. So in all my profiles I have to go around changing it to 0 so as to get the same results as I had before.

I know that Ultimaker receives info from Cura when it is used (assuming that the user doesn't disable that option) so it would be interesting if some basic statistics would be published every now and again (e.g. monthly). It surely would be interesting to know things like the number of active installations, the number of slices performed, the amount of filament sliced, etc. for each version of Cura that provides the stats. You have the data, why not share it?

Please try enabling the Wall Order Optimization (in the experimental category) and see if it still does that. And, yes, pictures and/or links to the model would be very useful.

Hi, could you please post links to the model (stl) and the gcode that doesn't have the hole. Thanks

I forgot to say that in the meantime you can just edit fdmprinter.def.json in your Cura installation and manually make that change.

See https://github.com/Ultimaker/Cura/pull/2621

Thanks for the feedback. Yes, the beta had a little problem with some models when printing infill first but that was quickly sorted.

Hi, @SandervG. The feature tries to optimize the order in which walls are printed. The aim is to reduce travel time (and hence reduce ooze). It also has the secondary effect of aligning the z-seams of inner walls with the outer wall. Yes, it's pretty much all my own work so I am claiming all the kudos if it is beneficial but I also get all the blame when it screws up. It has been very well tested but as we know, it's impossible for a developer (independent or Ultimaker) to test well enough to say something is completely bug free. That's why it is an experimental feature at the moment.

Great news! The Optimize Wall Printing Order feature is now available to all to try out. It's in the experimental settings section. Not that you would know that because the Cura devs failed to mention it in the 3.0 change log (or in the above blurb or the release notes). Anyway, please give it a go and if you have any problems either start a thread on the forum or raise an issue on github.

Hi, could you please post a link to the gcode file so that I can take a look?

Yes, the spiralize setting did get changed from being per-model to global. I can't remember now why that was done. I don't remember it being my idea to do that and git blame says that Tim was the last person that touched that setting. One restriction with using spiralize with multiple meshes is the obvious one that you can't have two separate models side by side and spiralize them both (or spiralize one and not the other). The meshes have to be stacked vertically so that only one mesh occurs on each layer. But that is what the OP above wants to achieve anyway. Perhaps it should be changed back to allow it to be specified per mesh?

I'm not suggesting you debug the software. Compile and install the software, yes. Debugging it should not be necessary if you install a (relatively) stable branch. Anyway, I'm leaving this thread now, I haven't got anything else to say beyond what I have said already.