Cura 2.7 toolpath

[shadowfiend 9]

I'm  very interested in knowing if there is any way to control the way that the toolpath is generated, or to be more accurate, the order in which the computed paths are printed.  For the most part when I have looked at the gcode in Gcode Analyzer the actual toolpath is exactly what I want.  The problem is that the code that optimises the order of printing seems to undo the good work the toolpath generation code has made.

For example, we have all seen the situation where, say in a simple rectangle, it starts in the middle somewhere and then moves somewhere else for a bit, then leaves gaps and finally comes back and fills them in all the while creating unnecessary retractions and moves.  When our human intuition would say start at the bottom left and continue to the top right corner and don't do anything crazy in the middle.

I apologise if I am going over old ground here but the thing that bugs me the most is that on some layers it is totally perfect!!!

I'm sure that I'm not the only one to be frustrated by this, as it would make such a difference to the quality and reduce the number of failed prints.

Thanks.

[burtoogle 513]

The last version of Cura should print the skin of a simple part (like a rectangle or circle) from corner to corner thus avoiding extra seams. It should no longer start the skin area "in the middle". Obviously, if the part contains holes or has a non-trivial outline then skin areas cannot be printed as a single piece and seams will be required. If you have a specific example of Cura 2.7 not getting that right, please post a link to the gcode.

Edited September 26, 2017 by burtoogle

[shadowfiend 9]

Hi smartavionics,

Yes the v 2.7 top and bottom layers do seem to be working much better, however the infill is still doing some crazy stuff. Please see the gocode in the link:-

GCODE

On layer 5 the squre shape is behaving badly. The infill (zig zag) is starting in the bottom right and going to the bottom left corner, but then when it starts the other part it does not pick up at the starting point of the infill. Instead it starts a new line in the top left, comes back to the bottom right corner and meets up with the starting point. This is where it gets funky; the lines touching the shell are drawn out of sequence forcing a non extrusion move over the top of each previously printed short line. In Gcode Analyzer you can step through this line by line and see this happening using the scroll handles and cursor keys.

If I was to make a suggestion, I would say this. Choose a polyline and start printing at the beginning and continue to the end. I'm sure that this is an easy fix to those who know the slicing code. No need for any 'travelling salesman' gymnastics, just follow the polyline from start to end. Are you with me?

Many thanks

[burtoogle 513]

Hi shadowfiend, yes I completely agree with you. That rectangle on layer 5 gets infilled in a totally bizarre order. I'm not familiar with the detail of the infill code so I can't immediately think of where to look to improve this. I will investigate when time allows.

[shadowfiend 9]

Thanks smartavionics,

I think that if there was some way of tracking down who had corrected the code for the top and bottom surfaces, we might politely ask them to do the same for the infill patterns ;c)

[burtoogle 513]

I think that if there was some way of tracking down who had corrected the code for the top and bottom surfaces, we might politely ask them to do the same for the infill patterns ;c)

Well, I had a hand in that and I have looked at if doing the same helps the infill and I am not convinced it is right there. But I have been busy working on a PR that stops the disconnected pairs of lines being output like you see in your example.

https://github.com/Ultimaker/CuraEngine/pull/613

The code it modifies is used a lot (infill, skin, support, raft, etc.) so the PR will need a lot of testing before it could be accepted into Cura but we may as well set the ball rolling.

[shadowfiend 9]

That's excellent smartavionics, I'm sure a lot of people will be delighted to see the improvement this would make to print quality and performance. When there are a lot of unnecessary moves, retractions and extra time spent on a layer there is more stress on the printer and more inconsistency in filament deposition and failed prints.

With the announcement of Cura v3, It would be great to see this issue finally put to rest and help to make Cura the market leader that I know it can be.

[burtoogle 513]

When there are a lot of unnecessary moves, retractions and extra time spent on a layer there is more stress on the printer and more inconsistency in filament deposition and failed prints.

I agree even though I normally only print small parts. For someone printing parts that can take 10s of hours, the time savings can be substantial. Also, cutting down on travel really does help with ooze!

 

With the announcement of Cura v3, It would be great to see this issue finally put to rest and help to make Cura the market leader that I know it can be.

Hmm, well, we shall see. I'm afraid I'm too cynical to really believe that but I'll keep on fixing the stuff that could (IMHO) be better done.

[burtoogle 513]

I put some more time into this and have submitted PRs that improve various other things including the combing. Here's an example:

Before:

After:

The travel time reduced from 11 to 9 minutes which is an 18% reduction and 2 minutes of less dribble!

[shadowfiend 9]

Hi smartavionics,

Sorry I've been busy with some real life stuff, so I missed your post.

This looks very interesting, if you post the gcode before and after and I will happily look through to help identify any remaining strange behaviours, if that is helpful.

Many thanks.

[burtoogle 513]

Hi shadowfiend, thanks for the offer but I know that as far as the combing is concerned there is much that could be done to improve the paths. It's really quite a task (I think) to make the combing optimal and I'm not going to take that on. I've tinkered with it and made some useful improvements but I don't have the time or energy to do more right now.

[shadowfiend 9]

Hi smartavionics,

I understand what you are saying here, but I do appreciate you taking the time to have looked into it.

Perhaps GitHub would be the place for me to make a nuisance of myself ;c)

Many thanks for your efforts.

[burtoogle 513]

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.