too much travel printing walls..

[Thomllama 4]

is it just me or does it seem that Cura has a bit too much travel when printing simple walls?  it prints line one every where, traveling from spot to spot, then line 2, travels a bunch.. and so on..

wouldn't it be better to print line 1-4 (4 outer layers in this case) at 1st location, then move on to location 2 and only have one travel between?  Is there some setting I'm missing that is causing this?

 

Edited October 28, 2017 by Guest

[burtoogle 510]

Is there some setting I'm missing that is causing this?

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

[Thomllama 4]

Is there some setting I'm missing that is causing this?

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

Cool.. I will!!! thanks .

[Thomllama 4]

THANKS!!!! seems to be working perfectly!!! though doesn't seem to be shortening time, 1st layer looks much cleaner!

[Dim3nsioneer 557]

Same findings here. It does not reduce print time but it gets rid of a significant part of the travelling mess. So please feel free to go for the next step and include infill into the optimization.

[burtoogle 510]

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.

[burtoogle 510]

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).

[Haabilo 0]

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).

Oooooh yeah. I'm really looking forward to that update. I am printing rings that have a hole between them, they are connected on ~12 degrees of the circle. I'm printing them with a Volcano .8mm nozzle so zig zag is almost the only way to go.

Currently the infill-travel is just ridiculous, print a zig and a zag, travel 5 seconds to another zig and zag and then back 5 seconds. (It takes long because it has to avoid crossing the perimeter of the "hole".)

Octoprint Gcode viewer of the print:

[qwerty8224 16]

smartavionics

I want to say thank you for your contribution to Cura you are the only one who optimizes the algorithm and not just writes it)))))

And you do it very very well.

It is interesting to know how much% of the installation has increased Сura 3.0.3

with the function entry"Optimize Wall Printing Order" )))))

Good luck )

Edited October 30, 2017 by Guest

[burtoogle 510]

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!

[burtoogle 510]

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?

[burtoogle 510]

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

Edited October 30, 2017 by burtoogle

[burtoogle 510]

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.

[burtoogle 510]

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.

[burtoogle 510]

Related to this is another PR that takes into account the real travel distances rather than the as the crow flies distances when deciding the order in which to print a bunch of holes. You can see an example of the difference it makes at https://github.com/Ultimaker/CuraEngine/pull/617. That PR has yet to be incorporated into the Cura master branch. Hopefully it will also make it into 3.1.

[qwerty8224 16]

Very very good )))

[Haabilo 0]

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.

Sorry, I got kinda frusturated with this particular model and decided to move to other parts of the assembly in the meantime. (Figured to maybe use Slic3r to do this part.) But you seemed to get along pretty nicely.

Is there a way to get "nightly" builds of Cura 3.1?

If not, in the meantime I'll probably build a special version for just this one part.

I did some analysis on the generated gcode (3.0.4) after some regex wrestling, and from the estimated print time of 7 hours 14mins, ~3 hours 35mins are travels!

Also because of the excess travels due to combing (so retraction extra priming isn't taken into account) the infill doesn't even print because of the plastic oozing out during the moves.

[burtoogle 510]

Hi. I'm afraid that my changes to reduce the travel when printing models like the above did not make it into 3.1. I needed to make the code more efficient as for some models it was too slow. I am now happy with the performance and it makes a good job of reducing the amount of travels. I am now expecting it to arrive in 3.2. Sorry for the extra delay.