Feature Request: Travel moves stay over infill if possible.

[Intrinsically-Sublime]

It would be really nice to have a feature like Skeinforges "Comb" that keeps the nozzle over the model as often as possible.

Example: Prusa vertex: The nozzle travels between the two ends outside of the perimeter which causes surface blemishes (and slight ooze with a bowden at high speeds).

It would be best if it went over the infill not the perimeter (SF follows the perimeter sometimes and it causes blemishes too)

[alranel]

Hi Sublime. While I think it would be great to have everything, that feature would add a significant slow down to slicing time. I believe that a sane retraction configuration, including a little retraction lift, really avoids the need of such a behavior, which would also slow down travel moves and increase the risk of ooze.

[Intrinsically-Sublime]

When you are printing perimeters at 100mm/s and traveling at 200mm/s the hysteresis in a bowden cable is unavoidable. I retract 2mm at 100mm/s and it is not enough. Adding Z-lift only adds more time for ooze and bumps. I truly believe this is a must have feature.

[jmgiacalone]

To solve the bowden ooze problem, we need to either implement my oozestep skeinforge plugin (retract takes place before the end of the extrusion thread, so when the head gets to the end of the thread is can go straight into the travel move without waiting for retraction) in slic3r, or have a play with Marlin's extruder advance feature which treats the filament going into the extruder as a compressed spring.

The comb feature merely hides the problem. If printing small parts, there is nowhere to hide an ooze problem, so the answer is to fix it.

This was raised as an issue some time ago (#150), and the conclusion was to look at Marlin's advance feature (which I still haven't done, although I now have Marlin running nicely on my machines, so this is hig on my to do list).

[Intrinsically-Sublime]

I have tried Marlins advance feature with a K setting of -0.1 to 0.1 and everything in between. It does not solve the problem. It moves the bump around to a new spot while making your extruder sound like it will be broken with in about 1 week (it does full speed reversals on EVERY move (only a tiny amount but way more than an extruder gear can take) plus it never seems to truly compensate for the reversals so by the end of the model it does not have enough plastic.

I am also not talking about much ooze at all. Maybe a drop the size of a pin head at the point where the head leaves the perimeter and comes back. Even if it does not ooze it can leave a mark as soon as the nozzle passes over a perimeter.

Speed on the side of the slicer is nice but I would rather have my slicer take and extra 5-500 minutes to slice if it means I do not have to spend any time doing clean up.

[alranel]

Okay people, I think Slic3r will get an "Avoid crossing perimeters" option.

[Intrinsically-Sublime]

Maybe it should be combined with issue 186 https://github.com/alexrj/Slic3r/issues/186 where all perimeters make a move inwards at the end as both are to achieve a perfect finish as the cost of speed.

[jmgiacalone]

@alexrj, I don't think slic3r should avoid crossing the perimeters as this will add considerable time to process and print. The important thing is that all moves which cross a perimeter must have retracted before the move.

I agree #186 is a good idea, however if the retract does not always take place before moving across a perimeter, it doesn't matter where you start and end the nozzle will ooze over empty space.

[alranel]

One more related idea (by @Joaz): add a checkbox to only lift Z when travelling across perimeters.

[Intrinsically-Sublime]

The problem with Z lift is it stops to lift before the move which allows for ooze. If this is being done on a perimeter like when printing hollow you end up with a bigger bump. If the head moved in over the infill area then retracted, then lifted, then moved it could work. But that may slow the build more than just staying over the infill in the first place. I think a check box with "do not cross perimeters" would be the best option. Then if people don't want to wait ten extra seconds to get a perfect print they can choose not to.

[thantik]

I believe the travel over infill would be a good option because people don't start out with perfect retraction settings. Combing the path so it doesn't cross perimeters means better first-run quality for those coming to Slic3r from Skeinforge/SFACT.

It was my understanding that Slic3r strived to be easier to setup than Skeinforge, and traveling over infill definitely fits the bill there. It means less initial tweaking retraction settings, nicer default prints, not having to resort to things like Z-lift (which can cause blobs/inaccuracies with layer heights when people are using cheap lead screws) and doesn't increase print time to any noticeable degree.

[canadaduane]

I wish I had a lens more suitable for close-ups, but here is an example of the result I'm seeing on the Ultimaker (note that the shaft should be a perfect cylinder, but it has oozing in 2 locations for each layer):

Does this jive with what others are experiencing, and trying to fix in this discussion?

[Intrinsically-Sublime]

@canadaduane Those look more like too slow or too long of retracts and or slow z speed and or slow travel. Maybe even to hot, to much material. We are talking about very small imperfections that occur after you have tuned away all of those bumps.

[jgeerds-zz]

@alexrj when do you think the slic3r "comb" feature will be implemented? I am asking because retraction on an Ultimaker doesn't always guarantee string-free printing, especially if the temp is slightly too high, and the PLA more fluid than necessary, and doing more of the travel over infill areas would prevent small&ugly little bums on the surface.

[jgeerds-zz]

0.7.2b still doesn't do a very good job with combing, and decides to do random travels "out to sea", where it could stay "on the island", with strings and blobbing and all the stuff that comes with it. related to this: retraction set to 45mm/s (Ultimaker) retracts like running at 20mm/s, or less, definitely not at max speed.

[Intrinsically-Sublime]

Just wondering if any work has been done on this or even just better path optimization which would lesson the need for travel moves.

[alranel]

No work on this yet.

[thantik]

Just a quick notation on this issue: Partial implementation of this (determination of a movement to cross a perimeter or not) could help reduce the number of retracts people are seeing on infill patterns (which is kind of just a bandaid for now, but would be welcome anyhow). Full implementation would allow retractions on infill to be almost eliminated.

[alranel]

Just an update on this: the avoid crossing perimeters feature is available in the avoid-crossing-perimeters branch. It needs some optimization before merging, as it slows down the G-code generation process too much. However, it's there.

[alranel]

This feature was recently merged as of a016a06fa604193bafaa9417a78834f17338c59a

[alranel]

My implementation should be smarter than Skeinforge's in most cases because it moves inside infill space and not on perimeters. Also, it looks for the shortest path and doesn't just follow perimeters. When it needs to exit an island, it tries to cross a perimeter corner.

[thecrazy]

Wow, thats some nice work, cant wait to try that!